8000 Rename "armcrypto" implementations to "neon_aes" by georges-arm · Pull Request #20 · aegis-aead/libaegis · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Rename "armcrypto" implementations to "neon_aes" #20

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

georges-arm
Copy link
Contributor

The Arm 64-bit architecture contains a number of architecture extensions relevant to the AEGIS family of algorithms, however currently libaegis only checks and exposes FEAT_AES. In particular:

  • FEAT_SHA3 contains the Neon EOR3 and BCAX instructions which can be useful for e.g. combining pairs of exclusive-or instructions.

  • FEAT_SVE_AES provides SVE versions of the existing AESE and AESMC instructions. These can be beneficial on micro-architectures with longer vectors.

  • FEAT_SVE2 provides SVE2 versions of the EOR3 and BCAX instructions, mirroring the Neon versions but for SVE vectors.

As a first step towards supporting these new extensions, rename the existing code to disambiguate away from "armcrypto" and instead refer to the exact "neon_aes" extension that the code depends on.

The Arm 64-bit architecture contains a number of architecture extensions
relevant to the AEGIS family of algorithms, however currently libaegis
only checks and exposes FEAT_AES. In particular:

* FEAT_SHA3 contains the Neon EOR3 and BCAX instructions which can be
  useful for e.g. combining pairs of exclusive-or instructions.

* FEAT_SVE_AES provides SVE versions of the existing AESE and AESMC
  instructions. These can be beneficial on micro-architectures with
  longer vectors.

* FEAT_SVE2 provides SVE2 versions of the EOR3 and BCAX instructions,
  mirroring the Neon versions but for SVE vectors.

As a first step towards supporting these new extensions, rename the
existing code to disambiguate away from "armcrypto" and instead refer to
the exact "neon_aes" extension that the code depends on.
@jedisct1
Copy link
Collaborator

Thank you!

SVE implementations would indeed be really good to have in the future.

@jedisct1 jedisct1 merged commit 5726c4a into aegis-aead:main May 12, 2025
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0