Changes between Version 7 and Version 8 of NewMutableEncodingDesign


Ignore:
Timestamp:
2010-01-05T19:40:22Z (15 years ago)
Author:
davidsarah
Comment:

delete insecure scheme using HMAC

Legend:

Unmodified
Added
Removed
Modified
  • NewMutableEncodingDesign

    v7 v8  
    189189 * storage-index = truncated verifycap
    190190
    191 == Shorter readcaps ==
     191== Shorter readcaps using MAC ==
    192192
    193 (oh, oops, ignore this part. HMACs using the readcap as key are vulnerable to
    194 manipulation by a collusion between Rose-the-readcap-holder and the storage
    195 servers, and could be used to cause another readcap-holder to see the wrong
    196 data. Nevermind.)
    197 
    198 To make the readcap shorter, we must give up something, like complete
    199 server-side validation and complete offline attenuation.
    200 
    201  * (1K) writecap = K-bit random string = privkey
    202  * (1K) readcap = H(writecap)[:K]
    203  * storage-index = H(readcap)
    204  * verifycap = storage-index + pubkey
    205 
    206 The readcap is used as an HMAC key, and the share contains (inside the signed
    207 block) an HMAC of the pubkey. The readcap is also hashed with the per-publish
    208 salt to form the AES key with which the actual data is encrypted.
    209 
    210 The writecap begets the readcap, and the readcap begets the storage-index, so
    211 both writers and readers will be able to find the shares, and writecaps can
    212 be attenuated into readcaps offline. Wally the writecap-holder can generate
    213 the pubkey himself and not use (or validate) the value stored in the share.
    214 But Rose the readcap-holder must first retrieve the (pubkey,HMAC) pair and
    215 validate them, then she can use the pubkey to validate the rest of the share.
    216 
    217 Wally can generate the verifycap offline, but Rose cannot, since she has to
    218 fetch the pubkey first.
    219 
    220 The verifycap must contain a copy of the pubkey (or its hash), because the
    221 storage-index is not usable to validate the pubkey (the HMAC doesn't help,
    222 because it is keyed on the readcap, which is unavailable to the Val the
    223 verifycap-holder). And it must contain a copy of the storage-index, because
    224 the pubkey is insufficient to generate it.
    225 
    226 The storage-index must be derived from the readcap, not the pubkey, because
    227 the pubkey is too long to get into the readcap, and Rose the readcap-holder
    228 must have some way of getting the storage-index.
    229 
    230 The server can check the signature against the embedded pubkey, but has no
    231 way to confirm that the embedded pubkey is correct, because the validatable
    232 binding between pubkey and storage-index is only available to Rose. You could
    233 copy the verifycap into the share, but there's no cryptographic binding
    234 between it and the storage index. You could put a copy of the storage-index
    235 in the signed block, but again that doesn't prove that the storage-index is
    236 the right one. Only a scheme in which the storage-index is securely derived
    237 from the pubkey will give the desired property.
    238 
    239 Another possibility is to have a 2K-long readcap and put K bits of a pubkey
    240 hash in it. That would look like:
    241 
    242  * (1K) writecap = K-bit random string = privkey
    243  * (1K) storage-index = H(pubkey)[:K]
    244  * (2K) readcap = H(writecap)[:K] + storage-index
    245  * verifycap = storage-index
    246 
    247 This "half-verifycap" approach restores full offline attenuation, and gives
    248 the server 1K bits of validation, but reduces Val the verifycap-holder's
    249 validation bits in half (from 2K to 1K). A full verifycap, H(pubkey), could
    250 be generated offline by Wally, or by Rose after fetching the pubkey. You
    251 still need the HMAC on the pubkey to give Rose 2K confidence that she's got
    252 the right pubkey: the storage-index only gives 1K.
    253 
     193This section used to describe a scheme using a MAC (with the read cap as key)
     194instead of signatures. However this was vulnerable to manipulation by a
     195collusion between Rose-the-readcap-holder and the storage servers, and
     196could be used to cause another readcap-holder to see the wrong data.
     197See the [http://allmydata.org/trac/tahoe/wiki/NewMutableEncodingDesign?version=7 history] if you're interested.