Re: [PATCH] Delete cryptoloop

Christophe Saout
2004-07-30T13:13:51Z

[-- Attachment #1: Type: text/plain, Size: 2083 bytes --]

Am Donnerstag, den 29.07.2004, 14:15 -0700 schrieb David Wagner:

> > IV = sector number (little endian, 32 bits), pad with zeroes
> > The actual content is then encoded using the selected cipher and key in
> > CBC mode.
> > C[0] = E(IV xor P[0])
> > C[1] = E(C[0] xor P[1])
> > ...
>
> Ok, that's what I thought. The above is pretty good, but does have some
> weaknesses due to the IV selection. CBC mode needs uniformly random IVs
> for security; using a counter can cause occasional information leakage.

Yes, we already identified this problem.

> You can see that the information leakage is typically modest and limited;
> in many cases, there might be no leakage at all. Nonetheless, this is
> not an ideal situation. As a cryptographer, one would usually consider
> this a flawed design (primarily because it is so easy to do better).
> There are known ways to prevent this attack; for instance, IV = E(sector
> number) or IV = HMAC(sector number) should be much better.

Exactly.

But we identified more problems (I don't if these are all real issues).

Assuming the attacker has access to both plaintext and the encrypted
disk. (shared storage, user account on the machine or something)

A simple one is if you set a sector to all zeroes, due to CBC you get
tons of plaintext-encrypted pairs on the encrypted disk.

One problem would be that if he modifies a sector only the rest of that
sector changes, starting from the block he changed.
Since CBC uses C[n] = E(C[n-1] xor P[n]) he could set P[n] = C[n-1] and
then has C[n] = E(0) which could be precomputed.

This can't happen if the IV also depends on the sector content, like IV
= HMAC(sector number, P[1 .. n-1])

Or if the attacker can copy around sectors on the encrypted side (shared
storage) from one location to another location where he has read access
on the machine that can decrypt the data, he can simply read the data
except for the first block (if secured by an "random" IV). This can't be
avoided when using CBC and a single key for every sector.

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]