Changes between Version 54 and Version 55 of NewCaps/WhatCouldGoWrong
- Timestamp:
- 2010-01-05T01:16:33Z (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
NewCaps/WhatCouldGoWrong
v54 v55 4 4 [[Image(http://jacaranda.org/tahoe/immutable-elkpoint-2.png)]] 5 5 6 ||#||''what bad thing could happen''||''how''||''who could do it''||''what could they target''||''what crypto property prevents it''||''how expensive to brute force'' ||6 ||#||''what bad thing could happen''||''how''||''who could do it''||''what could they target''||''what crypto property prevents it''||''how expensive to brute force'' [footnote 9]|| 7 7 ||1||shape-shifter immutable file [footnote 1]||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^ [footnotes 7,8]|| 8 8 ||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'')^|| … … 40 40 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 http://allmydata.org/pipermail/tahoe-dev/2009-October/003006.html . 42 43 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.)
