Changes between Version 20 and Version 21 of NewMutableEncodingDesign
- Timestamp:
- 2012-01-10T21:06:17Z (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
NewMutableEncodingDesign
v20 v21 33 33 The RSA fields are so large that we clearly cannot put them in the filecaps, 34 34 so the encoding scheme requires them to be stored in the shares, encrypted 35 and hashed as necessary. The E CDSAkeys are short enough (in most cases) to put35 and hashed as necessary. The Ed25519 keys are short enough (in most cases) to put 36 36 directly in the filecap, although note that this still increases the cap length 37 37 relative to using a hash truncated to K+T bits. … … 85 85 same way as immutable files. Shares include a merkle tree over the share 86 86 blocks, and a second one over the ciphertext segments. 87 * we'd like to add a merkle tree over the plaintext, without reintroducing87 * we'd like to add a Merkle tree over the plaintext, without reintroducing 88 88 the partial-information-guessing attack that prompted us to remove it. 89 89 This means encrypting the nodes of this merkle tree with a key derived … … 107 107 collision-resistance criteria. 108 108 109 == ECDSA , semi-private keys, no traversalcap ==109 == ECDSA or Ed25519, semi-private keys, no traversalcap == 110 110 111 111 Zooko captured the current leading semi-private-key-using mutable file design … … 148 148 is the pubkey, and that can't be used to protect the data because it's public 149 149 (and used by the server to validate shares). One approach is to use the 150 current (discrete-log DSA) mutable file structure, and merely move the 151 private key out of the share and into the writecap: 152 153 * (K + T) writecap = (K+T)-bit random string = privkey 154 * (2K + T) readcap = H(writecap)[:K] + H(pubkey)[:K+T] 150 current mutable file structure (with any signature algorithm), and merely 151 move the private key out of the share and into the writecap: 152 153 * (K + T) writecap = (K+T)-bit random string 154 * (2K) privkey = H(writecap) 155 * (2K + T) readcap = H(privkey)[:K] + H(pubkey)[:K+T] 155 156 * (K + T) verifycap = H(pubkey)[:K+T] 156 157 * storage-index = verifycap … … 164 165 for mutable files.) The verifycap is K+T bits. 165 166 166 === include ECDSA pubkey in cap ===167 === include ECDSA or Ed25519 pubkey in cap === 167 168 168 169 Or, if the pubkey is short enough, include it in the cap rather than 169 170 requiring the client to fetch a copy: 170 171 171 * (K + T) writecap = (K+T)-bit random string = privkey 172 * (minimum 3K) readcap = H(writecap)[:K] + pubkey 172 * (K + T) writecap = (K+T)-bit random string 173 * (2K) privkey = H(writecap) 174 * (minimum 3K) readcap = H(privkey)[:K] + pubkey 173 175 * (minimum 2K) verifycap = pubkey 174 176 * storage-index = H(pubkey) 175 177 176 ECDSA pubkeys are slightly more than 2*K long, so this would increase the 177 length of the readcaps whenever K > T. The advantage would be simplifying/speeding up 178 the download process. It is highly unlikely that there is any public key algorithm 178 The hash to obtain the privkey is necessary because directly using a (K+T)-bit 179 exponent would allow meet-in-the-middle attacks. ECDSA or Ed25519 pubkeys are 180 slightly more than 2*K long, so this would increase the length of the readcaps 181 because 2*K > T. The advantage would be simplifying/speeding up the download 182 process. It is highly unlikely that there is any public key algorithm 179 183 with keys shorter than 2*K for a K-bit security level. Since we can use shorter 180 184 hashes than public keys, the H(pubkey) design above gives us shorter read caps, … … 183 187 === Any signature algorithm, no semi-private keys, with traversalcap === 184 188 185 Since a secure pubkey identifier (either H(pubkey)[:K+T] or the original privkey)189 Since a secure pubkey identifier (either H(pubkey)[:K+T] or the original writecap) 186 190 is present in all caps, it's easy to insert arbitrary intermediate levels. It 187 191 doesn't even change the way the existing caps are used: 188 192 189 * (K + T) writecap = (K+T)-bit random string = privkey 190 * (2K + T) readcap = H(writecap)[:K] + H(pubkey)[:K+T] 193 * (K + T) writecap = (K+T)-bit random string 194 * (2K) privkey = H(writecap) 195 * (2K + T) readcap = H(privkey)[:K] + H(pubkey)[:K+T] 191 196 * (2K + T) traversalcap: H(readcap)[:K] + H(pubkey)[:K+T] 192 197 * (K + T) verifycap = H(pubkey)[:K+T]
