clarify which schemes depend on ECDSA (short public keys) and which don't
[Imported from Trac: page NewMutableEncodingDesign, version 10]
parent
f1f65b1605
commit
c36a0d87dc
|
@ -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
|
||||
|
|
Loading…
Reference in a new issue