Hi Kenny,

I am glad to see that you enjoyed the discussion more than what you planed for 
the time on your vacation.  We love crypto and the IETF!

From: "Paterson, Kenny" 
Date: Wednesday, February 15, 2017 at 8:46 AM
To: 'Quynh' <quynh.d...@nist.gov<mailto:quynh.d...@nist.gov>>
Cc: Atul Luykx 
<atul.lu...@esat.kuleuven.be<mailto:atul.lu...@esat.kuleuven.be>>, Yoav Nir 
<ynir.i...@gmail.com<mailto:ynir.i...@gmail.com>>, IRTF CFRG 
<c...@irtf.org<mailto:c...@irtf.org>>, "tls@ietf.org<mailto:tls@ietf.org>" 
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs 

Hi Quynh,

I'm meant to be on vacation, but I'm finding this on-going discussion 
fascinating, so I'm chipping in again.

On 15 Feb 2017, at 21:12, Dang, Quynh (Fed) 
<quynh.d...@nist.gov<mailto:quynh.d...@nist.gov>> wrote:

Hi Atul,

I hope you had a happy Valentine!

From: Atul Luykx 
Date: Tuesday, February 14, 2017 at 4:52 PM
To: Yoav Nir <ynir.i...@gmail.com<mailto:ynir.i...@gmail.com>>
Cc: 'Quynh' <quynh.d...@nist.gov<mailto:quynh.d...@nist.gov>>, IRTF CFRG 
<c...@irtf.org<mailto:c...@irtf.org>>, "tls@ietf.org<mailto:tls@ietf.org>" 
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs 

Why is that 2^48 input blocks rather than 2^34.5 input blocks?
Because he wants to lower the security level.

I respectfully disagree. 2^-32, 2^-33, 2^-57, 2^-60, 2^-112 are practically the 
same: they are practically zero.

I'm not clear what you mean by "practically" here.

As far as I know, such chance has not happened in history for any targeted 
search where the chance for hitting the target is 1 in 2^32.

They're clearly not the same as real numbers. And if we are being conservative 
about security, then the extremes in your list are a long way apart.

And, 2^-32 is an absolute chance in this case meaning that all attackers can’t 
improve their chance: no matter how much computational power the attacker has.

A sufficiently powerful adversary could carry out an exhaustive key search for 
GCM's underlying AES key. So I'm not sure what you're claiming here when you 
speak of "absolute chance".

I described my point not in a best way, sorry. For key recovery, if an attacker 
can do 2^96 AES operations, his chance of finding the key is 2^-32, but this 
chance will get improved if the attacker does more computation. On the 
contrary, the chance for the distinguishing attack won’t change with the 
proposed data limit.

I don’t understand why the number 2^-60 is your special chosen number for this ?

This is a bit subtle, but I'll try to explain in simple terms.

We can conveniently prove a bound of about this size (actually 2^-57) for 
INT-CTXT for a wide range of parameters covering both TLS and DTLS (where many 
verification failures may be permitted). Then, since we're ultimately 
interested in AE security, we would like to (roughly) match this for IND-CPA 
security, to get as good a bound as we can for AE security (the security bounds 
for the two notions sum to give an AE security bound - see page 2 of the "AE 
bounds" note).

In view of the INT-CTXT bound there's no point pushing the IND-CPA bound much 
lower than 2^-60 if the ultimate target is AE security. It just hurts the data 
limits more without significantly improving AE security.

I just checked the paper. There is a small error I think. AES-GCM in TLS 1.3 is 
a prf. Under a given key, every input block or just one repeated block 2^35 
times, their ciphertext blocks are 2^35 random 128-bit blocks assuming the key 
has 128 bits of entropy. If there is a collision among the ciphertext blocks, 
it does not mean anything because it does not say anything about the plaintext 

Finally, 2^-60 is not *our* special chosen number. We wrote a note that 
contained a table of values, and it's worth noting that we did not make a 
specific recommendation in our note for which row of the table to select.

(Naturally, though, we'd like security to be as high as possible without making 
rekeying a frequent event. It's a continuing surprise to me that you are 
pushing for an option that actually reduces security when achieving higher 
security does not seem to cause any problems for implementors.)

I respectfully disagree. As I explained before, 2^-32, 2^-57 and 2^-60 are all 
safe choices. If someone wants to rekey sooner (or often) for operational 
reason or any other reason, that would be just fine. I just hope that we don’t 
have text which might imply that 2^-32 is not a safe choice.  In our 
guidelines, we basically indicate that 2^-32 or below is safe.

In your “theory”, 2^-112 would be in “higher” security than 2^-60.

It certainly would, if it were achievable (which it is not for GCM without 
putting some quite extreme limits on data per key).



I am going to propose another option and I hope that you and all other people 
will be happy with.

Thank you and Regards,


The original text
recommends switching at 2^{34.5} input blocks, corresponding to a
success probability of 2^{-60}, whereas his text recommends switching at
2^{48} blocks, corresponding to a success probability of 2^{-32}.


On 2017-02-14 11:45, Yoav Nir wrote:
Hi, Quynh
On 14 Feb 2017, at 20:45, Dang, Quynh (Fed) 
Hi Sean and all,
Beside my suggestion at
https://www.ietf.org/mail-archive/web/tls/current/msg22381.html [1],
I have a second suggestion below.
Just replacing this sentence: "
For AES-GCM, up to 2^24.5 full-size records (about 24 million) may
encrypted on a given connection while keeping a safety margin of
approximately 2^-57 for Authenticated Encryption (AE) security.
" in Section 5.5 by this sentence: " For AES-GCM, up to 2^48
(partial or full) input blocks may be encrypted with one key. For
other suggestions and analysis, see the referred paper above."
I like the suggestion, but I’m probably missing something pretty
basic about it.
2^24.5 full-size records is 2^24.5 records of 2^14 bytes each, or
(since an AES block is 16 bytes or 2^4 bytes) 2^24.5 records of 2^10
Why is that 2^48 input blocks rather than 2^34.5 input blocks?
[1] https://www.ietf.org/mail-archive/web/tls/current/msg22381.html
TLS mailing list

TLS mailing list
TLS mailing list

Reply via email to