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 09/12/2013 03:15 AM, Perry E. Metzger wrote: On Wed, 11 Sep 2013 20:01:28 -0400 Jerry Leichter 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. IMO going through hoops to try to avoid covert channels is not worth our time. Both IPsec and TLS have a huge capacity for covert channels at the handshake (or key exchange) level, certainly enough to leak the *previous* session state. So plugging the per-record (per packet) holes is not interesting. These are living protocols, and extensions create an infinite amount of redundancy. If you try to eliminate covert channels you need to freeze the protocol and engineer it specifically for that purpose. This may be right for a project like Tor, but not for a general purpose protocol. Thanks, Yaron ___ 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 Thu, 12 Sep 2013 17:41:56 +0300 Yaron Sheffer wrote: > On 09/12/2013 03:15 AM, Perry E. Metzger wrote: > > On Wed, 11 Sep 2013 20:01:28 -0400 Jerry Leichter > > 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. > > IMO going through hoops to try to avoid covert channels is not > worth our time. Both IPsec and TLS have a huge capacity for covert > channels at the handshake (or key exchange) level, certainly enough > to leak the *previous* session state. So plugging the per-record > (per packet) holes is not interesting. I think that's being overly pessimistic. Again, plugging most holes means that you get to examine less of the implementation (including hardware) to gain assurance. Further, there are protocols and uses for these algorithms in the world other than IPsec and TLS. > These are living protocols, and extensions create an infinite > amount of redundancy. "Infinite" is a big number. I'd say, again, that if you can lower the number of side channels down to a couple, it helps someone having to do the auditing later. Just because it is hard to eliminate everything a priori is no reason to throw up your hands and make a protocol less verifiable to someone who has to walk through the implementation carefully later on. > If you try to eliminate covert channels you need to freeze the > protocol and engineer it specifically for that purpose. This may be > right for a project like Tor, but not for a general purpose > protocol. We no longer have the luxury of saying "this protocol isn't important enough to secure well", especially for TLS and IPsec. If the last few weeks have taught us anything, it is that we have not been exercising enough care in doing our work here, and as security engineers I think we have a duty to be better than that. Indeed, especially in the face of the knowledge that we have saboteurs working in protocol standardization who would discourage us from taking enough care, we need to be far more careful. -- Perry E. Metzgerpe...@piermont.com ___ 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 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
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
[Cryptography] Killing two IV related birds with one stone
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. 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. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
