Subject: [MLS] Reuse guard in Framing

From: Tijana Klimovic <[email-masked]>
Date: Thu, 22 Jul 2021 11:58:00 +0200

Hello,

I have a question regarding the reuse guard used in the framing. The
specification motivates its use in the following way:

"Before use in the encryption operation, the nonce is XORed with a fresh
random value to guard against reuse. Because the key schedule generates
nonces deterministically, a client must keep a persistent state as to where
in the key schedule it is; if this persistent state is lost or corrupted, a
client might reuse a generation that has already been used, causing reuse
of a key/nonce pair."

When would losing one's state be a realisitic possibility?

Many thanks.
Tijana

---

From: Natanael <[email-masked]>
Date: Thu, 22 Jul 2021 13:23:01 +0200

> When would losing one's state be a realisitic possibility?

Via a recent thread on the metzdowd cryptography mailing list;

https://www.metzdowd.com/pipermail/cryptography/2021-July/037258.html

The TLDR is we've seen it break so many times that we have to assume it
will fail again. See for example the Sony PS3 signing key leak, via ECDSA k
value reuse.

Anything from a power loss, to a logic bug, to application state being
replicated into new instances, or even restore from a backup, or a weak
RNG, etc, can cause it.

Note that in certain situations where nonce reuse happens due to lost
state, it may be because you're in a virtualized environment where the RNG
has also broken for the exact same reason. If you're concerned nonce reuse
may happen in a given environment, an MRAE ciphersuite is the best option
(misuse resistant authenticated encryption, including most SIV modes).

Looks like the draft currently only have plain stream cipher modes defined
(which would unfortunately fail catastrophically in the case a nonce and
key is reused for different messages), but perhaps AES-GCM-SIV can be added
in addition to the regular AES-GCM mode which is currently defined?