[Cryptography] Killing two IV related birds with one stone

[Nico Williams]

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
--