write caps need to be at least K + T bits
[Imported from Trac: page NewMutableEncodingDesign, version 16]
parent
3496c9eeb0
commit
ce22d7cc12
|
@ -131,11 +131,11 @@ Zooko captured the current leading semi-private-key-using mutable file design
|
|||
nicely in the ["StorageSS08" paper](http://allmydata.org/~zooko/lafs.pdf)
|
||||
(in Figure 3). The design is:
|
||||
|
||||
* (1K) writecap = K-bit random string (perhaps derived from user-supplied
|
||||
material) (remember, K=kappa, probably 128bits)
|
||||
* (K + T) writecap = (K+T)-bit random string, perhaps derived from user-supplied
|
||||
material (remember, K=kappa, probably 128bits)
|
||||
* (minimum 2K) readcap = minimum 2*K-bit semiprivate key
|
||||
* (minimum 2K) verifycap = public key
|
||||
* storage-index = truncated verifycap
|
||||
* storage-index = (possibly truncated) verifycap
|
||||
|
||||
On each publish, a random salt is generated and stored in the share. The data
|
||||
is encrypted with H(salt, readcap) and the ciphertext stored in the share. We
|
||||
|
@ -150,11 +150,11 @@ 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
|
||||
* (K + T) writecap = (K+T)-bit random string
|
||||
* (minimum 2K) readcap = minimum 2*K-bit first semiprivate key
|
||||
* (minimum 2K) traversalcap = minimum 2*K-bit second semiprivate key
|
||||
* (minimum 2K) verifycap = public key
|
||||
* storage-index = truncated verifycap
|
||||
* storage-index = (possibly truncated) verifycap
|
||||
|
||||
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
|
||||
|
@ -169,10 +169,10 @@ is the pubkey, and that can't be used to protect the data because it's public
|
|||
current (discrete-log DSA) mutable file structure, and merely move the
|
||||
private key out of the share and into the writecap:
|
||||
|
||||
* (K) writecap = K-bit random string = privkey
|
||||
* (K + T) writecap = (K+T)-bit random string = privkey
|
||||
* (2K + T) readcap = H(writecap)[:K] + H(pubkey)[:K+T]
|
||||
* (K + T) verifycap = H(pubkey)[:K+T]
|
||||
* storage-index = truncated verifycap
|
||||
* storage-index = verifycap
|
||||
|
||||
In this case, the readcap/verifycap holder is obligated to fetch the pubkey
|
||||
from one of the shares, since they cannot derive it themselves. This
|
||||
|
@ -187,7 +187,7 @@ for mutable files.) The verifycap is K+T bits.
|
|||
Or, if the pubkey is short enough, include it in the cap rather than
|
||||
requiring the client to fetch a copy:
|
||||
|
||||
* (K) writecap = K-bit random string = privkey
|
||||
* (K + T) writecap = (K+T)-bit random string = privkey
|
||||
* (minimum 3K) readcap = H(writecap)[:K] + pubkey
|
||||
* (minimum 2K) verifycap = pubkey
|
||||
* storage-index = H(pubkey)
|
||||
|
@ -205,11 +205,11 @@ Since a secure pubkey identifier (either H(pubkey)[:K+T] or the original privkey
|
|||
is present in all caps, it's easy to insert arbitrary intermediate levels. It
|
||||
doesn't even change the way the existing caps are used:
|
||||
|
||||
* (1K) writecap = K-bit random string = privkey
|
||||
* (K + T) writecap = (K+T)-bit random string = privkey
|
||||
* (2K + T) readcap = H(writecap)[:K] + H(pubkey)[:K+T]
|
||||
* (2K + T) traversalcap: H(readcap)[:K] + H(pubkey)[:K+T]
|
||||
* (K + T) verifycap = H(pubkey)[:K+T]
|
||||
* storage-index = truncated verifycap
|
||||
* storage-index = verifycap
|
||||
|
||||
## Shorter readcaps (insecure)
|
||||
|
||||
|
|
Loading…
Reference in a new issue