IETF Logo Mail Archive

[Cfrg] A standard for committing authenticated encryption

Paul Grubbs <pag225@cornell.edu> Mon, 11 November 2019 23:57 UTC

Return-Path: <pag225@cornell.edu>
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 9BDDC1200FD for <cfrg@ietfa.amsl.com>; Mon, 11 Nov 2019 15:57:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cornell.edu
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 axb8IpPaAROX for <cfrg@ietfa.amsl.com>; Mon, 11 Nov 2019 15:57:46 -0800 (PST)
Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 E04CC1200B6 for <cfrg@irtf.org>; Mon, 11 Nov 2019 15:57:45 -0800 (PST)
Received: by mail-io1-xd33.google.com with SMTP id s3so16653563ioe.3 for <cfrg@irtf.org>; Mon, 11 Nov 2019 15:57:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cornell.edu; s=g.20171207; h=mime-version:from:date:message-id:subject:to; bh=decZ0g7a+DNYUbOvoQa3KgVi4/VhftPuf1Mfjum7tus=; b=kEjfvVpph01+4CaLI8FVqucWdVcbxFhJfL6mSuWASz8V0XqOcHH7J2/1scRVhzBnvN DwQN2QFIlI5WqQyFshLIYicfCZjzvpeoQzuJfm7XeU4O9cOZnMbcVPhhjp77f9NdQugD Z6LhI7+hegFUg8QHannlzIWtibq/5CvR1O6UADy7MCcDdQnqDv6KRjIYVDUyZrG6Fwka Z8YutwoRD4e5gPFYtP/or8q4hdcL4dgNDhhV8B7C6kFk06BRnoIUPin0QC+u0botj7Sm /yKnoUzNwflCXTSMXFmkmxO1WBN57AFe2hwTESu0uym4Iiznl8G2kGymbLMR2zpfvkUV F14A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=decZ0g7a+DNYUbOvoQa3KgVi4/VhftPuf1Mfjum7tus=; b=jHtOZp/c/Gxk9TYBug8qORUKqo/oI7WhHUbeW3MJb9KjPmHOU16ltb8wA6YbmCGYzw OryOuiZgw5Y0B/QJ1uvQJgBsaW82aoq1jfTKt6c/tskLe0KVMWjPvUiMd3+Za4uu2zsD mKIg78UwJt4EBfRpfe6av65W1uyK4qBMAh37t4jD6j6mx2Unvfi73bNQUuzKy+Npu2PK KN/NBMdD27iTzsTInx7bip3a8rURlluuStPwYOub5atkL2kxwMiBgbrMExQxZ0ViJD8G DdnIlMWdudQJJ/S95H8Gt5l0rvZcwb3mp6aF5W5OMysL7GEgWsK4t+5o+mwpy9MoJaZh oUVA==
X-Gm-Message-State: APjAAAW/DOzxO+APDWSzjivQOIlMBYZHFNBqar49tYFu7fssDQADJMTX gM87iW0xWyTfjp0dtOdINqAMMiaxe3FGPX+PJ5csvJbGEyg=
X-Google-Smtp-Source: APXvYqxn+R1LL8uE8NxqAD6nrTRe0KeHyOsjXp8YGeMVIAWrSLBfIep6ZNE7YRajsPzCEO/KDu3eGVitVXJxo3UMgBk=
X-Received: by 2002:a6b:ba44:: with SMTP id k65mr25507615iof.190.1573516664524; Mon, 11 Nov 2019 15:57:44 -0800 (PST)
MIME-Version: 1.0
From: Paul Grubbs <pag225@cornell.edu>
Date: Mon, 11 Nov 2019 18:57:33 -0500
Message-ID: <CAKDPBw_Vew+hc4mb49BeMaxG8a-Tu1GcHq5XtWKyE0rsu=uZ5Q@mail.gmail.com>
To: cfrg@irtf.org
Content-Type: multipart/alternative; boundary="000000000000d6689505971ae599"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/msFJaVwi3DQ2Td5jf68TU2cDURg>
Subject: [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: Mon, 11 Nov 2019 23:57:49 -0000

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)

v2.23.0 | Report a Bug | By Email