Hi > On 12 Jul 2016, at 18:57, Dang, Quynh (Fed) <[email protected]> wrote: > > Hi Kenny, > >> On 7/12/16, 12:33 PM, "Paterson, Kenny" <[email protected]> wrote: >> >> Unfortunately, that's not quite the right interpretation. The bounds one >> obtains depend on both the total amount of data encrypted AND the number >> of encryption queries the adversary is allowed to make to AES-GCM under >> the (single) target key. > > My understanding is that the total is the data complexity limit (counting > block encryptions and queries which are also block encryptions).
Yes. And you can approximately convert between them by dividing by the block size (128 bits for AES). > To be > more precise, then we should count data complexity by number of block > encryptions (encrypting 1 bit is 1 block encryption). But for large data > in TLS, encryption is pretty much with full blocks of plaintexts. Yes. For our analysis, we assume 2^14 bytes per record. This equates to a whole number of AES blocks. You can add one more block per record if you want to, to cater for any rounding up, but it makes only a tiny difference to the final bounds. > If the attacker has 2^10 encrypted blocks and is allowed to query another > 2^10 encryptions, then the total data is 2^20 because the total of 2^20 > block encryptions happens. In TLS, it means that 2^20 AES block > encryptions happen. > I'm not sure I understand this. It's perhaps worth rereading what I wrote just below about why we assume 2^14 bytes per record. Cheers, Kenny >> We assumed each record was 2^14 bytes in size to simplify the ensuing >> analysis, and to enable us to focus on how the security bounds then depend >> on the number of records encrypted. See equation (5) and Table 2 in the >> note at >> >> http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf. >> >> In short, the security bound does not necessarily hold for ANY 2^52 >> encrypted data bytes. For example, if the attacker encrypted 2^52 records >> of size 1 (!) then equation (5) would tell us almost nothing useful at all >> about security. >> >> Finally, you write "to come to the 2^38 record limit, they assume that >> each record is the maximum 2^14 bytes". For clarity, we did not recommend >> a limit of 2^38 records. That's Quynh's preferred number, and is >> unsupported by our analysis. >> >> Cheers, >> >> Kenny > > Regards, > Quynh. > > > > > > > > > > > > > > >> >> >> >> On 12/07/2016 16:45, "Scott Fluhrer (sfluhrer)" <[email protected]> >> wrote: >> >>> Actually, a more correct way of viewing the limit would be 2^52 encrypted >>> data bytes. To come to the 2^38 record limit, they assume that each >>> record is the maximum 2^14 bytes. Of course, at a 1Gbps rate, it'd take >>> over a year to encrypt that much data... >>> >>>> -----Original Message----- >>>> From: TLS [mailto:[email protected]] On Behalf Of Dang, Quynh (Fed) >>>> Sent: Tuesday, July 12, 2016 11:12 AM >>>> To: Paterson, Kenny; Dang, Quynh (Fed); Eric Rescorla; [email protected] >>>> Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt >>>> >>>> Hi Kenny, >>>> >>>> The indistinguishability-based security notion in the paper is a >>>> stronger >>>> security notion than the (old) traditional confidentiality notion. >>>> >>>> >>>> (*) Indistinguishability notion (framework) guarantees no other attacks >>>> can >>>> be better than the indistinguishability bound. Intuitively, you can¹t >>>> attack if >>>> you can¹t even tell two things are different or not. So, being able to >>>> say two >>>> things are different or not is the minimal condition to lead to any >>>> attack. >>>> >>>> The traditional confidentiality definition is that knowing only the >>>> ciphertexts, >>>> the attacker can¹t know any content of the corresponding plaintexts >>>> with a >>>> greater probability than some value and this value depends on the >>>> particular >>>> cipher. Of course, the maximum amount of data must not be more than >>>> some limit under a given key which also depends on the cipher. >>>> >>>> For example, with counter mode AES_128, Let¹s say encrypting 2^70 input >>>> blocks with a single key. With the 2^70 ciphertext blocks alone (each >>>> block is >>>> 128 bits), I don¹t think one can find out any content of any of the >>>> plaintexts. >>>> The chance for knowing any block of the plaintexts is >>>> 1/(2^128) in this case. >>>> >>>> I support the strongest indistinguishability notion mentioned in (*) >>>> above, >>>> but in my opinion we should provide good description to the users. >>>> That is why I support the limit around 2^38 records. >>>> >>>> Regards, >>>> Quynh. >>>> >>>> On 7/12/16, 10:03 AM, "Paterson, Kenny" <[email protected]> >>>> wrote: >>>> >>>>> Hi Quynh, >>>>> >>>>> This indistinguishability-based security notion is the confidentiality >>>>> notion that is by now generally accepted in the crypto community. >>>>> Meeting it is sufficient to guarantee security against many other >>>> forms >>>>> of attack on confidentiality, which is one of the main reasons we use >>>> it. >>>>> >>>>> You say that an attack in the sense implied by breaking this notion >>>>> does not break confidentiality. Can you explain what you mean by >>>>> "confidentiality", in a precise way? I can then try to tell you >>>> whether >>>>> this notion will imply yours. >>>>> >>>>> Regards >>>>> >>>>> Kenny >>>>> >>>>> On 12/07/2016 14:04, "TLS on behalf of Dang, Quynh (Fed)" >>>>> <[email protected] on behalf of [email protected]> wrote: >>>>> >>>>>> Hi Eric and all, >>>>>> >>>>>> >>>>>> In my opinion, we should give better information about data limit for >>>>>> AES_GCM in TLS 1.3 instead of what is current in the draft 14. >>>>>> >>>>>> >>>>>> In this paper: http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf, what >>>>>> is called confidentiality attack is the known plaintext >>>>>> differentiality attack where the attacker has/chooses two >>>> plaintexts, >>>>>> send them to the AES-encryption oracle. The oracle encrypts one of >>>>>> them, then sends the ciphertext to the attacker. After seeing the >>>>>> ciphertext, the attacker has some success probability of telling >>>> which >>>>>> plaintext was encrypted and this success probability is in the >>>> column >>>>>> called ³Attack Success Probability² in Table 1. This attack does not >>>>>> break confidentiality. >>>>>> >>>>>> >>>>>> If the attack above breaks one of security goal(s) of your individual >>>>>> system, then making success probability of that attack at 2^(-32) max >>>>>> is enough. In that case, the Max number of records is around 2^38. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> Quynh. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Date: Monday, July 11, 2016 at 3:08 PM >>>>>> To: "[email protected]" <[email protected]> >>>>>> Subject: [TLS] New draft: draft-ietf-tls-tls13-14.txt >>>>>> >>>>>> >>>>>> >>>>>> Folks, >>>>>> >>>>>> >>>>>> I've just submitted draft-ietf-tls-tls13-14.txt and it should show up >>>>>> on the draft repository shortly. In the meantime you can find the >>>>>> editor's copy in the usual location at: >>>>>> >>>>>> >>>>>> http://tlswg.github.io/tls13-spec/ >>>>>> >>>>>> >>>>>> The major changes in this document are: >>>>>> >>>>>> >>>>>> * A big restructure to make it read better. I moved the Overview >>>>>> to the beginning and then put the document in a more logical >>>>>> order starting with the handshake and then the record and >>>>>> alerts. >>>>>> >>>>>> >>>>>> * Totally rewrote the section which used to be called "Security >>>>>> Analysis" and is now called "Overview of Security Properties". >>>>>> This section is still kind of a hard hat area, so PRs welcome. >>>>>> In particular, I know I need to beef up the citations for the >>>>>> record layer section. >>>>>> >>>>>> >>>>>> * Removed the 0-RTT EncryptedExtensions and moved ticket_age >>>>>> into the ClientHello. This quasi-reverts a change in -13 that >>>>>> made implementation of 0-RTT kind of a pain. >>>>>> >>>>>> >>>>>> As usual, comments welcome. >>>>>> -Ekr >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> * Allow cookies to be longer (*) >>>>>> >>>>>> >>>>>> * Remove the "context" from EarlyDataIndication as it was undefined >>>>>> and nobody used it (*) >>>>>> >>>>>> >>>>>> * Remove 0-RTT EncryptedExtensions and replace the ticket_age >>>>>> extension >>>>>> with an obfuscated version. Also necessitates a change to >>>>>> NewSessionTicket (*). >>>>>> >>>>>> >>>>>> * Move the downgrade sentinel to the end of ServerHello.Random >>>>>> to accomodate tlsdate (*). >>>>>> >>>>>> >>>>>> * Define ecdsa_sha1 (*). >>>>>> >>>>>> >>>>>> * Allow resumption even after fatal alerts. This matches current >>>>>> practice. >>>>>> >>>>>> >>>>>> * Remove non-closure warning alerts. Require treating unknown alerts >>>>>> as >>>>>> fatal. >>>>>> >>>>>> >>>>>> * Make the rules for accepting 0-RTT less restrictive. >>>>>> >>>>>> >>>>>> * Clarify 0-RTT backward-compatibility rules. >>>>>> >>>>>> >>>>>> * Clarify how 0-RTT and PSK identities interact. >>>>>> >>>>>> >>>>>> * Add a section describing the data limits for each cipher. >>>>>> >>>>>> >>>>>> * Major editorial restructuring. >>>>>> >>>>>> >>>>>> * Replace the Security Analysis section with a WIP draft. >>>>>> >>>>>> >>>>>> (*) indicates changes to the wire protocol which may require >>>>>> implementations >>>>>> to update. >>>> >>>> _______________________________________________ >>>> TLS mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
