Re: [Cryptography] Killing two IV related birds with one stone
On Wed, Sep 11, 2013 at 06:51:16PM -0400, 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.
The first bird is the obvious one: we now know IVs are unpredictable
and will not repeat.
The second bird is less obvious: we've just gotten rid of a covert
channel for malicious hardware to leak information.
I like this, and I've wondered about this in the past as well. But note
that this only works for ordered {octet, datagram} streams. It can't
work for DTLS, for example, or GSS-API, or Kerberos, or ESP,
This can be implemented today anywhere that explicit IVs are needed;
there's only a need for the peer to know the seed if they need to be
able to verify that you're not leaking through IVs. Of course, we
should want nodes to verify that their peers are not leaking through
IVs.
There's still nonces that are needed at key exchange and authentication
time that can still leak key material / PRNG state. I don't think you
can get rid of all covert channels... And anyways, your peers could
just use out-of-band methods of leaking session keys and such.
BTW, Kerberos generally uses confounders instead of IVs. Confounders
are just explicit IVs sent encrypted. Confounders leak just as much
(but no more) than explicit IVs, so confounding is a bit pointless --
worse, it wastes resources: one extra block encryption/decryption
operation per-message.
Nico
--
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Killing two IV related birds with one stone
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
Re: [Cryptography] Killing two IV related birds with one stone
On Wed, 11 Sep 2013 20:01:28 -0400 Jerry Leichter leich...@lrw.com wrote: ...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? Certainly, but if you remove most or all covert channels, you've narrowed the problem down to auditing the RNG instead of having to audit much more of the system. It is all a question of small steps towards better assurance. No one measure will fix everything. -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
