[TLS] Randomization of nonces

[Watson Ladd]

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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Randomization of nonces

[Paterson, Kenny]

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 
mailto:watsonbl...@gmail.com>> 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.

As an alternative we could use 256 bit keys.

Sincerely,
Watson Ladd

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Randomization of nonces

[Bodo Moeller]

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

Re: [TLS] Randomization of nonces

[Björn Tackmann]

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 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  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.
>> 
>> As an alternative we could use 256 bit keys.
>> 
>> Sincerely,
>> Watson Ladd
>> 
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] KeyUpdate receive_generation field (again)

[Keith Winstein]

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 and stop accepting data encrypted with receive-keys from
earlier generations, and
3) advance the send-key forwards to at least the same generation if it
isn't already (and send a KeyUpdate in the reverse direction as
necessary).

Because either side can generate a KeyUpdate message whenever they
want, there's no way within the current draft to tell that this
instruction has actually been carried out. For some applications, it
would be helpful for an initiating side to receive a confirmation that
the KeyUpdate (especially part #2, de-trusting the old receive-key)
has taken effect:

- An embedded device may wish to fully rotate the session keys before
going to sleep.

- A paranoid device might fully rotate the session keys before closing
the session, with the hopes that the other side will de-trust and also
delete the old session keys, so that a subsequent compromise doesn't
betray the session plaintext. If an endpoint can't get confirmation
that the other side has incremented the receive-key generation, it
might use a higher-level mechanism to forcibly log out all open
sessions from that user.

- An endpoint that wishes to permit a read-only virus scanner or IDS
will want to fully rotate the session before sharing the directional
keys with the middlebox. Otherwise the middlebox could use them to
become a MITM in at least one direction.

Our proposal is to add a receive_generation field to the KeyUpdate
message, so an initiating node can learn when an earlier KeyUpdate has
taken effect. The KeyUpdate message would remain as async and
non-blocking as it is currently.

Pull request: https://github.com/tlswg/tls13-spec/pull/580

Earlier discussion:
https://www.ietf.org/mail-archive/web/tls/current/msg19347.html and
subsequent

Cheers,
Keith

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Randomization of nonces

[Martin Thomson]

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 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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls