All,
Thank you for your input on this errata report and apologies for the delayed
reply.
We have updated as requested. As this thread involved a number of responses,
please review the text as it currently appears at
http://www.rfc-editor.org/errata_search.php?rfc=5288&eid=4694 and let us know
> On 14 Jun 2016, at 19:25, Joseph Lorenzo Hall wrote:
>
> s/it's/its/ in one place in your errata text, Aaron.
Thank you. I suggest the RFC Errata editors change text and further
additions/recommendations by others along the way when publishing (if that's
the right way to proceed, I'm quite
s/it's/its/ in one place in your errata text, Aaron.
On Tue, Jun 14, 2016 at 5:04 AM, Aaron Zauner wrote:
> Hi,
>
> It's been a few weeks. We by now know of at least one other affected vendor.
> I think this errata is valid and should be accepted. I'll take any feedback
> and improvements if va
Hi,
It's been a few weeks. We by now know of at least one other affected vendor. I
think this errata is valid and should be accepted. I'll take any feedback and
improvements if valid.
Aaron
signature.asc
Description: Message signed with OpenPGP using GPGMail
__
Hi,
> The first step of our attack involves attacker controlled content. So yes
> (phishing, unauthenticated HTTP, selective company DPI etc.). In our example
> we use a local proxy to carry out the attack. I hope I can post a full
> version of the actual paper and PoC to this thread soon.
htt
Hi Kenny,
> On 16 May 2016, at 17:24, Paterson, Kenny wrote:
>
> Good to get this cleared up. Yes, it's eminently practical to recover the
> two plaintexts from their XOR assuming you have a good language model
> (e.g. one can use a Markov model with a suitable memory length; this would
> work f
Hi
On 16/05/2016 11:15, "Aaron Zauner" wrote:
>Hi Kenny,
>
>> On 16 May 2016, at 16:48, Paterson, Kenny
>>wrote:
>>
>> Maybe the confusion is this: in your authenticity attack, you do recover
>> the GHASH key, and the effect is catastrophic. In the confidentiality
>> attack, one can recover pl
Hi Kenny,
> On 16 May 2016, at 16:48, Paterson, Kenny wrote:
>
> Maybe the confusion is this: in your authenticity attack, you do recover
> the GHASH key, and the effect is catastrophic. In the confidentiality
> attack, one can recover plaintexts for the records with repeated nonces,
> but not t
Hi
On 16/05/2016 10:37, "Aaron Zauner" wrote:
>Hi Kenny,
>
>> On 16 May 2016, at 16:18, Paterson, Kenny
>>wrote:
>>
>> Hi Aaron,
>>
>> If AES-GCM ever generates two ciphertexts using the same key and the
>>same
>> 96-bit nonce, then the underlying CTR-mode keystreams will be the same.
>> XORi
Hi Kenny,
> On 16 May 2016, at 16:18, Paterson, Kenny wrote:
>
> Hi Aaron,
>
> If AES-GCM ever generates two ciphertexts using the same key and the same
> 96-bit nonce, then the underlying CTR-mode keystreams will be the same.
> XORing the ciphertexts together then produces the XOR of the plain
Hi Aaron,
If AES-GCM ever generates two ciphertexts using the same key and the same
96-bit nonce, then the underlying CTR-mode keystreams will be the same.
XORing the ciphertexts together then produces the XOR of the plaintexts,
from which the two individual plaintexts can be recovered (usually) w
Hi,
In the TLS case, RFC5288 defines the following IV construction (Section 3):
```
struct {
opaque salt[4];
opaque nonce_explicit[8];
} GCMNonce;
The salt is the "implicit" part of the nonce and is not sent in the
packet. Instead
> On 16 May 2016, at 6:50 AM, Atul Luykx wrote:
>
> Here's a possible re-write of the second paragraph:
>
> Nonce re-use in AES-GCM results in failure of both confidentiality and
> authenticity. Not only will confidentiality be breached by leaking the XOR of
> any two packets processed under
Atul Luykx writes:
>Here's a possible re-write of the second paragraph:
That looks good.
Peter.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Here's a possible re-write of the second paragraph:
Nonce re-use in AES-GCM results in failure of both confidentiality and
authenticity. Not only will confidentiality be breached by leaking the
XOR of any two packets processed under the same nonce, but TLS sessions
can also be attacked through
Aaron Zauner writes:
>If so, could you suggest better wording for this specific paragraph?
I would just leave it as "nonce", with no attempt at a definition. If there
are any cryptographers who don't know what a nonce is they can look it up. If
they use an authoritative source they'll get the
The way I read the first draft, the wording made it sound like "nonce" was
a contraction of the words "(N)umber used (once)". I thought I learned
something. Then I looked it up, and unfortunately, that is not the case, as
cute as it would be.
That is the problem with the wording. Even if a nonce i
On Sun, May 15, 2016 at 11:43 AM, Rick van Rein
wrote:
> Hi,
>
> > I think the erratum needs an erratum. Firstly, "nonce" doesn't mean
> "number
> > used once", and secondly nonce re-use in AES-GCM doesn't just result in
> > "catastrophic failure of it's authenticity", it results in catastrophic
On Sun, May 15, 2016 at 6:50 AM, Aaron Zauner wrote:
> I know that the word "nonce" does have another meaning as well (BTW I'm
> not a native english speaker, as you may have guessed). But do you think
> that is really relevant in this case? If so, could you suggest better
> wording for this spec
On Sun, May 15, 2016 at 3:52 PM, Peter Gutmann
wrote:
> Aaron Zauner writes:
>
> >What do you think nonce stands for?
> >https://en.wikipedia.org/wiki/Cryptographic_nonce
>
> Well there's your first mistake, you're using Wikipedia as a reference.
> "nonce" is from medieval English, and predates
Hi,
On May 15, 2016 10:28, "Peter Gutmann" wrote:
>
> RFC Errata System writes:
>
> >The following errata report has been submitted for RFC5288, "AES Galois
> >Counter Mode (GCM) Cipher Suites for TLS".
>
> I think the erratum needs an erratum.
No problem, but:
>Firstly, "nonce" doesn't mean "n
Aaron Zauner writes:
>What do you think nonce stands for?
>https://en.wikipedia.org/wiki/Cryptographic_nonce
Well there's your first mistake, you're using Wikipedia as a reference.
"nonce" is from medieval English, and predates modern cryptography and IVs by
about 800 years.
>In TLS nonce reuse
Hi,
> I think the erratum needs an erratum. Firstly, "nonce" doesn't mean "number
> used once", and secondly nonce re-use in AES-GCM doesn't just result in
> "catastrophic failure of it's authenticity", it results in catastrophic
> failure of the entire mode, both confidentiality and integrity/au
RFC Errata System writes:
>The following errata report has been submitted for RFC5288, "AES Galois
>Counter Mode (GCM) Cipher Suites for TLS".
I think the erratum needs an erratum. Firstly, "nonce" doesn't mean "number
used once", and secondly nonce re-use in AES-GCM doesn't just result in
"cat
The following errata report has been submitted for RFC5288,
"AES Galois Counter Mode (GCM) Cipher Suites for TLS".
--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5288&eid=4694
--
Ty
25 matches
Mail list logo