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

write caps need to be at least K + T bits 

[Imported from Trac: page NewMutableEncodingDesign, version 16]
davidsarah 2010-01-13 00:47:27 +00:00
parent 3496c9eeb0
commit ce22d7cc12
1 changed files with 10 additions and 10 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

20
NewMutableEncodingDesign.md

@ -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)