Changes between Version 58 and Version 59 of NewCaps/WhatCouldGoWrong

Timestamp:

2013-05-23T18:04:34Z (11 years ago)

Author:

daira

Comment:

my name

NewCaps/WhatCouldGoWrong

@@ -41 +41 @@
 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.)
+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 (Daira) 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.)