|
|
|
|
|
|
by tptacek
4009 days ago
|
|
|
I don't have the brainpower to really answer this. A couple observations: * You can design around needing a random IV by manipulating keys and message contents; as you note, the IV is a formalism. CBC doesn't simply explode if you repeat an IV. * I am generally skeeved out by systems that use hashes of messages as parameters. Another common species of custom crypto scheme does a similar trick but uses the hash as a key. * This also gets into the subtleties of IVs and nonces. You want an IV to be unpredictable, and you want a nonce to be unique. An IV that is the hash of a message is probably predictable (and perhaps testably so). The way CBC tends to fail with IV problems is that it turns back into ECB mode; the way ECB fails is by allowing attackers to carefully pick blocks based on combinations of known and unknown plaintext. It would depend a lot on the system. I'm also not sure what the win here is in deriving the IV from the message, as opposed to just making it random. |
|
|
If a random IV were used, then there would have to be some other mechanism to detect attempts to store duplicate strings. Perhaps a table that maps hashes of already stored plaintext strings to the row ID of the encrypted string.
I don't like that, because if someone is able to steal a copy of the database, they have hashes of all the stored strings. I guess that could be dealt with by using HMAC for these hashes instead of just a plain hash.
There is a lot less discussion on the net (at least that I could find) of using IVs derived from the message than I would have expected, since it has to be about the first thing anyone thinks of when they want identical plaintext to produce identical ciphertext. The most direct discussion seems to be in Thomas Pornin's comments on his answer in this stackoverflow discussion: http://stackoverflow.com/questions/4608489/how-to-pick-an-ap...