Atul, Kenny,
Thanks for doing this. My initial impression is that these results are
uncomfortably
close to the line for AES-GCM, especially for the scenario where we have
multiple
keys: there are probably well upward of 2^{32} HTTPS connections a day.
A few questions:
1. As I understand it, failure in these models is fairly catastrophic,
so I should be reading Table 1 as "chance of total collapse of
confidentiality",
not "chance of being able to read one plaintext" value. Is that correct?
2. Are there available proofs for a non-chosen plaintext context? This seems
to bear on the multiple key question: it seems plausible that an attacker
could
capture a very large number of AES-GCM encrypted connections passively,
but collecting a huge number of AES-GCM connections where it gets to
specify the plaintexts seems more challenging, even with BEAST-style
attacks.
3. Naively, from equation 5, it seems like as \sigma >> q you should be able
to encrypt rather more submaximal (e.g., 1K) records than maximal size
records.
Finally, and this calls for an opinion: do you believe that given these
results
we should include a KeyUpdate feature in TLS 1.3?
Thanks,
-Ekr
On Tue, Mar 8, 2016 at 2:16 PM, aluykx <[email protected]> wrote:
> Kenny Paterson and I prepared a document providing an overview of how much
> data ChaCha20+Poly1305 and AES-GCM can process with a single key. Besides
> summarizing the results, the document also gives an explanation of why the
> limits are there. The document confirms the analysis done by Watson and
> others in the thread on "Data Volume Limits", but goes into more detail.
>
> The document can be found on Kenny's website:
> http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf
>
> Atul Luykx
>
> _______________________________________________
> TLS mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
