Re: [CFRG] Update of the AEGIS draft

[John Mattsson <[e-mail]>]

Another comment on -02

The document registers two AEAD algorithms but does not specify how 'ct' and 'tag' are combined to create C compatible with the RFC 5116 interface which requires a single output.
https://www.iana.org/assignments/aead-parameters/aead-parameters.xhtml

For the same reasons, the following are a bit contradictiing.
  "ct: the ciphertext."
 "C_MAX (maximum ciphertext length) = P_MAX + tag length"

RFC 8439 (ChaCha20-Poly1305) seems to have the same problem, it is unspecified how to create C. There are infinite ways (most bad) to combine ct and tag.

RFC 8452 (AES-GCM-SIV) specifies that "The final ciphertext is the result of XORing the plaintext with the keystream and appending the tag."

Cheers,
John

From: CFRG <[e-mail]> on behalf of John Mattsson <john.mattsson=[e-mail]>
Date: Tuesday, 18 April 2023 at 08:10
To: IRTF CFRG <[e-mail]>
Subject: Re: [CFRG] Update of the AEGIS draft
Should be simplified and generalized as:

When the AEAD is based on AEGIS, then the mask is generated by the AEGIS Encrypt function with a 128-bit tag length, sn_key as the key, and the first 16 bytes of the ciphertext zero padded to the nonce length:

     Mask = Encrypt( , , sn_key, ZeroPad(Ciphertext[0..15], nonce length))


When the AEAD is based on AEGIS, then the mask is generated by the AEGIS Encrypt function with a 128-bit tag length, hp_key as the key, and the 16 bytes ciphertext sample zero padded to the nonce length:

     mask = Encrypt( , , hp_key, ZeroPad(sample, nonce length))

Cheers,
John


From: CFRG <[e-mail]> on behalf of John Mattsson <john.mattsson=[e-mail]>
Date: Monday, 17 April 2023 at 12:05
To: IRTF CFRG <[e-mail]>
Subject: Re: [CFRG] Update of the AEGIS draft
Hi,

Thinking more about QUIC and DTLS 1.3 header protection, I think this should be addressed in the CFRG draft. The header protection solution should reuse the current AEGIS interfaces.

The simplest solution seems to just use the 128-bit PRF tag for header encryption. Suggestion:

------------
# QUIC and DTLS 1.3 Header Protection

## DTLS 1.3 Record Number Encryption

In DTLS 1.3, record sequence numbers are encrypted as specified in Section 4.2.3 of [RFC9147]. When the AEAD is based on AEGIS, then the mask is generated by the AEGIS Encrypt function with a 128-bit tag length, sn_key as the key, and the first 16 bytes of the ciphertext as the nonce. The Mask for AEGIS-128L is

     Mask = Encrypt( , , sn_key, Ciphertext[0..15])

and the Mask for AEGIS-256 is

     Mask = Encrypt( , , sn_key, ZeroPad(Ciphertext[0..15], 256))

## QUIC Header Protection

In QUIC, parts of the QUIC packet headers are encrypted as specified in Section 5.4 of [RFC9001]. When the AEAD is based on AEGIS, then the mask is generated by the AEGIS Encrypt function with a 128-bit tag length, hp_key as the key, and the 16 bytes ciphertext sample as the nonce. The mask for AEGIS-128L is

     mask = Encrypt( , , hp_key, sample)

and the Mask for AEGIS-256 is

     mask = Encrypt( , , hp_key, ZeroPad(sample, 256))



------------

Alternatively, you could encrypt 128 zeroes and take the first 128-bits of 256-bit ciphertext, but that would be slower, and I don’t see any practical security benefits.

Cheers,
John



From: Colin Perkins <[e-mail]>
Date: Saturday, 15 April 2023 at 16:37
To: John Mattsson <[e-mail]>
Cc: Frank Denis <[e-mail]>, IRTF CFRG <[e-mail]>
Subject: Re: [CFRG] Update of the AEGIS draft


On 14 Apr 2023, at 17:05, John Mattsson wrote:

> Review of draft-irtf-cfrg-aegis-aead-02
>
> Hi,
>
> Thanks for driving this work! I have always been very supportive of this work. Reading and providing comments on the NIST SP 800-38 series during the last year has made me even more supportive. I think AEGIS fills several important requirements that are missing from current AEAD algorithms, espcially high-performance on commodity CPUs as well as large nonces. I hope the authors will submit AEGIS to the upcoming NIST workshop on encryption modes.
>
> I think the draft seems in a very good state. Some comments:
>
> - Title: Titles of RFCs should be capitalized according to RFC 7322, i.e., change to "The AEGIS Family of Authenticated Encryption Algorithms"
>
> - Abstract: I think the abstract should mention all the nice high level properties: support of large nonces, large plaintexts, key commitment…
>
> - Abstract: I think you should remove "It is not an IETF product and is not a standard." All needed text is automatically added to the RFC.

Section 2.1 of RFC 5743 requires certain statements be included in the Abstract and Introduction of IRTF drafts. This includes making it “very clear throughout the document that it is not an IETF product and is not a standard”. Having this text in the Abstract is one way of addressing that requirement, so I would not remove it.

Colin



