Re: [Cfrg] A standard for committing authenticated encryption

Yevgeniy Dodis <dodis@cs.nyu.edu> Tue, 12 November 2019 00:11 UTC

Return-Path: <zaumka@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66051200E0 for <cfrg@ietfa.amsl.com>; Mon, 11 Nov 2019 16:11:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ta0-b_bGu1sb for <cfrg@ietfa.amsl.com>; Mon, 11 Nov 2019 16:11:18 -0800 (PST)
Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2E121200B6 for <cfrg@irtf.org>; Mon, 11 Nov 2019 16:11:17 -0800 (PST)
Received: by mail-io1-f44.google.com with SMTP id c11so16659314iom.10 for <cfrg@irtf.org>; Mon, 11 Nov 2019 16:11:17 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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: <CAKDPBw_Vew+hc4mb49BeMaxG8a-Tu1GcHq5XtWKyE0rsu=uZ5Q@mail.gmail.com>
In-Reply-To: <CAKDPBw_Vew+hc4mb49BeMaxG8a-Tu1GcHq5XtWKyE0rsu=uZ5Q@mail.gmail.com>
From: Yevgeniy Dodis <dodis@cs.nyu.edu>
Date: Mon, 11 Nov 2019 19:11:05 -0500
Message-ID: <CAMvzKsgDo+mpAuWEKyk_gadr7kzUw1-HWQbv1JmXqPHY4aMSSA@mail.gmail.com>
To: Paul Grubbs <pag225@cornell.edu>
Cc: cfrg@irtf.org
Content-Type: multipart/alternative; boundary="00000000000041dfe805971b16f7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/W3OpOCvN92qq8TIHLnws5Q7VzLg>
Subject: Re: [Cfrg] A standard for committing authenticated encryption
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=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.

Yevgeniy

On Mon, Nov 11, 2019 at 6:57 PM Paul Grubbs <pag225@cornell.edu>; 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 (
> https://eprint.iacr.org/2017/664)
> [2] Fast Message Franking: From Invisible Salamanders to Encryptment (
> https://eprint.iacr.org/2019/016.pdf)
> [3] OPAQUE draft (
> https://tools.ietf.org/html/draft-krawczyk-cfrg-opaque-03)
> [4] OPAQUE in TLS draft (
> https://tools.ietf.org/html/draft-sullivan-tls-opaque-00)
> [5] Security of Symmetric Primitives under Incorrect Usage of Keys (
> https://eprint.iacr.org/2017/288)
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>