Re: crypto(4) and IVs

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

>> 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
save you.

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               mouse%rodents.montreal.qc.ca@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B