Re: [Cfrg] Do we need a selection contest for AEAD?

With regard to requirements for the mode, I would suggest to also consider
adding nonce hiding.

AEAD is understood as providing message privacy for any choices of nonces,
as long as they don't repeat. (Ignoring the nonce-misuse aspect, which is
orthogonal to what follows.) But, as pointed out in [BNT19]
<https://eprint.iacr.org/2019/624>, this isn't really true. There are
choices of non-repeating nonces that, if transmitted with the ciphertext as
necessary to allow decryption, compromise message privacy. This does not
contradict the AEAD definition, because the syntax of the latter gives the
decryptor the nonce and leaves the implementer to ensure it gets there.
Nonce hiding AE (which has a modified syntax and security definition, as
per the above paper) fills this gap.

This problem does not arise with random nonces. But the promise of AEAD was
to provide privacy with arbitrary nonces. A standard should either do this
fully (nonce hiding) or come with restrictions to only use, say, random
nonces.

Nonce hiding is also of interest for anonymity and meta-data privacy. With
regular AEAD, nonces that are sequence numbers can (if visible to the
adversary) reveal information, as pointed out by Bernstein
<https://groups.google.com/g/crypto-competitions/c/n5ECGwYr6Vk/m/bsEfPWqSAU4J>
and
CHAE <https://chae.cr.yp.to/whitepaper.html>. This is prevented in part by
nonce hiding.

For such reasons, nonce hiding is targeted in the AE mode of QUIC.

Mihir

On Fri, Jun 19, 2020 at 10:32 AM Stanislav V. Smyshlyaev <smyshsv@gmail.com>
wrote:

> Dear CFRG,
>
> The chairs would like to ask for opinions whether it seems reasonable to
> initiate an AEAD mode selection contest in CFRG, to review modern AEAD modes
> and recommend a mode (or several modes) for the IETF.
>
> We’ve recently had a CAESAR contest, and, of course, its results have to
> be taken into account very seriously. In addition to the properties that
> were primarily addressed during the CAESAR contest (like protection against
> side-channel attacks, authenticity/limited privacy damage in case of nonce
> misuse or release of unverified plaintexts, robustness in such scenarios as
> huge amounts of data), the following properties may be especially important
> for the usage of AEAD mechanisms in IETF protocols:
> 1) Leakage resistance.
> 2) Incremental AEAD.
> 3) Commitment AEAD (we've had a discussion in the list a while ago).
> 4) RUP-security (it was discussed in the CAESAR contest, but the finalists
> may have some issues with it, as far as I understand).
> 5) Ability to safely encrypt a larger maximum number of bytes per key
> (discussed in QUIC WG)..
>
> Does this look reasonable?
> Any thoughts about the possible aims of the contest?
> Any other requirements for the mode?
>
> Regards,
> Stanislav, Alexey, Nick
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>