Leveraging ARM64 AES and SHA Extensions for Faster Crypto

Leveraging ARM64 AES and SHA Extensions for Faster Crypto

If you're built a TLS-enabled service or a disk-encryption tool on ARM64 and noticed crypto performance that doesn't match the datasheet, you're not alone. The difference often comes down to whether your code is using the hardware-accelerated AES and SHA extensions built into the architecture, or falling back to software emulation.

What the ARM64 AES and SHA extensions actually do

The ARMv8-A architecture optionally includes cryptographic extensions that add dedicated instructions for AES block encryption and SHA hash computation. When present, these instructions let the processor perform crypto operations at full speed without shuttling data through main memory loops. GCC and Clang expose built-in functions for these instructions and will emit the corresponding hardware code if you compile with the -march=armv8-a+ aes+sha flag. Omit that flag, and the compiler generates generic software loops—functionally correct, but orders of magnitude slower.

Compiling and verifying hardware acceleration

To target the extensions, add the flag to your build. Here is a minimal example with GCC:

gcc -march=armv8-a+ aes+sha -O2 crypto_test.c -o crypto_test

After compiling, inspect the generated assembly to confirm the instructions are present:

objdump -d crypto_test | grep -E 'aes|sha'

You can also check the CPU's reported capabilities directly on the running host, without root privileges:

cat /proc/cpuinfo | grep -i 'aes sha'

Look for the aes and sha flags in the flags line of your CPU. If both appear, the hardware extensions are available. If not, the extensions are absent for that core, and you'll need a software fallback.

Measuring the real-world impact

OpenSSL's built-in speed test gives a quick comparative view. Run on the same hardware:

openssl speed -evp aes-256-cbc

and

openssl speed -evp sha256

On a Cortex-A72, you'll typically see 3-5x higher throughput for AES-256 and 2-3x for SHA-256 compared to the same code compiled without the extension flag. On ThunderX2, the gains are even more pronounced. Keep in mind these ratios are microarchitecture-dependent: a Cortex-A53 may show a smaller gap, and some low-power cores omit the extensions entirely.

When hardware isn't available – limitations and runtime checks

Not every ARM64 core implements AES or SHA. The Cortex-A53, found in many Raspberry Pi and embedded boards, lacks these extensions by default. Assuming their presence without verification can lead to silent performance degradation or, in rare cases, incompatible code paths. A practical defense is to embed a runtime capability query in your deployment script, checking /proc/cpuinfo or using a CPUID intrinsic before selecting the accelerated path. Additionally, performance improvements vary by silicon; the 3x AES gain on Cortex-A72 doesn't guarantee the same on custom or older hardware. Always benchmark on your target platform before committing to a hardware-accelerated crypto path.

To get the best results, add -march=armv8-a+ aes+sha to your build configuration for AES- or SHA-dependent code, and include a simple /proc/cpuinfo check in your deployment pipeline. This gives you the speed boost on compatible cores while safely falling back on ones that don't support the extensions.