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
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
