>>n 16 byte blocks on disk where data is encrypted ONLY with K1
The second block is already tweaked with I=1, making the encryption
dependent on K2. Only the 16-byte block with I=0 is encrypted alone
with K1, that is one 16-byte block per disk drive (or key scope). If
there are many drives using the same K1 key (which should not happen,
being bad practice), and an attacker knows which ones, and he has the
ability to put every one of them on a spin stand, then he can gain a
few plaintext/ciphertext pairs corresponding to the same, unknown key
K1. If AES was so weak that this few pairs presented some security
problems, we had to replace AES with something else, anyway.
Laszlo
> -------- Original Message --------
> Subject: Re: LBA-to-I mapping & key scopes
> From: Michael Torla <[EMAIL PROTECTED]>
> Date: Fri, December 16, 2005 12:18 pm
> To: [EMAIL PROTECTED], [EMAIL PROTECTED]
>
> Colin Sinclair wrote: this opens the door for an easy attack on
> the AES to get K1.
> If there was a weakness in AES in ECB mode. None is known, so there is
> no argument against allowing I = 0.
>
> If you have enough plaintext/ciphertext pairs with the same key, this starts
> opening doors. For the
> ease of avoiding I=0, I think it should be done. There is nothing in the
> original "LRW" paper which
> describes such a problem, but then neither does it specify the use of a GF
> multiply to implement the
> function T = h(I) chosen from family of hash functions H (by virtue of
> changing K2). Because h(0) ==
> 0 whatever h (ie K2) is chosen, this may invalidate the security proof for
> LRW? I don't know, this
> is beyond me! I agree with Colin. Recall that I is the index within the
> scope of the second key K2. In a system with multiple K2's {K2_1 .. K2_n},
> that leads to n 16 byte blocks on disk where data is encrypted ONLY with K1.
> Given that data is at rest, this concerns me.
>
> Although I am aware of no attacks on AES-ECB today, one may be identified in
> the future. I should think it would be desirable to make the LRW somewhat
> stronger than the base cryptographic algorithm if possible.
>
> mt
>
