Alignment with draft-irtf-cfrg-aead-properties

[jedisct1]

We should align with the draft-irtf-cfrg-aead-properties draft. There was already an open issue about this on the previous repository, but it was unfortunately lost, and was probably referring to an older revision of the draft anyway. So let's go though the different properties again, and then see how to include them in the document.

• confidentiality: yes, and the current document already includes details about this.
• data integrity: ditto
• blockwise security: yes, since the output function is a linear combination of multiple blocks, and doesn't reveal anything about the actual state.
• full commitment: no, even though we document a simple and efficient way to achieve this.
• key commitment: the aead-properties draft is being updated in a way that can capture the relaxed setup applicable to AEGIS.
• key dependent messages security: this is a protocol property, not an AEAD property. Reported to the aead-properties author.
• leakage resistance: no, already documented
• multi-user security: the large nonce size of AEGIS-256 makes it possible to embed a key identifier, and still allow random nonces to be safely used. With a distinct key identifier for every user, there's no security degradation even in a multi-target setting. See section 3.2.1 of Xoodyak for a precedent. With AEGIS-128, the 32 extra bits compared to current AEADs used in IETF protocols can also be used to embed a key identifier.
• nonce misuse: no, already documented
• reforgeability resilience: see Reforgeability of Authenticated Encryption Schemes, especially section 4.3. And that's one more paper we can cite.
• Release of unverified plaintext: no, already documented.
• Inverse-free: yes
• lightweight: no
• online: yes
• parallelizable: yes
• single-pass: yes
• static associated data: no
• ZK-friendly: no
• incremental: no, if only because it must be used in a nonce-respecting setting.
• nonce-hiding: no
• remotely-keyed: not a property of an AEAD, this requires a protocol. Reported to the aead-properties author.
• robust: no

[samuel-lucas6]

Thanks for going through them and those references. Seeing as there are so many, shall we stick to the ones that are 'yes'? Most of the 'no's don't seem popular in practice.

Multi-user security and reforgeability resilience should definitely be discussed. Parallelizable is already being mentioned. I'm not sure if inverse-free, online, and single-pass need to be stated given they're somewhat obvious if you read the draft, although they could go in the Introduction. Haven't read about blockwise security.

[jedisct1]

The plan can be:

• Make sure the vocabulary we use matches the one from the aead-properties spec, and try to use it whenever we describe some of these properties without using it.
• The "no" ones don't seem to be very interesting to mention.
• Inverse-free, online and single-pass can be quickly dropped somewhere in the intro, unless that feels too artificial
• Blockwise-security doesn't sound necessary. All standardized AEADs have that property, or else they could hardly be qualified as IND-CCA secure. It would rather be something worth mentioning if a construction would NOT have that property.
• Multi-user security and reforgeability can be added to the Security Considerations section.