Re: [Cfrg] new authenticated encryption draft

Steven M. Bellovin writes:
> Many people have made similar proposals; others disagree -- there's a
> layering issue here that might impact security.

No, there isn't. Nonces used to recognize out-of-order packets have a
security requirement, no matter what layer they're in: they _must_ be
generated in increasing order. Nonces used as MAC inputs also have a
security requirement, no matter what layer they're in: they _must_ be
unique.

In an efficient protocol, these nonces are unified. There's one piece of
security-critical code generating one nonce in increasing order. In an
inefficient protocol, these nonces are separated, and there are two
pieces of security-critical code generating the two nonces.

> Let me give a slightly -- but only slightly -- contrived example.  Suppose
> you had a site-to-site VPN, where the encryptor used counter mode driven
> by the TCP sequence number.

The TCP sequence number isn't a nonce; it repeats. The TCP sequence
number is the _bottom 32 bits_ of a nonce _for one connection_ (plus an
irrelevant offset). The nonce is, as I said before, the number of bytes
transmitted through the connection. It's safe to use this nonce to
encrypt those bytes in counter mode under a connection-specific key.

---D. J. Bernstein, Professor, Mathematics, Statistics,
and Computer Science, University of Illinois at Chicago

_______________________________________________
Cfrg mailing list
Cfrg@ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg