Subject: [TLS] Randomization of nonces

From: Watson Ladd <[email-masked]>
Date: Mon, 15 Aug 2016 16:40:11 -0700

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 top counter mode and GHASH easily.

As an alternative we could use 256 bit keys.

Sincerely,
Watson Ladd

---

From: "Paterson, Kenny" <[email-masked]>
Date: Mon, 15 Aug 2016 23:46:25 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

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 top counter mode and GHASH easily.

Sincerely,
Watson Ladd

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 16 Aug 2016 01:50:43 +0200

That's https://eprint.iacr.org/2016/564 for those who'd like to see the
research (Mihir Bellare and Björn Tackmann).

Bodo

---

From: Björn Tackmann <[email-masked]>
Date: Mon, 15 Aug 2016 17:34:38 -0700

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 <[email-masked]> wrote:
> 
> On 15 Aug 2016, at 16:40, Watson Ladd <[email-masked]> wrote:
> 
>> Dear TLS list,
>> [email-masked]
> [email-masked]

---

From: Martin Thomson <[email-masked]>
Date: Tue, 16 Aug 2016 14:56:06 +1000

On 16 August 2016 at 09:46, Paterson, Kenny <[email-masked]> 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 fed to AES-GCM?

We set N = N XOR HKDF(IKM, salt, label[N], 12), which the paper shows
improves things.  If we also set P = P XOR repeat(HKDF(IKM, salt,
label[P], 16)) would we gain any of the advantages of XCAU?  That
change could be made without needing a new algorithm.

---

From: Atul Luykx <[email-masked]>
Date: Tue, 16 Aug 2016 07:25:54 -0700

Right now I see no reason for this not to work. In fact if you XOR the 
tag as well, then every block cipher call looks similar to a DESX call, 
like in XCAU.

Atul

---

From: Watson Ladd <[email-masked]>
Date: Tue, 16 Aug 2016 07:51:16 -0700

> change could be made without needing a new algorithm.

Yes. XOR two adjacent blocks, and you get something that is a function
purely of the key.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Atul Luykx <[email-masked]>
Date: Tue, 16 Aug 2016 16:38:21 -0700

> Yes. XOR two adjacent blocks, and you get something that is a function

This is true if N XOR L is made public (where L is the secret value). As 
long as N XOR L is only used for encryption, and N is the value 
communicated, then it isn't possible to get a function purely of the key 
by XORing two adjacent ciphertext blocks, since the block cipher inputs 
will depend on L.

Atul