Re: [MLS] Reuse guard in Framing

Natanael <> Thu, 22 July 2021 11:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DB49D3A42B8 for <>; Thu, 22 Jul 2021 04:23:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DjGi0ESTvA18 for <>; Thu, 22 Jul 2021 04:23:28 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0FC913A42B7 for <>; Thu, 22 Jul 2021 04:23:17 -0700 (PDT)
Received: by with SMTP id b26so7974652lfo.4 for <>; Thu, 22 Jul 2021 04:23:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DOj+CZziYeBIjP5h9Jyz4d+8ohZ7/EF+C0KktuTIqaw=; b=cGjZ40Cs14UPCapB1DnAccVxLmQ/OrxQjaD/SDN3702BZPqFBIJGCOfO1ZZ7l3S5Ea x3LPC/KzqGXUyjYBX1TZsutv965hQcEsPURmIZUOMqIs6qY7QgVL0BWcXMLMDtMY/Stj vIBExbf2N/jz6xJ+vltcSjV8PxxGE2zI2ZeLFVmHZax9jIDXgyLkexjNCrxf+8DI33Yb xpj+3xPFrWhw8QkgB3+rWt2OnqSyo1vJpKmqW56RjergCq0oXaOW6r7iPGuCYLkp8IOt HvxKJxm1dzXyIjEHZn1AXOVVItc3sXiamG0EiX+BpGr5inRKvAgkKa6b8pG/ctoPiW4c DKBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DOj+CZziYeBIjP5h9Jyz4d+8ohZ7/EF+C0KktuTIqaw=; b=Hl7wR1K6qv6gosQn79D/jW7IXNbVxZBpdtXeUEl/gymu4sTfnqzfh0gYA+V8UlKHRm FuTj7OtdZR8YcroThn/SoxMeEhFGMJSXExgUdDvfLc2VM1WJ0GwhiieblpPHr6dVTtHs X5ZjZ/fq1y+mHXYXelO21buaJL5G0TK9K0gh69182RtHM+saO0OripI0WpJG7amHbDZ4 2w/fO3tMxsKGaA79zbGYXsNIWB+D2Ooc2LKRONlwHXSz1tH3Db+7eXI0Wt4tCXIW3doS 41AOnFdK3ykkjRULEsVLZyjGSBHFYMSCgoWqRAEdgXvV+XsqGS8YhSp56KaRJ2+Tz3Zj AyxQ==
X-Gm-Message-State: AOAM530HzfVYPb/5U0vRRSlejtu4Ml6czH4cHMejWwJ1krUzt6wcNrDq yMTCKoS0MJyhL8mx6FWE/2kXklEdN6+DectnBKc=
X-Google-Smtp-Source: ABdhPJx/R2HBCt/n3IHhpKzIkKXU5WgrpcSDklLI11BllHOeHsw7TgWN8D+No0uc2JcOJTTqHKkBwXtjkV8dYgnplto=
X-Received: by 2002:a05:6512:3316:: with SMTP id k22mr28592594lfe.472.1626952995567; Thu, 22 Jul 2021 04:23:15 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Natanael <>
Date: Thu, 22 Jul 2021 13:23:01 +0200
Message-ID: <>
To: Tijana Klimovic <>
Content-Type: multipart/alternative; boundary="0000000000005dfd9605c7b48377"
Archived-At: <>
Subject: Re: [MLS] Reuse guard in Framing
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Jul 2021 11:23:33 -0000

Den tors 22 juli 2021 11:58Tijana Klimovic <>

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

Via a recent thread on the metzdowd cryptography mailing list;

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?