> - "With AEGIS-128L, random nonces can safely encrypt up to 2^48 messages
>    using the same key with negligible collision probability."
>
>   Not sure 2^-33 is always considered negligible. Maybe good to inform the reader that after n messages the collision probability is n^2 / 2^129. I assume 2^48 was chosen to align with the NIST required 2^-32 probability for GCM.
>
> - IANA Considerations: How do I use AEGIS in QUIC and DTLS 1.3? Code points have been registered for TLS 1.3, which means that AEGIS can be used for TLS 1.3. It can however not be used for QUIC, DTLS 1.3, and cTLS as that requires standardization of how to do the QUIC and DTLS 1.3 Header Protection. What is the plan for that? I think this should be done very soon. Should that be done it this draft or a separate draft? Happy to help write such a separate draft/drafts if needed. The IANA registry says "DTLS-OK = Y", but that is only true for DTLS 1.2. How to encrypt the DTLS 1.3 header when TLS_AEGIS_256_SHA384 or TLS_AEGIS_128L_SHA256 is used is not specified. I would also like to see AEGIS being Recommended = 'Y' in the future. Unless done in this draft, I think a TLS WG draft should be processed in parallel with the CFRG draft doing these three things:
>
> 1. Recommended = 'Y'
> 2. How to encrypt DTLS 1.3 headers
> 3. How to encrypt QUIC headers
>
> Cheers,
> John
>
> From: CFRG <[e-mail]> on behalf of Frank Denis <cfrg=[e-mail]>
> Date: Friday, 14 April 2023 at 15:58
> To: IRTF CFRG <[e-mail]>
> Subject: [CFRG] Update of the AEGIS draft
>
> Hi all,
>
>
>
> A new revision of the draft on the AEGIS family of authenticated encryption algorithms was recently published.
>
>
>
> AEGIS is an AEAD designed for high performance applications, with significant advantages over AES-GCM:
>
> - Fast. 2x to 4x faster than AES-GCM on CPUs with AES pipelines. Software implementations also tend to be faster
>
> - Very simple to implement securely and efficiently using only the AES forward round function
>
> - Reduced memory usage: doesn’t require precomputing a key schedule nor powers of the MAC key to achieve optimal performance
>
> - Large nonce size (128 bits for AEGIS-128L, 256 bits for AEGIS-256)
>
> - Better security bounds
>
> - Context committing
>
> - Backtracking resistant
>
>
>
> In addition to internal deployments, AEGIS is already deployed in OVH routers, in the Linux kernel and in VPN software.
>
>
>
> Multiple implementations exist (C, C++, Rust, Zig, Python, Go, Assembly), most of them having been written independently, using only the specification:
>
> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-3b0fdf065dc1e6ef&q=1&e=d465abc6-e170-4c80-99e2-705daad7bfd1&u=https%3A%2F%2Fgithub.com%2Fjedisct1%2Fdraft-aegis-aead%23known-implementations<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-3b0fdf065dc1e6ef&q=1&e=c68cc6f1-dbc0-4c3d-8ff6-e92a201f6a59&u=https%3A%2F%2Fgithub.com%2Fjedisct1%2Fdraft-aegis-aead%23known-implementations><https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-3b0fdf065dc1e6ef&q=1&e=d465abc6-e170-4c80-99e2-705daad7bfd1&u=https%3A%2F%2Fgithub.com%2Fjedisct1%2Fdraft-aegis-aead%23known-implementations%3chttps://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-3b0fdf065dc1e6ef&q=1&e=c68cc6f1-dbc0-4c3d-8ff6-e92a201f6a59&u=https%3A%2F%2Fgithub.com%2Fjedisct1%2Fdraft-aegis-aead%23known-implementations%3e>
>
> In addition to reference code and to the specification, Google’s Project Wycheproof includes an extensive set of test vectors for AEGIS.
>
>
>
> For evaluation purposes, AEGIS can be used as an alternative to AES-GCM in the context of TLS.
>
> In order to ensure interoperability, IANA has assigned identifiers for AEGIS-based cipher suites.
>
> There is a maintained fork of BoringSSL that supports these cipher suites. The TLS stack of the Zig standard library also supports these suites out of the box.
>
>
>
> Feedback would be very useful. We would love to see this document move forward.
>
>
>
> Direct links to the draft:
>
> - latest version (editor’s copy): https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-7d2fee82ec540a8d&q=1&e=d465abc6-e170-4c80-99e2-705daad7bfd1&u=https%3A%2F%2Fjedisct1.github.io%2Fdraft-aegis-aead%2F%23go.draft-irtf-cfrg-aegis-aead.html<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-7d2fee82ec540a8d&q=1&e=c68cc6f1-dbc0-4c3d-8ff6-e92a201f6a59&u=https%3A%2F%2Fjedisct1.github.io%2Fdraft-aegis-aead%2F%23go.draft-irtf-cfrg-aegis-aead.html><https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-7d2fee82ec540a8d&q=1&e=d465abc6-e170-4c80-99e2-705daad7bfd1&u=https%3A%2F%2Fjedisct1.github.io%2Fdraft-aegis-aead%2F%23go.draft-irtf-cfrg-aegis-aead.html%3chttps://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-7d2fee82ec540a8d&q=1&e=c68cc6f1-dbc0-4c3d-8ff6-e92a201f6a59&u=https%3A%2F%2Fjedisct1.github.io%2Fdraft-aegis-aead%2F%23go.draft-irtf-cfrg-aegis-aead.html%3e>
>
> - datatracker page: https://datatracker.ietf.org/doc/draft-irtf-cfrg-aegis-aead
>
>
>
> Kind regards,
>
>
>
> -Frank.

> _______________________________________________
> CFRG mailing list
> [e-mail]
> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-40f7d10cf9eb7c69&q=1&e=d465abc6-e170-4c80-99e2-705daad7bfd1&u=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg