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
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
* 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:
* (1K) writecap = K-bit random string
* (2K) readcap = 2*K-bit first semiprivate key
* (2K) traversalcap = 2*K-bit second semiprivate key
* (minimum 2K) readcap = minimum 2*K-bit first semiprivate key
* (minimum 2K) traversalcap = minimum 2*K-bit second semiprivate key
* verifycap = 2*K-bit public key
* 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
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
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
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
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
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)
is present in all caps, it's easy to insert arbitrary intermediate levels. It