tahoe-lafs/trac-2024-07-25
2
0
Issues 1.1k Wiki Activity

footnote about parallel brute-force and multiple-key attacks 

[Imported from Trac: page NewCaps/WhatCouldGoWrong, version 55]
davidsarah 2010-01-05 01:16:33 +00:00
parent 6a7d62a01e
commit 937f77871f
1 changed files with 4 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
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| |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*)^| |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| |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. 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 <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.)