Re: crypto(4) and IVs

der Mouse <[email protected]>
Newsgroups gmane.os.netbsd.devel.crypto
Message-ID <[email protected]>
>> 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	       [email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.