tahoe-lafs/trac-2024-07-25
2
0
Issues 1.1k Wiki Activity

fix links 

[Imported from Trac: page NewCaps/WhatCouldGoWrong, version 57]
zooko 2013-01-14 02:16:26 +00:00
parent 26c330c952
commit 3f6f99424e
1 changed files with 2 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
NewCaps/WhatCouldGoWrong.md

@ -28,7 +28,7 @@ where *k* = bitlength(*K1*), *r* = bitlength(*R*), *s* = bitlength(*S*), *t* = b
1. *shape-shifter immutable file*: creator creates more than one file matching the immutable file readcap 1. *shape-shifter immutable file*: creator creates more than one file matching the immutable file readcap
2. *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> 2. *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 [//pipermail/tahoe-dev/2009-October/002959.html tahoe-dev/2009-October/002959.html]
3. *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 3. *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
@ -40,6 +40,6 @@ where *k* = bitlength(*K1*), *r* = bitlength(*R*), *s* = bitlength(*S*), *t* = b
7. The formula given in the Wikipedia Birthday Attack page is sqrt(2.ln(1/(1-*p*))).2^(*r*+*t*)/2^, but the approximation given here is very accurate for small *p*, and can only underestimate the cost. For *p* = 1/2 it underestimates by only a factor of 1.18. For *p* near 1 it underestimates severely; it is very hard for an attacker to be *certain* to find a collision. 7. The formula given in the Wikipedia Birthday Attack page is sqrt(2.ln(1/(1-*p*))).2^(*r*+*t*)/2^, but the approximation given here is very accurate for small *p*, and can only underestimate the cost. For *p* = 1/2 it underestimates by only a factor of 1.18. For *p* near 1 it underestimates severely; it is very hard for an attacker to be *certain* to find a collision.
8. In order for the combined hash with output (*R*,*T*) to have the strength against collision and preimage attacks given here, there must not be multicollision attacks against the hash truncated to *r* bits or to *t* bits, that would yield an easier attack on the combined hash. See <http://allmydata.org/pipermail/tahoe-dev/2009-October/003006.html> . 8. In order for the combined hash with output (*R*,*T*) to have the strength against collision and preimage attacks given here, there must not be multicollision attacks against the hash truncated to *r* bits or to *t* bits, that would yield an easier attack on the combined hash. See [//pipermail/tahoe-dev/2009-October/003006.html tahoe-dev/2009-October/003006.html] .
9. The estimates given here are in terms of work factor, i.e. they are products of machine size and attack time. See [this paper by Dan Bernstein](http://cr.yp.to/snuffle/bruteforce-20050425.pdf) for discussion of parallel brute-force attacks, including attacks against multiple keys at once. Note that the applicability of these multiple-key attacks depends on the encryption mode. CTR mode with a fixed IV would be particularly vulnerable, so I (David-Sarah) think we should use a variable IV. (Bernstein prefers simply to make the key longer, which would be good advice for most protocols, but most protocols don't have the usability constraint of the key length contributing to URL length.) 9. The estimates given here are in terms of work factor, i.e. they are products of machine size and attack time. See [this paper by Dan Bernstein](http://cr.yp.to/snuffle/bruteforce-20050425.pdf) for discussion of parallel brute-force attacks, including attacks against multiple keys at once. Note that the applicability of these multiple-key attacks depends on the encryption mode. CTR mode with a fixed IV would be particularly vulnerable, so I (David-Sarah) think we should use a variable IV. (Bernstein prefers simply to make the key longer, which would be good advice for most protocols, but most protocols don't have the usability constraint of the key length contributing to URL length.)