[6673] in cryptography@c2.net mail archive
Re: Predictable IVs
daemon@ATHENA.MIT.EDU (Steve Reid)
Sun Feb 27 22:29:06 2000
Date: Sun, 27 Feb 2000 15:30:34 -0800
From: Steve Reid <sreid@sea-to-sky.net>
To: Damien Miller <djm@mindrot.org>
Cc: cryptography@c2.net
Message-ID: <20000227153034.A502@grok.localnet>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <Pine.LNX.4.10.10002272331001.737-100000@mothra.mindrot.org>; from Damien Miller on Sun, Feb 27, 2000 at 11:36:17PM +1100
On Sun, Feb 27, 2000 at 11:36:17PM +1100, Damien Miller wrote:
> What risks does using a predictable IV bring?
> Background: I am interested in writing an encrypting swap driver for
> Linux using a fast cipher in CBC mode keyed from /dev/random at boot
> time.
If you just use the block number, there are vulnerabilities when you try
to encrypt data of a form like this:
block 0: 0x123456789abcdef0
block 1: 0x123456789abcdef1
XOR with the block number and you get the same input and output. Anyone
who knows what block 0 is can easily figure out what block 1 is, and
vice versa. I'm not sure what else can be done with this.
The bottom line is that IVs should be random or pseudo-random so that
these things can only occur by random chance. Related IVs are bad
because they are more likely to coincide with structure in the
plaintext.
You should probably do what Matt Blaze did for CFS. ECB-encrypt the
block number under one key (which should be secret but I don't think
needs to be), XOR the plaintext with that, then ECB-encrypt the result
with your secret key. This requires two block encryption operations
instead of one but at least you're doing something that has stood up to
some analysis.
