Updated the last checkin "(for Quynh) Limits on Key Usage": #769
Conversation
- corrected arithmetic errors; - clarified normative text; - removed statements that don't seem to be necessary; - consistent with http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf
| probability of success at 1/2^32. The padding {{record-padding}} is | ||
| considered to be a part of plaintext in this section. If the average | ||
| record size in a session is 2^x bytes, the data limit with AES-GCM | ||
| for each key is 2^(52-x) records. |
There was a problem hiding this comment.
I would drop this last sentence on the basis that it is misleading.
There was a problem hiding this comment.
I am OK to drop it.
It's here primarily because I wanted to preserve Quynh's text to the degree I could.
Minimum doesn't work because of Finished. Maximum overestimates. It may not be clear how to estimate Average. In general, I believe that counting in blocks (v.s. records) in the code is the most efficient method to track data limits.
There was a problem hiding this comment.
Yes, I am rounding this down for a few reasons:
- The use of fractional exponents adds unnecessary complexity
- We begin the analysis with somewhat arbitrary assumption of p=1/2^32 that NIST happen to use in SP 800 38D .
- This doesn't consider multi-session collision concerns, e.g. when two AES-128 keys collide
The formula is straightforward: blocks < 2^((128+log2(p))/2).
Because we primarily work in an exponential scale here, 1 bit ~ 100% of error margin. We can tolerate this margin of error because it's widely recognized that rekeying marginally more often doesn't hurt.
Are we OK to keep rounded estimate without additional elaboration?
|
It seems like there are two substantive changes here:
The first of these seems sensible, but the second seems just as unprincipled as our initial selection of 2^{24.5} (which was selected by roughly matching encryption and AE). What's the rationale for 2^{-32} |
|
Correct for your 1, with small caveat that bytes should be rounded up to the nearest block (and thus we have to mention blocks). For your 2: The previous estimate didn't state the security margin used. I used 2^-32 that NIST is using (SP 800-38D). Where did the 2^24.5 come from? As I wrote, the fractional exponent looks overkill on implementation complexity grounds. As the recent SWEET32 attack on 3DES shows, as expected, 2^-1 is the practical value. 2^-10 or 0.1% is what I would use as the lowest margin for 3DES. Anything in the range 2^-32 .. 2^-10 seems OK for AES, but why not go with 2^-32 because NIST already uses it? The only reason I see to accept the higher probability is because we rekey too fast, but this is not the case with 128-bit block ciphers (as it is with 3DES). Do you have a concrete probability / security margin in mind? |
|
2^24.5 is the low entry in the AEBounds paper table 1. I chose it for rough parity with the provided 2^{-57} integrity bound. Given that we have to multiple all these values by the number of extant sessions (S 1.3) 2^{-32} seems fairly aggressive. |
|
As explained before, it does not make a lot of sense to worry about the distinguishing attack for multiple sessions because AES has been used a lot and will be used a lot more and its block size is 128 bits. More than 2^64 blocks of AES have a lot of collisions. In a nutshell, my suggestion for the data limit is ""The limit of total ciphertext under a single key is ( (TLSCipherText.length / 16) / ceiling (TLSCipherText.length / 16) ) . 2^48 128-bit blocks.". It is safe for the chance of a collision below 1/2^32 which is practically zero. |
|
Hi Eric and all, Based on the discussions we have had in the last 2-3 weeks, below is my revised suggestion text. " To use AES-GCM to provide authenticity of authenticated data, content of the plaintext and information leakage [0] protection for the plaintext safely, the limit of total ciphertext under a single key is ( (TLSCipherText.length / 16) / ceiling (TLSCipherText.length / 16) ) times 2^48 128-bit blocks. When the data limit is reached, the chance of having a collision among 128-bit blocks of the ciphertext is below 2^(-32) which is negligible. Since the block size of AES is 128 bits, there will be collisions among different sets of ciphertext from multiple sessions using GCM (or any other modes of AES) when the total amount of the ciphertext of all considered sessions is more than 2^64 128-bit blocks. This fact does not seem to create a practical security weakness of using AES GCM. For ChaCha20/Poly1305, the record sequence number would wrap before the safety limit is reached. See [AEAD-LIMITS] for further analysis. [0]: Information leakage in the context of TLS is a chosen-plaintext distinguishing attack where the attacker provides 2 128-bit plaintext blocks to a GCM encryption engine, after seeing one encrypted block for one of the 2 plaintext blocks, the attacker knows which plaintext block was encrypted. Or, it means that there is a collision among 128-bit blocks of the ciphertext. "
|
|
@ekr, please let me get back to you on your comment. Give me a day or so... |
|
Martin, When the data limit is reached, the collision probability is around 42% times 2^(-32) and that is why I say below 2^(-32). |
|
brainhub, A repeat of (key, IV) is a complete kill for GCM, in TLS 1.3, that is equivalent to a collision in a domain of 2^224 elements which won't happen "any time soon" including the multiple sessions situation. Keeping the chance of a repeat of a (key, IV) below 2^(-32), the total of TLS 1.3 sessions can be 2^192 in total. |
|
Correction: 2^192/2 = 2^96 sessions. |
|
@ekr a day ago wrote:
I see. 2^24.5 records assumes a substantial "Attack Success Probability" at 2^-60 (which then means that fewer bytes can be sent before rekey). 2^-60 is grantees guessing any DES key in one try and I think is excessive. I am not fixated on any given probability, but I think it needs to a reasonable value and this needs to be a single choice. I chose 2^-32. This is about IND-CPA side of the argument. On integrity, or INT-CTXT. The integrity is discussed on p.5 and p.6 of that paper. Assuming that we are capped at the proposed 2^48 cipher blocks (less than 2^64 is what matters here), the paper shows that the formula is simplified as follows. The success probability is then capped by (2^10+1)/2^127 < 1/2^116 for TLS 1.3, which is essentially negligible. Compare this with the assumed 1/2^32 above. For DTLS, which allows unlimited verifications, the formula changes. This is out of scope for this document and I will leave this aside. (However, I ran the numbers and see that for 2^-32 probability one needs v~=2^130 DTLS failed verification attempts, assuming the cap at 2^48 encryption blocks). In summary, I don't see that we need to worry about lower limits due to integrity concerns with DTLS and definitely with TLS 1.3. Encryption data limits are tighter. DTLS may need new language, though, regarding unconstrained failed verifications.
Could you elaborate on your concern here? ( I assume you consider how multiple sessions affect the estimates. Multiple sessions use different keys, but the data limits are per key. In a set of 2^48 AES128-GCM sessions a pair of AES keys will collide with probability 1/2^32. Are you concerned that 2^48 sessions is too low? ) |
|
Martin, As explained above, 2^96 sessions are actually 2^96 pairs of (key, IV), if all TLS 1.3 sessions (of all connections) are configured to be rekeyed too often than needed, not only that no practical security gain can be obtained, we'll also hurt security because that would consume the (key, IV) pair space a lot quicker than needed. |
|
Hi all, For the standard notion, when we talk about distinguishing attacks (indistinguishability) of AES, we treat each element in a set as a 128-bit value because the output of each AES encryption is 128 bits. But, if we treat the output (ciphertext) coming out of an AES engine is a stream of bits, then when we try to distinguish 32 or 64-bit values of the output bits, collisions occur very quickly. But, if somebody cares about distinguishing attacks on 256-bit values (instead of 128-bit values) in the ciphertext, then he/she would not need to worry about a collision until the amount of ciphertext reaches 2^112 256-bit blocks. The point is that it is hard to see if there are any practical consequences from a particular distinguishing attack on 128-bit values of the ciphertext even though when there is a distinguishing attack on a cipher, the guarantee that there won't be any breaks on the cipher (as long as the assumptions underlining the cipher are held and the security proof of the cipher is correct), is broken. |
|
The last paragraph above by @QuynhDangNIST above means that TLS 1.3 sec "5.4. Record Padding" feature is completely broken when there is a distinguishing attack. I also don't follow the argument of simply looking at 2 blocks at a time. The original issue here is that AES, the underlying block cipher of AES-GCM, is a secret permutation on 128 bits. In AES-GCM the input to the AES block cipher permutation is a unique plaintext, which is based on the IV. By definition, the permutation will produce a different value when the input is different (and it always is for AES in AES-GCM, in any given session). This fact is used in a distinguishing attack. Considering a pair of adjacent blocks in an AES-GCM stream is not the right way to look at the problem. We don't get a 256-permutation by adopting this view. There are wide cipherblocks modes exist, e.g. WCFB and related, see references, but we are not doing AES-2x-WCFB-GCM of sort here. Thus, AES-GCM limits need to address the issues of the 128-bit permutation only. |
|
brainhub, I agree with you and with the standard security notion. If you think fully about what I wrote, there was nothing contradicting your view. " The point is that it is hard to see if there are any practical consequences from a particular distinguishing attack... " For example (theoretically for now), plaintext is a string of 64-bit values, the attack is to find out if 2 64-bit values are the same or not (or which 64-bit value is encrypted from 2 chosen 64-bit values). In this case, finding an distinguishing attack on 128-bit output values does not make sense. Similarly, if the values I care are 256-bit values and the plaintext is a string of these values, the attack is to find out if 2 256-bit values are the same or not (or which 256-bit value is encrypted from 2 chosen 256-bit values). In this case, finding an distinguishing attack on 128-bit output values does not make sense. |
|
We can't escape the birthday bound limitation of the AES-GCM mode by considering "virtual" blocks. AES-GCM mode of operation is a mode with a 128-bit internal state, due to the AES block size. The problem is a textbook limitation of a counter mode of operation with a 128-bit block cipher. While GCM seems to have fewer practical problems than CBC at birthday bound limit, this is not good enough. |
|
Agree, many other ciphers can tolerate a lot more ciphertext under a given key than GCM can with regards to keeping distinguishing attacks at zero chance of success practically. |
I kept the content intact, in principle. I will respectfully note that this version is shorter and goes to the point of the problem.