Subject: Re: crypto(4) and IVs
To: None <tech-crypto@NetBSD.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 05/29/2005 00:41:20
>> I find that when I do a CIOCCRYPT, the IV is not modified. How am I
>> supposed to get the correct IV for my next call? Do I have to go
>> under the hood and "know" that for the cipher I'm using (3DES_CBC)
>> it's the last block of the encrypted data (output for ENCRYPT, input
>> for DECRYPT)? Or is there something I'm missing?
> In fact, the interface should not do that. There are a number of
> subtle attacks possible if the IV is predictable by the enemy; thus,
> in things like packet-oriented crypto, you should *not* use the last
> block of the previous message as the IV for the next message.
I didn't say anything about packet-oriented. For many cases - such as
encrypting a stream of data in CBC mode one bufferful at a time - you
_do_ want that. For the cases where you don't, I can't see any harm in
returning it (except possibly the minor inconvenience of having to keep
a separate IV buffer around).
And since I can't see any way short of going under the hood - wiring
algorithm-specific knowledge into the code - to figure out what the
next IV should be when you _do_ want to process a single effective
buffer as multiple physical buffers, I think it should do that.
The only downside I can see is that it may tempt people who don't know
what they're doing to design protocols vulnerable to such attacks. But
if you've got a protocol designer who designs crypto protocols based on
what's easy to code using a particular interface, you're dealing with a
sufficient lack of crypto clue that I doubt any interface design will
As it happens, the use I expect to make of it _will_ be
packet-oriented, but the protocol is already designed and frozen; in
order to interoperate using 3des-cbc at all, I have to implement that
kind of IV chaining. All this interface achieves is to make my life as
an implementer harder; it does not make any security difference at all.
In passing, I have to wonder whether you were just being careless with
language when you wrote "predictable". Chained CBC does not produce a
predictable IV; it produces an unpredictable IV which it then reveals.
Against an adaptive chosen plaintext attack, there is no practical
difference, but against most weaker threat models, I see no reason to
think the difference is unimportant.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML email@example.com
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B