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