Dear TLS list,
Sitting in Santa Barbara I have just learned that our nonce randomization
does slightly better then GCM in the multiuser setting. However, XGCM would
produce even better security.
XGCM is GCM with masking applied to blocks before and after each
encryption. It can be implemented on t
Sadly, you can't implement XGCM using an existing AES-GCM API, because of the
way the MAC (which is keyed) is computed over the ciphertext in the standard
GCM scheme.
This does not contradict what you wrote, but may be a barrier to adoption.
Cheers
Kenny
On 15 Aug 2016, at 16:40, Watson Ladd
That's https://eprint.iacr.org/2016/564 for those who'd like to see the
research (Mihir Bellare and Björn Tackmann).
Bodo
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
I wanted to explain that on my final slide but then ran over time. It is
discussed in the paper, though. Sorry for the confusion.
Best,
Bjoern
> On Aug 15, 2016, at 4:46 PM, Paterson, Kenny
> wrote:
>
> Sadly, you can't implement XGCM using an existing AES-GCM API, because of the
> way the
Hello all,
After our discussion in Berlin, I wanted to try to rally consensus
over adding an explicit receive_generation field to the TLS 1.3
KeyUpdate message.
The KeyUpdate message allows one side of the connection to instruct
the other to:
1) increment the receive-key generation,
2) de-trust
On 16 August 2016 at 09:46, Paterson, Kenny wrote:
> Sadly, you can't implement XGCM using an existing AES-GCM API, because of
> the way the MAC (which is keyed) is computed over the ciphertext in the
> standard GCM scheme.
Is there a reason why you can't simply XOR the plaintext stream that
is
