Hi all, I've attached my notes. Appreciate your flexibility Madison. It's my bad for not doing this last time.
Please could you review this Frank, and we can do any edits on GitHub so it's easier to check. I'm happy to do the PRs if you want to wait until the weekend, or I can just double check your changes if you'd prefer. Many thanks, Samuel On Thursday, 27 August 2026 at 14:20, Madison Church <[email protected]> wrote: > Hi Samuel, > > No worries at all! Please feel free to send along an updated markdown file > once you’ve made those updates. > > Thank you, > Madison Church > RFC Production Center > > > On Aug 27, 2026, at 2:00 AM, Samuel Lucas <[email protected]> > > wrote: > > > > Hi Madison, > > > > I'm about halfway through my rereview of the document and have found > > several errors/clarity/undefined issues so far. > > > > Please could I check what can be changed at this stage so I can format my > > feedback accordingly. Errors obviously need to be fixed, so it's more > > whether things can be made clearer/more consistent. Can I send you a > > Markdown file when I'm done? > > > > Sorry for not doing a full reread as part of the GitHub work. I can assure > > you that we have both fully reviewed this document multiple times before, > > so I think this is just what happens after a long break. > > > > Many thanks, > > Samuel > > > > On Tuesday, 25 August 2026 at 15:51, Madison Church > > <[email protected]> wrote: > > > >> Hi Frank, Samuel, > >> > >> Frank - Thank you for your approval! We have noted it here: > >> https://queue.rfc-editor.org/final-review/rfc10032/. > >> > >> Samuel - No worries! We will wait to hear from you later this week. > >> > >> Thank you, > >> Madison Church > >> RFC Production Center > >> > >>> On Aug 25, 2026, at 7:01 AM, Samuel Lucas <[email protected]> > >>> wrote: > >>> > >>> Hello RFC Editors, > >>> > >>> I trust Frank's judgement. However, if there's no rush, please could you > >>> give me Wednesday/Thursday evening to review this. > >>> > >>> Sorry for the delay; I don't get notifications for this email account and > >>> assumed this email might come after the weekend. > >>> > >>> Many thanks, > >>> Samuel > >>> > >>> On Saturday, 22 August 2026 at 11:46, Frank Denis <[email protected]> wrote: > >>> > >>>> Hello RFC Editors, > >>>> > >>> > >>>> I've reviewed the final version of the document, and I think it's ready > >>>> for publication. > >>>> > >>> > >>>> Thanks again for all your help! > >>>> > >>> > >>>> -Frank. > >>>> > >>> > >>>> On Fri, Aug 21, 2026 at 01:20:18PM -0500, Madison Church wrote: > >>>>> Hello Authors, > >>>>> > >>>>> We have merged the updates and converted the kramdown-rfc file to > >>>>> RFCXML. Thank you both for submitting PRs and comments throughout the > >>>>> process, it was super helpful on our end! > >>>>> > >>>>> Please review the XML file and its TXT, HTML, and PDF outputs, and let > >>>>> us know if any changes are required or if you approve the RFC for > >>>>> publication. We consider this your final assent that the document is > >>>>> ready for publication. To request changes or approve your RFC for > >>>>> publication, please reply to this email. Please use ???REPLY ALL???, as > >>>>> all the parties CCed on this message need to see your approval. > >>>>> > >>>>> Note that we will only make changes in the XML file from this point on. > >>>> > >>> <publickey - [email protected] - 0xB416EEAC.asc> > >> > > <publickey - [email protected] - 0xB416EEAC.asc> > >
Scope (for all sections unless stated otherwise):
- Manual proofread of HTML
- AI proofread of PDF
- Spelling/grammar checker
I've split each section into 'Major' and 'Minor' for importance. Some 'Minor' entries are very optional.
---
## Abstract
Minor:
- No mention of stream cipher/MAC uses.
## Introduction
Minor:
- Committing security requires the associated data to be fixed - think this could be clearer here, but this is explained later in the document.
- `We follow the specification of [AEGIS], which can be found in the References section of this document.` => `of AEGIS v1.1 [AEGIS].` (References section bit can be removed too)
- `Status of This Memo` section says `represents the consensus` and `is not a standard`, so do we need a sentence in the Introduction? Seems like duplication, which I didn't realise before.
## Conventions and Definitions
Major:
- We haven't defined that `Tail(x, n)` returns nothing when there's no partial block at the end, which is important for the `if cn is not empty` line.
Minor:
- `the remainder of the Euclidean division between a as the dividend and b as the divisor.` => `the remainder obtained when dividing a (the dividend) by b (the divisor) using Euclidean division`
## The AEGIS-128L Algorithm
Major:
- `C_MAX` includes the tag length but then the tag is a separate input. We could do with a separate constant for the tag length.
- `tag_len_bits` is undefined but pretty obvious what it means. One could argue this should be a function parameter, but that's quite complicated to edit. This should probably just be defined somewhere instead now.
Minor:
- `if tag verification failed` => `if tag verification fails` (rest is in present tense)
- `in bits:` still looks a bit weird to me but can't be changed unless you put the tag size first.
## The AEGIS-256 Algorithm
Major:
- `Authenticated Decryption` shouldn't say `Split(ZeroPad(ct, 128), 128)` - this is an error and must be corrected. Compare to the AEGIS-128L section and notice the lack of `ZeroPad()`.
- `C_MAX` includes the tag length but then the tag is a separate input.
- `tag_len_bits` is undefined.
Minor:
- `[RFC5116], Section 3` - formatting different to AEGIS-128L section and other places.
- `if tag verification failed` => `if tag verification fails`
## Parallel Modes
Major:
- `Byte(x)` should probably be defined in `Conventions and Definitions` and used for the stream cipher section.
- `ZeroPad({}, 128)` - this is wrong since the definition says not to pad when the input is empty.
- Are `0..D`/`1..D` in the pseudocode sufficiently clear that it's `[0..D)`?
Minor:
- `, but it processes` => `However, they process` because this applies to both variants.
- Missing definition of inputs/outputs but can get away with this. That's a larger edit.
- `m0[i]`/`m1[i]` not explicitly defined but obvious.
- `The context is added to the state before every update` => `mixed into certain parts of the state`?
- `V[6,i] ^ V[1,i]` are a different order to the non-parallel functions, not that this matters.
- `similar to the AEGIS-128L DecPartial function but decrypts up to R bits` - R bits should never be reached but not sure how to reprhase.
- `R (=` => `R (` - it's currently different between the two parallel modes.
- `The resulting algorithms are called AEGIS-128X2, AEGIS-128X4, AEGIS-256X2, and AEGIS-256X4` - should these algorithm names be codified like they are?
- Table 1 has no description below it compared to Table 2.
## Encoding (ct, tag) Tuples
Nothing found.
## AEGIS as a Stream Cipher
Major:
- No mention that nonce + key reuse is insecure in this section (no `Security:` subsection and nonce is optional). I would argue that the nonce shouldn't be optional for the specification because it isn't anywhere else and isn't for most other algorithm definitions.
- Haven't defined `{ 0 }` in `Conventions and Definitions` section. See my comment about the `Byte(x)` function to solve this.
## AEGIS as a Message Authentication Code
Major:
- `there is no guarantee that they are uniformly random` - is this definitely right because surely that means ciphertexts are distinguishable from random? However, it still shouldn't be used for key derivation.
- `tag_len_bits` not defined again.
- I want to double check `# tag from state 0 is included` with Frank for AEGISMAC-128X because it feels like double computation with the final if statement and differs from AEGISMAC-256X. If this is correct, it's not obvious why this is different.
Minor:
- `For all the variants` => `For all variants`
- `takes a key, a nonce, and data` => `takes a key, nonce, and data`
- `inputs causing state collisions` => `inputs that cause state collisions`
- `used for key derivation as there` => `because there`
- `finalizes all the instances` => `finalizes all instances`
## Security Considerations
Minor:
- Nonce reuse clarification for AEADs/stream ciphers vs the MACs to avoid a contradiction.
- `last Update call of the initialization function.` => `Init function`? I think this is fine though, and this is the case in other places.
## References
Only checked with AI because I've manually checked this before thoroughly. Only found a false positive.
## Test Vectors
Major:
- Double check `AEGISMAC-128X4 Test Vector` because `tags256` isn't double the number of lines as `tags128`. I think this is correct based on the pseudocode.
- Make sure `AEGISMAC-128X2 Test Vector` is also correct based on the `# tag from state 0 is included` comment above.
I didn't check that the actual test vectors are correct.
## IANA Considerations
Nothing found.
## Acknowledgments
Nothing found.
## Authors' Addresses
Nothing found.
publickey - [email protected] - 0xB416EEAC.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
