Hey Martin,
You're right, this analysis works for any block cipher with 128 bit
output that is "good enough" (a pseudorandom permutation), and so for
all versions of AES regardless of the key size. Determining the
appropriate key size for the block cipher relies on accounting for
possible att
On 9 March 2016 at 09:16, aluykx 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 docu
* aluykx [23/03/2016 09:12:02] wrote:
> >Finally, and this calls for an opinion: do you believe that given these
> >results
> >we should include a KeyUpdate feature in TLS 1.3?
>
> Ideally it would be better to include a KeyUpdate feature, but the added
> complexity could risk introducing vulnera
Hey,
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?
Actually, confidentiality will not collapse, the limit indicate
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, fai
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
