Re: [Cfrg] A standard for committing authenticated encryption

Yevgeniy Dodis <> Tue, 12 November 2019 00:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C66051200E0 for <>; Mon, 11 Nov 2019 16:11:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ta0-b_bGu1sb for <>; Mon, 11 Nov 2019 16:11:18 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E2E121200B6 for <>; Mon, 11 Nov 2019 16:11:17 -0800 (PST)
Received: by with SMTP id c11so16659314iom.10 for <>; Mon, 11 Nov 2019 16:11:17 -0800 (PST)
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=FgVuzy3MjK6bK2ONOmN39ZdKgHKuic8m1uMXu8dOQ0U=; b=VY1XIBymw8AtyHj5ilgSeoOlYQmWrnwODdseZwoTnGh3eZUKXmJoOK5MrMCUXKF50/ CXRO/QtU4eiJ9t5K+E+Cbllpn3mQ/zvGJdOMXylNotnQnJLM/WeW2okUoyrFqWG7tOi7 Teh5YdlaChhFXLXrGdWhT7Dp4peQcRi+uBGBS1M1ob01F5jhxibKba+LJ+yqMsm29flR ffUwmJhTJB7iQ2u2xNXL15H/rEBj+xn6g44va1C4z1BzHnyyLdGilYZzPElRV0zKyvn6 3VxeQ2ermICGXyqxpGNzBPMgUCOVI83eqNWNVssjPjalQe1txSEJk7dUOK3EhYHT56UV jY0w==
X-Gm-Message-State: APjAAAUDWrKJW7sfPvohKGbdpVBZtk69NjUJPkYLTjm7Kv8BukYTnmet Dzg4/GF91MatG7tQy/ycQ4dYkf0Kd/2jbDO+n8XqLA==
X-Google-Smtp-Source: APXvYqx0MoONZzwciaNp4BAk4qy00KgDOZle3XAzZRfw2XAVtQ6cN5xDij9F5dn7Gd6YC6T396IC4iu0JdHwld/Ya+I=
X-Received: by 2002:a5d:970c:: with SMTP id h12mr26329766iol.20.1573517476879; Mon, 11 Nov 2019 16:11:16 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Yevgeniy Dodis <>
Date: Mon, 11 Nov 2019 19:11:05 -0500
Message-ID: <>
To: Paul Grubbs <>
Content-Type: multipart/alternative; boundary="00000000000041dfe805971b16f7"
Archived-At: <>
Subject: Re: [Cfrg] A standard for committing authenticated encryption
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Nov 2019 00:11:20 -0000

I am highly biased, but I think the idea is fantastic. I will be happy to
participate in this if you guys decide to go ahead...

Of course, to be upfront, one needs to understand that cAE requires some
use of collision-resistant hashing. So, in
terms of current implementations, could be close to an order of magnitude
slower than encrypt-then-MAC or OCB
schemes based on only a block cipher (e.g., AES).

So this might not be for everybody if speed in concerned. But a clear
standard, with appropriate warnings (more secure,
wider applicability, but potentially slower), seems like a great idea.


On Mon, Nov 11, 2019 at 6:57 PM Paul Grubbs <> wrote:

> Hello all,
> A 'committing' authenticated encryption (cAE) scheme is one for which it
> is hard to find a ciphertext having multiple correct decryption keys.*
> More formally, a cAE scheme's ciphertexts are binding commitments. AE
> security of a scheme does not imply its ciphertexts are binding
> commitments, and widely-used AE schemes like Galois/Counter Mode and
> two-key encrypt-then-MAC are not cAE [1]. This has already led to attacks
> on already-deployed protocols like message franking [2]; cAE is also needed
> in protocols like OPAQUE [3, 4] that may soon be standardized and deployed,
> and is useful elsewhere (e.g., group messaging/MLS).
> Though cAE is needed in practice, there is no standards document
> explaining cAE and defining secure schemes. I think such a document would
> be really helpful to researchers and practitioners alike, so I'd like to
> initiate some discussion in the mailing list ahead of the CFRG meeting at
> IETF 106 next week, where hopefully Nick will present a few slides to get
> people thinking about cAE.
> Right now, I'd really like to know whether people think this is needed or
> useful, and what they'd like to see out of an eventual RFC. Also, if you've
> ever needed committing AE or have encountered a setting where encryption
> keys and/or ciphertexts can be adversarially chosen, I'd love to hear about
> it.
> Thanks everybody!
> *Some prior work [5] calls this and other similar properties 'robustness'.
> Since 'robust' is already an overloaded term in cryptography, I prefer
> 'committing'.
> [1] Message Franking via Committing Authenticated Encryption (
> [2] Fast Message Franking: From Invisible Salamanders to Encryptment (
> [3] OPAQUE draft (
> [4] OPAQUE in TLS draft (
> [5] Security of Symmetric Primitives under Incorrect Usage of Keys (
> _______________________________________________
> Cfrg mailing list