Version 13 (modified by davidsarah, at 2009-10-11T02:07:43Z) (diff) |
---|
This is about What Could Go Wrong with the "Elk Point 2" immutable file caps: http://jacaranda.org/tahoe/immutable-elkpoint-2.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(n+t)/2 |
2 | unauthorized read | attack the encryption of K1 with R | anyone | any one file | the cipher's security and the secrecy of the read-key R | 2n |
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-pre-image resistance on (R,T). This also depends on the encryption of K1 being deterministic and correct. | 2n+t |
4 | roadblock or speedbump [footnote 2] | generate (K1enc,Dhash,V) that hash to someone else's T, and copy their S | anyone | any one file | the hash function's and cap format's collision resistance on T | 2t |
5 | unauthorized read | attack the encryption of the plaintext with K1 | anyone | any one file | the cipher's security and the secrecy of the encryption key K1 | 2k |
6 | unauthorized read | figure out the input to the hash function that generates S | anyone | any one file | the hash function's pre-image resistance on 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 the destroy key KD from Dhash | anyone | any one file | the hash function's pre-image 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-pre-image 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-pre-image resistance on (R,T,U) | 2n+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), n = bitlength(R), t = bitlength(T), u = bitlength(U), d = bitlength(KD), dh = bitlength(Dhash).
- 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
- 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 .
- 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 give explicit formulae for this?)
http://allmydata.org/pipermail/tahoe-dev/2009-October/002959.html