Subject: [TLS] shibboleth and the nonce

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Jul 2014 11:21:00 -0700

(No, that's not a proposed prog-synth-death-polka band name.)

The arguments around the way that explicit/implicit nonces interact
with certification were, I thought, already exhausted.  So I'd like to
see if some points can be clarified:

As far as I am aware, there are no concrete concerns about implicit
nonces from a straight-up security perspective.  Is that right?

If the concerns are solely around the certification of crypto modules,
then we need more information to be able to make a rational decision
here.

If the static inputs are keys, and the per-record inputs are nonce +
ad + plaintext, I see no problem.

The previous response to suggestions that the nonce was a required
input was to have a counter produce the nonce input, with a matching
counter and validation in the module.

The new information yesterday was that David McGrew suggested that the
nonce needed to be arbitrary.  In that case, do we actually need the
input to be validated?  Does the certification process check that the
module produces different output for different nonces by starting
separate module instances with the same values for all other inputs
(keys, ad, and plaintext) then varying the input nonces?

I'm sure that there are other concerns, but it's hard for me to make
an assessment based on the information made available thus far.

---

From: Adam Langley <[email-masked]>
Date: Thu, 24 Jul 2014 12:05:03 -0700

> nonces from a straight-up security perspective.  Is that right?

For polynomial MACs, no. (For CBC mode, yes.)

> an assessment based on the information made available thus far.

I'm not sure that I understand David McGrew's reported suggestion here.

I thought that the concern was that the "crypto module" (being the
thing that is validated) needs to ensure that nonces don't repeat
because the security of the system should be a property of the crypto
module alone.

In that case, the module can either generate random nonces itself, or
it can use a counter. In either case, the nonce isn't an input to the
module when encrypting. If it were then, in order to establish
uniqueness, the module would need to remember a list of all previous
nonces.

With AES-GCM, the nonces are explicit which allows the crypto module
to generate them itself and report them to the TLS layer for
transmission. With implicit nonces, the crypto module can use a
counter and the counter keeps in sync with the TLS sequence number.

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: Andy Lutomirski <[email-masked]>
Date: Thu, 24 Jul 2014 14:13:04 -0700

> counter and the counter keeps in sync with the TLS sequence number.

Would it be practical for the crypto module to have an interface
"encrypt this payload; choose your own nonce, but that nonce had better
be X"?

The implicit nonce (for AES-GCM, anyway) is a *counter*.  Surely the
crypto module and the TLS stack can agree on how to increment a number.

--Andy

---

From: Michael StJohns <[email-masked]>
Date: Thu, 24 Jul 2014 17:34:29 -0400

> >thing that is validated) needs to ensure that nonces don't repeat

To be pedantic - it's important the the combination of key + nonce 
doesn't repeat.  If you change the key, you can reuse the nonce and vice 
versa.

Mike