tahoe-lafs/trac-2024-07-25
2
0
Issues 1.1k Wiki Activity

clarify which schemes depend on ECDSA (short public keys) and which don't 

[Imported from Trac: page NewMutableEncodingDesign, version 10]
davidsarah 2010-01-07 07:34:46 +00:00
parent f1f65b1605
commit c36a0d87dc
1 changed files with 6 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
NewMutableEncodingDesign.md

@ -112,7 +112,7 @@ nicely in the ["StorageSS08" paper](http://allmydata.org/~zooko/lafs.pdf)
* (1K) writecap = K-bit random string (perhaps derived from user-supplied * (1K) writecap = K-bit random string (perhaps derived from user-supplied
material) (remember, K=kappa, probably 128bits) material) (remember, K=kappa, probably 128bits)
* (2K) readcap = 2*K-bit semiprivate key * (minimum 2K) readcap = minimum 2*K-bit semiprivate key
* verifycap = 2*K-bit public key * verifycap = 2*K-bit public key
* storage-index = truncated verifycap * storage-index = truncated verifycap
@ -130,8 +130,8 @@ signed block that must be fetched anyways).
Like above, but create two levels of semiprivate keys instead of just one: Like above, but create two levels of semiprivate keys instead of just one:
* (1K) writecap = K-bit random string * (1K) writecap = K-bit random string
* (2K) readcap = 2*K-bit first semiprivate key * (minimum 2K) readcap = minimum 2*K-bit first semiprivate key
* (2K) traversalcap = 2*K-bit second semiprivate key * (minimum 2K) traversalcap = minimum 2*K-bit second semiprivate key
* verifycap = 2*K-bit public key * verifycap = 2*K-bit public key
* storage-index = truncated verifycap * storage-index = truncated verifycap
@ -139,7 +139,7 @@ The dirnode encoding would use H(writecap) to protect the child writecaps,
H(readcap) to protect the child readcaps, and H(traversapcap) to protect the H(readcap) to protect the child readcaps, and H(traversapcap) to protect the
child verifycap/traversalcaps. child verifycap/traversalcaps.
## ECDSA, no semi-private keys, no traversalcap ## Any public key algorithm, no semi-private keys, no traversalcap
Without semi-private keys, we need something more complicated to protect the Without semi-private keys, we need something more complicated to protect the
readkey: the only thing that can be mathematically derived from the writecap readkey: the only thing that can be mathematically derived from the writecap
@ -160,7 +160,7 @@ to (1+2)*K : we can truncate the AES key since we only need K bits for K-bit
confidentiality, but require 2*K bits on H(pubkey) to attain K-bit collision confidentiality, but require 2*K bits on H(pubkey) to attain K-bit collision
resistance. The verifycap is 2*K. resistance. The verifycap is 2*K.
### include pubkey in cap ### include ECDSA pubkey in cap
Or, if the pubkey is short enough, include it in the cap rather than Or, if the pubkey is short enough, include it in the cap rather than
requiring the client to fetch a copy: requiring the client to fetch a copy:
@ -176,7 +176,7 @@ could use shorter pubkeys, this design might give us slightly shorter keys.
Alternately, if we could use shorter hashes, then the H(pubkey) design might Alternately, if we could use shorter hashes, then the H(pubkey) design might
give us slightly shorter keys. give us slightly shorter keys.
### add traversalcap ### Any public key algorithm, no semi-private keys, with traversalcap
Since a secure pubkey identifier (either H(pubkey) or the original privkey) Since a secure pubkey identifier (either H(pubkey) or the original privkey)
is present in all caps, it's easy to insert arbitrary intermediate levels. It is present in all caps, it's easy to insert arbitrary intermediate levels. It