Changes between Version 56 and Version 57 of NewCaps/WhatCouldGoWrong

Timestamp:

2013-01-14T02:16:26Z (11 years ago)

Author:

zooko

Comment:

fix links

NewCaps/WhatCouldGoWrong

@@ -27 +27 @@
 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
@@ -39 +39 @@
 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 [http://cr.yp.to/snuffle/bruteforce-20050425.pdf this paper by Dan Bernstein] 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.)