[lkml]   [2000]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: A patch to loop.c for better cryption support
Ingo Rohloff  wrote:
> As an example, it is not true that CBC encryption
> can use an arbitrary nonce initialization vector: it is essential
> that the IV be unpredictable by the adversary. (To see this, suppose
> the IV is a sequence number: 0, 1, 2, ... . Then a (first) encryp-
> tion of 0x0000000000000000 followed by an encryption of
> 0x0000000000000001 is recognizably distinct from a (first) encryption
> of 0x0000000000000000 followed by an encryption of
> 0x0000000000000000. Clearly this violates violates the notion of a
> secure encryption sketched in Section 2.)
>So I think what is written in "Applied Cryptography" (by Bruce Schneier)
>is correct. A sequence is ok, as long as you can't predict the start
>of the sequence.

No, a sequence is not ok, even if the beginning is unpredictable.
Why? The encryption of 0 with IV v followed by encryption of 1 with IV v+1
is distinguishable from the reverse. (Because, with high probability,
v and v+1 differ only in their low bit.)

The problem is that the patterns in the IV sequence can interact with
patterns in the plaintext. And, if the plaintext is patterned (e.g.,
ASCII-encoded English), there is a reasonable chance that you can get
two plaintexts which start with blocks that differ only in their low
bit; and this is the case that leads to the bad interaction, when you
use a counter as your IV sequence.

Using SHA1(sector #) should be ok, as long as you don't expect your
plaintexts to have similar patterns. (If you do think your plaintexts
might begin with the SHA1-hashes of sector numbers, you could use a
"keyed hash", or more precisely, a pseudorandom function. For instance,
you could encrypt the sector number using a secret IV-generation key.)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:45    [W:0.052 / U:2.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site