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
TLS WG,
(Cc AVTCORE WG)
When AVTCORE run a WG last call earlier this year on "Multiplexing
Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension
for Datagram Transport Layer Security (DTLS)":
https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5764-mux-fixes/
There was se
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
