Version 29 (modified by zooko, at 2009-10-11T04:04:03Z) (diff) |
---|
This is about What Could Go Wrong with the "Elk Point 2" immutable file caps: http://zooko.com/immutable-elkpoint-2.svg (http://zooko.com/immutable-elkpoint-2.png if your browser does not correctly handle SVG.)
# | what bad thing could happen | how | who could do it | what could they target | what crypto property prevents it | how expensive to brute force [footnote 5] |
1 | shape-shifter immutable file [footnote 1] | collide read-cap (R,T) | creator of a file | their own file | the hash function's and cap format's collision resistance on the read-cap (R,T). This also depends on the encryption of K1 being deterministic and correct. | 2(r+t)/2 |
2 | unauthorized read | attack the encryption of K1 with R | anyone | any one file | the security of the encryption scheme used for K1, and the secrecy of the read-key R | 2min(r,k) |
3 | forgery of immutable file | generate a matching read-cap (R,T) for someone else's file | anyone | any one file | the hash function's and cap format's second-preimage resistance on (R,T). This also depends on the encryption of K1 being deterministic and correct. | 2r+t |
4 | roadblock or speedbump [footnote 2] | generate (K1enc,Dhash,V) that hash to someone else's T, and copy their S | anyone [footnote 6] | any one file | the hash function's and cap format's second-preimage resistance on T | 2t |
5 | unauthorized read | attack the encryption of the plaintext with K1 | anyone | any one file | the security of the encryption scheme used for the plaintext, and the secrecy of the encryption key K1. The latter also depends on the security and seeding of the RNG that generated it. | 2k |
6 | unauthorized read | figure out the input to the hash function that generates S | anyone | any one file | the hash function's onewayness for (R,T) -> S | brute force on R is #2 |
7 | unauthorized deletion | brute force KD | anyone | any one file | secrecy of KD | 2d |
8 | unauthorized deletion | figure out a working destroy key KD from Dhash | anyone | any one file | the hash function's preimage resistance on Dhash | 2min(d,dh) |
9 | denial of service | prevent access to servers holding sufficient shares (by controlling some of them, or by attacking them or the network) | anyone | any file | not prevented by crypto | n/a |
10 | cause invalid share to verify | generate (K1enc,Dhash,V) that hash to someone else's (T,U), and copy their S | anyone | any one file | the hash function's second-preimage resistance on (T,U) | 2t+u |
11 | undeletion [footnote 3] | restore a deleted file's shares by controlling the relevant servers | anyone | any one file | not prevented by crypto | n/a |
12 | undeletion [footnote 3] | generate matching (R,T,U) for a deleted file | anyone | any one file | the hash function's and cap format's second-preimage resistance on (R,T,U) | 2r+t+u |
13 | accidental collision | storage indices (S1,T1) and (S2,T2) collide accidentally | n/a | any two files | approximately random distribution of hash function outputs | [footnote 4] |
where k = bitlength(K1), r = bitlength(R), s = bitlength(S), t = bitlength(T), u = bitlength(U), d = bitlength(KD), dh = bitlength(Dhash).
(The notes to the diagram assume k == r.)
- shape-shifter immutable file: creator creates more than one file matching the immutable file readcap
- roadblock: attacker prevents uploader (including repairer) from being able to write a real share into the right storage index; speedbump: attacker adds his bogus share into the list of shares stored under the storage index by the same method; downloader has to download, examine, and discard the bogus (K1enc,Dhash,V)'s until it finds the real one. Also see http://allmydata.org/pipermail/tahoe-dev/2009-October/002959.html
- undeletion: attacker makes a deleted file (for which it need not have had a read cap) accessible at its previous storage index, and readable by previous read caps
- See the probability table at http://en.wikipedia.org/wiki/Birthday_Paradox , for hash length s+t.
- Brute force costs assume a single-target attack that is expected to succeed with high probability. Costs will be lower for attacking multiple targets or for a lower success probability. (Should we give explicit formulae for this?)
- roadblock/speedbump attacks could be restricted to holders of a read cap by use of an extra signature, as in the Elk Point 3 design (diagram at http://jacaranda.org/tahoe/mutable-addonly-elkpoint-3.svg for mutable files).