From 3f6f99424e71fcfe59defa84bae527595d2ae9a3 Mon Sep 17 00:00:00 2001 From: zooko <> Date: Mon, 14 Jan 2013 02:16:26 +0000 Subject: [PATCH] fix links [Imported from Trac: page NewCaps/WhatCouldGoWrong, version 57] --- NewCaps/WhatCouldGoWrong.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/NewCaps/WhatCouldGoWrong.md b/NewCaps/WhatCouldGoWrong.md index b2f9598..0474317 100644 --- a/NewCaps/WhatCouldGoWrong.md +++ b/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 -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 +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 @@ -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. -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 . +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.)