From 937f77871f0bd944b8c9423cdd5da16c8e8819e8 Mon Sep 17 00:00:00 2001
From: davidsarah <>
Date: Tue, 5 Jan 2010 01:16:33 +0000
Subject: [PATCH] footnote about parallel brute-force and multiple-key attacks

[Imported from Trac: page NewCaps/WhatCouldGoWrong, version 55]
---
 NewCaps/WhatCouldGoWrong.md | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/NewCaps/WhatCouldGoWrong.md b/NewCaps/WhatCouldGoWrong.md
index cfc5b9f..216112e 100644
--- a/NewCaps/WhatCouldGoWrong.md
+++ b/NewCaps/WhatCouldGoWrong.md
@@ -5,7 +5,7 @@ This is about What Could Go Wrong with the "Elk Point 2" immutable file caps: <h
 
 | | | | | | | |
 |---|---|---|---|---|---|---|
-|#|*what bad thing could happen*|*how*|*who could do it*|*what could they target*|*what crypto property prevents it*|*how expensive to brute force*|
+|#|*what bad thing could happen*|*how*|*who could do it*|*what could they target*|*what crypto property prevents it*|*how expensive to brute force* [9]footnote|
 |1|shape-shifter immutable file [1]footnote|collide read-cap (*R*,*T*)|creator of a file|their own file|the hash function's and cap format's collision resistance on the read-cap (*R*,*T*). This also depends on the encryption of *K1* being deterministic and correct, and on the suitability of hash_*r* as a KDF (key derivation function).|approx sqrt(2.*p*).2^(*r*+*t*)/2^ [7,8]footnotes|
 |2|unauthorized read|attack the encryption of *K1* with *R*|anyone|any one file|the security of the encryption scheme used for *K1*, the secrecy of the read-key *R*, and the suitability of hash_*r* as a KDF.|*p*.2^min(*r*,*k*)^|
 |3|forgery of immutable file|generate a matching read-cap (*R*,*T*) for someone else's file|anyone|any one file|the hash function's and cap format's second-preimage resistance on (*R*,*T*). This also depends on the encryption of *K1* being deterministic and correct, and on the suitability of hash_*r* as a KDF.|(*p*/*N*).2^*r*+*t*^ [5,8]footnotes|
@@ -40,4 +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 <http://allmydata.org/pipermail/tahoe-dev/2009-October/003006.html> .
\ No newline at end of file
+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> .
+
+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.)