Regarding attacks which insert chosen data:
Agreed, loop-AES (and all other block-level-encryption methods I know about)
do not protect against this attack, and were not designed to do so.
It raises an interesting attack:
1. Disk is encrypted
2. Inserted data satisfies watermark of
(copyrighted material, top-secret plans, whatever)
3. Victim must reveal encryption keys to prove they do not
have watermarked data.
The idea here is to insert a bit of data anywhere in the encrypted area that
will cause a "hit" for someone scanning for watermarks.
If the attacker inserted a plain-text document into the partition, it would
stand out as plaintext. The attacker can insert an encrypted document, which
will look like it belongs to the victim.
Victim could reveal encryption keys, show that with those keys the
watermarked document is still ciphertext (as the victim's key is not the
same as the attacker's key. If the attacker could insert data with the
victim's key then this attack is not necessary.)
~boyd
Boyd Waters
Socorro, New Mexico
On 1/20/05 1:32 PM, "Jari Ruusu" <jariruusu@xxxxxxxxxxxxxxxxxxxxx> wrote:
> jerome etienne wrote:
>> well it is a valid argument if you assume the OS has been corrupted.
>> Nevertheless this assumption isnt mandatory, here is a scenario where it
>> doesnt apply:
>> 1. a user encrypt a whole removable disk with loop-aes
>> 2. he goes in a conference and leave it unattended in a room (bad
>> practice but it happen)
>> 3. an attacker gets it, insert chosen data in it and put it back
>> 4. the user replugs the removable device
>>
>> => with the current loop-aes, the attack succeed
>> o the modification goes undetected and the user uses attacker's data
>> as if they were legitimate.
>
> Only if the user failed to RTFM.
>
> loop-AES' README clearly states that it does not authenticate ciphertext,
> and as such, does not protect against ciphertext tampering attacks.
-
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/
