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