[Cryptography] Killing two IV related birds with one stone

[Jerry Leichter]

On Sep 11, 2013, at 6:51 PM, Perry E. Metzger wrote:
> It occurs to me that specifying IVs for CBC mode in protocols
> like IPsec, TLS, etc. be generated by using a block cipher in counter
> mode and that the IVs be implicit rather than transmitted kills two
> birds with one stone.
Of course, now you're going to need to agree on two keys - one for the main cipher, one of the IV-generating cipher.  Seems like a great deal of trouble to go to to rescue a mode with few advantages.  (Perry and I exchanged some private mail on this subject.  He claims CBC has an advantage over CTR because CTR allows you to deterministically modify the plaintext "under" the encryption.  I used to favor CBC for that reason as well, though in fact you can modify the text anyway by replaying a previous block - it's just harder to control.  I've become convinced, though, the CBC without authentication is way too insecure to use.  Once you require authentication, CBC has no advantages I can see over CTR.)

But if you insist on CBC ... it's not clear to me whether the attack in Rogoway's paper goes through once authentication is added.  If it doesn't, E(0) does just fine (and of course doesn't have to be transmitted).

> ...Note that if you still transmit the IVs, a misimplemented client
> could still interoperate with a malicious counterparty that did not
> use the enforced method for IV calculation. If you don't transmit
> the IVs at all but calculate them, the system will not interoperate if
> the implicit IVs aren't calculated the same way by both sides, thus
> ensuring that the covert channel is closed.
Ah, but where did the session and IV-generating keys come from?  The same random generator you now don't trust to directly give you an IV?

                                                        -- Jerry