raspi3 luks - aes-xts vs xchacha,aes-adiantum

2025-10-03

The raspberry pi 3 doesn’t have the hardware crypto extensions for aarch64, at least going by cpuinfo. That’s bad news for using AES for disk encryption, because software implementations of AES are slow. But there’s a disk encryption algorithm that uses your pick of chacha12 or chacha20 for the bulk data encryption. These algorithms were designed to be better suited to software and simd implementations than AES, so they’re a lot faster on the pi.

no hw crypto

Before I tell you about that, here’s what I’m going off of to see we don’t have hardware instructions for AES. I’ll compare with my Rock64 which does.

First, checking /proc/cpuinfo

# pi3
Features	: fp asimd evtstrm crc32 cpuid

# rock64
Features	: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp

Second, cat /proc/crypto | awk '$1 == "driver" && $3 ~ /^aes/'

# pi3
driver       : aes-arm64
driver       : aes-generic

# rock64
driver       : aes-arm64
driver       : aes-ce
driver       : aes-generic

I think aes-arm64 is an arm64 implementation (maybe using simd? or maybe just hand-crafted assembly) optimized as much as it can be, while aes-ce is using the aes instruction (ce = “crypto extensions” perhaps?).

wtf is adiantum?

I don’t feel like I can explain the crypto of it, so I’m not going to try. High level, some folks who were working at google wanted to make a faster disk encryption option for phones that didn’t have hardware AES acceleration. They cooked a composite-algorithm up, using chacha12 or chacha20 for the bulk of the work, and some other existing algorithms for some other parts of the encryption process. And that’s called Adiantum.

AES is sort of a household name in crypto at this point, but if you’re wondering where you might have used chacha20 before, WireGuard notably uses it as its only symmetric encryption cipher.

You should go read the paper if you want the maths of it.

It was merged into linux years ago so you can use it pretty much anywhere, but if you’ve got hardware aes acceleration then the usual aes-xts option beats it anyway.

Note there’s no 512-bit key version of adiantum. I think since the key is being used in a different way its not a direct comparison to aes-xts for what that means for security.

As for chacha20 vs chacha12, the number is how many rounds of the algorithm it’s doing. My understanding is chacha20 was the first variant, and then some folks proposed that a reduced number of rounds would still be secure. I can’t be the authority to tell you if chacha12 is good enough for you or not though.

benchmarks

These will just be running cryptsetup benchmark, which is a synthetic benchmark that tells the kernel to do some encryption work in memory, without an actual IO layer involved.

These are all on the pi3; comparing to rock64 wouldn’t be really interesting here since they’ve got different clocks anyway.

# Pin CPU to max clock speed so dynamic scaling doesnt mess
# with the numbers
echo performance > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor

cryptsetup benchmark -c aes-xts -s 256
cryptsetup benchmark -c aes-xts -s 512
cryptsetup benchmark -c xchacha12,aes-adiantum
cryptsetup benchmark -c xchacha20,aes-adiantum

Algorithm	Key	Encryption	Decryption
aes-xts	256b	34.5 MiB/s	35.1 MiB/s
aes-xts	512b	26.3 MiB/s	26.8 MiB/s
xchacha12,aes-adiantum	256b	143.9 MiB/s	144.0 MiB/s
xchacha20,aes-adiantum	256b	121.7 MiB/s	121.7 MiB/s

As you can see, it’s quite the difference!

encrypting a LUKS partition with it

Consult your favorite guide for using luks, but instead of --cipher aes-xts-plain64, use --cipher xchacha20,aes-adiantum-plain64.