This is about What Could Go Wrong with the "Elk Point 2" immutable file caps: http://jacaranda.org/tahoe/immutable-elkpoint-2.svg

||#||''what bad thing could happen''||''how''||''who could do it''||''what could they target''||''what crypto property prevents it''||''how expensive to brute force''||
||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.||2^(''n''+''t'')/2^||
||2||unauthorized read||attack the encryption of ''K1'' with ''R''||anyone||any one file||the cipher's security and the secrecy of the read-key ''R''||2^''n''^||
||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-pre-image resistance on (''R'',''T'')||2^''n''+''t''^||
||4||roadblock or speedbump [footnote 2]||generate (''K1enc'',''Dhash'',''V'') that hash to someone else's ''T'', and copy their ''S''||anyone||any one file||the hash function's and cap format's collision resistance on ''T''||2^''t''^||
||5||unauthorized read||attack the encryption of the plaintext with ''K1''||anyone||any one file||the cipher's security and the secrecy of the encryption key ''K1''||2^''k''^||
||6||unauthorized read||figure out the input to the hash function that generates ''S''||anyone||any one file||the hash function's pre-image resistance on ''S''||brute force on ''R'' is !#2||
||7||unauthorized deletion||brute force KD||anyone||any one file||secrecy of ''KD''||2^''d''^||
||8||unauthorized deletion||figure out the destroy key KD from Dhash||anyone||any one file||the hash function's pre-image resistance on ''Dhash''||brute force on ''KD'' is !#7||
||9||denial of service||prevent access to servers holding sufficient shares (by controlling some of them, or by attacking them or the network)||anyone||any file||not prevented by crypto||n/a||
||10||cause invalid share to verify||generate (''K1enc'',''Dhash'',''V'') that hash to someone else's (''T'',''U''), and copy their ''S''||anyone||any one file||the hash function's second-pre-image resistance on (''T'',''U'')||2^''t''+''u''^||
||11||undeletion [footnote 3]||restore a deleted file's shares by controlling the relevant servers||anyone||any one file||not prevented by crypto||n/a||
||12||undeletion [footnote 3]||generate matching (''R'',''T'',''U'') for a deleted file||anyone||any one file||the hash function's and cap format's second-pre-image resistance on (''R'',''T'',''U'')||2^''n''+''t''+''u''^||

where ''k'' = bitlength(''K1''), ''n'' = bitlength(''R''), ''t'' = bitlength(''T''), ''u'' = bitlength(''U''), ''d'' = bitlength(''KD'').

1. ''shape-shifter immutable file'': creator creates more than one file matching the immutable file readcap

2. ''roadblock'': attacker prevents uploader (including repairer) from being able to write a real share into the right storage index; ''speedbump'': attacker adds his bogus share into the list of shares stored under the storage index by the same method; downloader has to download, examine, and discard the bogus (''K1enc'',''Dhash'',''V'')'s until it finds the real one

3. ''undeletion'': attacker makes a deleted file (for which it need not have had a read cap) accessible at its previous storage index, and readable by previous read caps

http://allmydata.org/pipermail/tahoe-dev/2009-October/002959.html