Authors,
While reviewing this document during Final Review, please reply to the issues
in the GitHub repository
(https://github.com/rfc-editor-drafts/FinalReview-rfc10032/issues), which are
listed below for backup.
1) <!-- [rfced] We have shortened the abbreviated title for this document as
shown below. Please review and let us know if you prefer something
different. Note that the abbreviated title only appears on the running header
at the top of each page in the PDF output.
Original:
The AEGIS Family of Authenticated Encryption Algorithms
Updated:
AEGIS Authenticated Encryption Algorithms
-->
2) <!-- [rfced] The document title, abstract, and introduction use slightly
different language in referring to the algorithms. For example, the abstract
uses "AES-based authenticated encryption algorithms", and the introduction
uses "Authenticated Encryption with Associated Data (AEAD) algorithms". Please
review and let us know if any updates are needed.
Document title:
The AEGIS Family of Authenticated Encryption Algorithms
Abstract:
This document describes the AEGIS-128L, AEGIS-256, AEGIS-128X, and
AEGIS-256X AES-based authenticated encryption algorithms designed for
high-performance applications.
Introduction:
This document describes the AEGIS family of Authenticated Encryption
with Associated Data (AEAD) algorithms [AEGIS], which were chosen for ...
-->
3) <!-- [rfced] The [FIPS-AES] reference entry points to a "Withdrawn NIST
Technical Series Publication". NIST FIPS 197 was withdrawn in May 2023 and
updated by NIST FIPS 197-upd1.
The withdrawal notice includes the following note:
This update makes no technical changes to the algorithm specified in the
original (2001) release of this standard. This update includes extensive
editorial
improvements to the original version.
We have updated this reference to point to the most current version of
NIST FIPS 197. Please let us know if you have any objections.
Original:
[FIPS-AES] NIST, "Advanced encryption standard (AES)", NIST Federal
Information Processing Standards Publications 197,
DOI 10.6028/NIST.FIPS.197, November 2001,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.197.pdf>.
Updated:
[FIPS-AES] NIST, "Advanced Encryption Standard (AES)", NIST FIPS 197,
DOI 10.6028/NIST.FIPS.197-upd1, May 2023,
<https://doi.org/10.6028/NIST.FIPS.197-upd1>.
-->
4) <!-- [rfced] Please insert any keywords (beyond those that appear in the
title) for use on https://www.rfc-editor.org/search. -->
5) <!--[rfced] Please ensure that the guidelines listed in Section 2.1 of RFC
5743 have been adhered to in this document. -->
6) <!-- [rfced] Regarding sourcecode, the response on the intake form
specifies that the document includes two types: "pseudocode" for algorithm
descriptions and "test-vectors" for sourcecode in the appendix.
We have updated to use "test-vectors" in the appendix, but we would like to
clarify your intent for using "pseudocode" for algorithm descriptions. Should
"pseudocode" be applied to each block prefaced with "Steps:" in Sections 3-8?
Should each function (e.g., 'Encrypt(msg, ad, key, nonce)' in Section 3.1)
also be marked as "pseudocode"?
Note that the blocks in Sections 5.4.7 and 8.3.2 contains lines that are too
long for the TXT output (the line limit for sourcecode in the TXT output is 69
characters). When we convert the kramdown-rfc file to RFCXML, we will ask
about how to break these long lines to fit the line limit.
-->
7) <!-- [rfced] How may we update "whose meaning is defined in" for clarity?
Note that this text appears twice in the document.
Original:
The parameters for this algorithm, whose meaning is defined in
[RFC5116], Section 4, are:
Perhaps (uses "are" - parameters are defined):
The parameters for this algorithm, which are defined in
Section 4 of [RFC5116], are:
Or (uses "is" - algorithm is defined):
The parameters for this algorithm, which is defined in
Section 4 of [RFC5116], are:
-->
8) <!-- [rfced] How should we expand "VAES"?
Original:
Some CPUs, such as Intel and Intel-compatible CPUs with
the VAES extensions, include instructions to efficiently
apply the AES round function to a vector of AES blocks.
-->
9) <!-- [rfced] FYI - We updated "each of them updating" to "each of which
updates". Let us know any concerns.
Original:
M0 and M1 are 128
* D bits instead of 128 bits, but are split into 128-bit blocks, each
of them updating a different AEGIS-128L state.
...
M is 128 * D bits
instead of 128 bits and is split into 128-bit blocks, each of them
updating a different AEGIS-256 state.
Updated:
M0 and M1 are 128
* D bits instead of 128 bits, but they are split into 128-bit blocks, each
of which updates a different AEGIS-128L state.
...
M is 128 * D bits
instead of 128 bits and is split into 128-bit blocks, each of which
updates a different AEGIS-256 state.
-->
10) <!-- [rfced] Is a citation needed for "NIST guidelines"? If so, please
provide the appropriate reference.
Original:
With AEGIS-128L and AEGIS-128X, random nonces can safely encrypt up
to 2^48 messages using the same key with negligible (~2^-33, to align
with NIST guidelines) collision probability.
-->
11) <!-- [rfced] Will readers know what is meant by "the original
specification" here? Is a citation needed?
Original:
This document extends the original specification by introducing
optional support for 256-bit authentication tags, which are
constructed similarly to the 128-bit tags.
-->
12) <!-- [rfced] IANA Considerations
a) FYI - We made the following changes to the table in the IANA Considerations
section:
- switched the order of the columns to match the order in registry
- updated the column headers to match those in the registry
Link to registry:
https://www.iana.org/assignments/aead-parameters#aead-parameters-2
b) The algorithm names listed in Table 2 in the IANA Considerations section do
not align with the names used throughout the document. In the pairs of
examples below, we see the first name in Table 2 and the second elsewhere in
the document. Please review and let us know if any updates are needed
(document and IANA registry).
AEAD_AEGIS128L
AEGIS-128L
AEAD_AEGIS256
AEGIS-256
AEAD_AEGIS128X2
AEGIS-128X2
AEAD_AEGIS128X4
AEGIS-128X4
AEAD_AEGIS256X2
AEGIS-256X2
AEAD_AEGIS256X4
AEGIS-256X4
In addition, the following appear in the document but not in Table 2. If any
updates are needed for the above, these may also need to be updated.
AEGIS-128X
AEGIS-256X
AEGISMAC-128L
AEGISMAC-256
AEGISMAC-128X
AEGISMAC-256X
-->
13) <!-- [rfced] We note that the following term is used inconsistently in the
document. Please let us know which form you prefer or if this should be left
as is.
Mac function
MAC function (1 instance)
-->
14) <!-- [rfced] FYI - We have added expansions for the following
abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review
each expansion in the document carefully to ensure correctness.
key derivation function (KDF)
HMAC-based key derivation function (HKDF)
-->
15) <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
Thank you.
Madison Church and Rebecca VanRheenen
RFC Production Center
On Aug 14, 2026, at 1:30 PM, [email protected] wrote:
*****IMPORTANT*****
RFC Author(s):
--------------
Your document has now entered Final Review (previously AUTH48).
The document was edited in kramdown-rfc as part of the RPC pilot test (see
https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc).
Final Review is being handled in GitHub as part of the GitHub pilot test
(see
https://www.rfc-editor.org/rpc/wiki/doku.php?id=rpc-github-phase-0-pilot-test).
Your document is available for review at:
https://github.com/rfc-editor-drafts/FinalReview-rfc10032
Please do the following:
a) accept your invitations to join the repo as collaborators. Note that we sent
invitations to both authors. We can also send an invitation to the document
shepherd (Stanislav Smyshlyaev) if provided with a GitHub username.
b) see the README for details on the Final Review process:
https://github.com/rfc-editor-drafts/FinalReview-rfc10032/blob/Approved/README.md
c) review the edits in the RPC-edits pull request:
https://github.com/rfc-editor-drafts/FinalReview-rfc10032/pulls
d) address the issues:
https://github.com/rfc-editor-drafts/FinalReview-rfc10032/issues
Once the content of the .md file is stable, we will convert it to .xml
and provide the .html, .pdf, .txt, and .xml files for review.
You and your coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Once the document has been reviewed and approved by all of the authors,
it will be published as an RFC. If an author is no longer available,
there are several remedies; see the Unavailable Authors section
(https://authors.ietf.org/rfc-publication-process#unavailable-authors).
Details on the status of your Final Review are here:
https://queue.rfc-editor.org/final-review/rfc10032/
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Production Center
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
