From 7475c9c6ef07af13bacc75fd239cef0ba5c76f8e Mon Sep 17 00:00:00 2001 From: daira <> Date: Thu, 23 May 2013 18:04:34 +0000 Subject: [PATCH] my name [Imported from Trac: page NewCaps/WhatCouldGoWrong, version 59] --- NewCaps/WhatCouldGoWrong.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/NewCaps/WhatCouldGoWrong.md b/NewCaps/WhatCouldGoWrong.md index f2e92b2..ed7a053 100644 --- a/NewCaps/WhatCouldGoWrong.md +++ b/NewCaps/WhatCouldGoWrong.md @@ -42,4 +42,4 @@ where *k* = bitlength(*K1*), *r* = bitlength(*R*), *s* = bitlength(*S*), *t* = b 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 (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.)