Re: [Cfrg] A standard for committing authenticated encryption

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
>