[CFRG] Re: I-D Action: draft-irtf-cfrg-aegis-aead-12.txt

[Eric Biggers <[e-mail]>]

On Mon, Sep 23, 2024 at 04:32:58AM -0700, [e-mail] wrote:
> Internet-Draft draft-irtf-cfrg-aegis-aead-12.txt is now available. It is a
> work item of the Crypto Forum (CFRG) RG of the IRTF.
> 
>    Title:   The AEGIS Family of Authenticated Encryption Algorithms
>    Authors: Frank Denis
>             Samuel Lucas
>    Name:    draft-irtf-cfrg-aegis-aead-12.txt
>    Pages:   63
>    Dates:   2024-09-23
> 
> Abstract:
> 
>    This document describes the AEGIS-128L, AEGIS-256, AEGIS-128X, and
>    AEGIS-256X AES-based authenticated encryption algorithms designed for
>    high-performance applications.
> 
>    The document is a product of the Crypto Forum Research Group (CFRG).
>    It is not an IETF product and is not a standard.
> 
> Discussion Venues
> 
>    This note is to be removed before publishing as an RFC.
> 
>    Source for this draft and an issue tracker can be found at
>    https://github.com/cfrg/draft-irtf-cfrg-aegis-aead.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-irtf-cfrg-aegis-aead/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-irtf-cfrg-aegis-aead-12.html
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-irtf-cfrg-aegis-aead-12
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts

Thanks for the updated draft.  I noticed that AEGIS-128X and AEGIS-256X are now
included and have been since v6 of the draft.  I haven't looked into the
cryptography in detail here, but I wanted to express support for designing
algorithms that allow for larger amounts of parallelism -- as AEGIS-128X and
AEGIS-256X are intended to do, and many existing algorithms like AES-GCM do.

Due to the Vector AES extension and improved AVX-512 support in recent x86_64
CPUs, recent x86_64 CPUs can en/decrypt 16 or even 32 AES blocks in parallel.
For example, on AMD's "Zen 5" CPUs that have a full 512-bit data path, the
'vaesenc ZMM, ZMM, ZMM' instruction has a latency of 4 cycles and a reciprocal
throughput of 0.5 cycles.  Since 8 of these instructions can be executed in
parallel, and each one operates on a 512-bit register containing 4 AES blocks,
this means that up to 32 AES blocks can be encrypted in parallel.

I recently wrote AES-XTS and AES-GCM implementations that take advantage of the
x86_64 Vector AES and VPCLMULQDQ extensions.  Except for one AES block
encryption per message (for the tweak and authentication tag respectively), both
algorithms are fully parallel, so this was possible to do.  I looked into
optimizing AEGIS similarly, but I noticed that the "accepted" variant of AEGIS,
AEGIS-128, only supports 5 parallel AES round functions.  I guess it was assumed
this would be sufficient, but that's no longer the case.  AEGIS-128 naturally
results in an implementation using 128-bit vector registers, which uses only
about a quarter of the CPU's resources, and there is not much point trying to
optimize the code further as the algorithm definition makes it impossible.

Now, I don't know how practical it is to define more AEGIS variants when
AEGIS-128 was the one selected in CAESAR -- maybe it's "too late"?  But, I did
want to express support in principle for fixing the limited level of parallelism
in AEGIS, and it looks like AEGIS-128X and AEGIS-256X do this.

- Eric