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)
|
nicely in the ["StorageSS08" paper](http://allmydata.org/~zooko/lafs.pdf)
|
||||||
(in Figure 3). The design is:
|
(in Figure 3). The design is:
|
||||||
|
|
||||||
* (1K) writecap = K-bit random string (perhaps derived from user-supplied
|
* (K + T) writecap = (K+T)-bit random string, perhaps derived from user-supplied
|
||||||
material) (remember, K=kappa, probably 128bits)
|
material (remember, K=kappa, probably 128bits)
|
||||||
* (minimum 2K) readcap = minimum 2*K-bit semiprivate key
|
* (minimum 2K) readcap = minimum 2*K-bit semiprivate key
|
||||||
* (minimum 2K) verifycap = public 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
|
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
|
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:
|
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) readcap = minimum 2*K-bit first semiprivate key
|
||||||
* (minimum 2K) traversalcap = minimum 2*K-bit second semiprivate key
|
* (minimum 2K) traversalcap = minimum 2*K-bit second semiprivate key
|
||||||
* (minimum 2K) verifycap = public 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,
|
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
|
||||||
|
@ -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
|
current (discrete-log DSA) mutable file structure, and merely move the
|
||||||
private key out of the share and into the writecap:
|
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]
|
* (2K + T) readcap = H(writecap)[:K] + H(pubkey)[:K+T]
|
||||||
* (K + T) verifycap = 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
|
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
|
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
|
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:
|
||||||
|
|
||||||
* (K) writecap = K-bit random string = privkey
|
* (K + T) writecap = (K+T)-bit random string = privkey
|
||||||
* (minimum 3K) readcap = H(writecap)[:K] + pubkey
|
* (minimum 3K) readcap = H(writecap)[:K] + pubkey
|
||||||
* (minimum 2K) verifycap = pubkey
|
* (minimum 2K) verifycap = pubkey
|
||||||
* storage-index = H(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
|
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:
|
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) readcap = H(writecap)[:K] + H(pubkey)[:K+T]
|
||||||
* (2K + T) traversalcap: H(readcap)[:K] + H(pubkey)[:K+T]
|
* (2K + T) traversalcap: H(readcap)[:K] + H(pubkey)[:K+T]
|
||||||
* (K + T) verifycap = H(pubkey)[:K+T]
|
* (K + T) verifycap = H(pubkey)[:K+T]
|
||||||
* storage-index = truncated verifycap
|
* storage-index = verifycap
|
||||||
|
|
||||||
## Shorter readcaps (insecure)
|
## Shorter readcaps (insecure)
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue