Hardware without AES-NI: use xchacha12/Adiantum instead of AES-XTS

[py0xc3]

This is a re-opening of https://bugzilla.redhat.com/show_bug.cgi?id=2077532 (I guess blivet handles tickets preferably here on GitHub? ;)

This report was written during the F35 release cycle, but still applies (also, feel free to review the adiantum discussions in the kernel-related mailing lists):

---

When setting up a new Fedora installation, Anaconda (both "Custom" and "Advanced Custom (Blivet-GUI)") always uses aes-xts-plain64 for disk encryption, even if the hardware does not support AES-NI.

If there is no AES-NI in the hardware, it makes sense to use xchacha12,aes-adiantum-plain64 or xchacha20,aes-adiantum-plain64 (xchacha12,aes-adiantum-plain64 is in my opinion sufficiently, especially for weak or battery-operated hardware).

Anaconda needs a function that determines the existence of an AES-NI in the CPU when setting up encrypted storage in order to choose aes-xts if AES-NI is available, and xchacha/adiantum if AES-NI is not available.

For an average kernel-operated block-based disk encryption use case, the security advantages of xchacha-adiantum compared to software-based aes-xts can be neglected: both aes-xts and chacha-adiantum are sufficiently secure for that.

But there are big performance disadvantages of AES when there is no AES-NI (this was the major reason for merging Adiantum into the kernel).

Besides the use of system resources, netbooks/laptops may have strongly decreased battery life times with aes-xts due to the high power consumption (the issue is primarily aes, not xts).

I tested with Fedora 35, KDE spin; but as the issue is Anaconda-centric, I expect that other Workstation installations tend to the same behavior, including different architectures.

Adjustments seem to be limited to Anaconda.

Might be interesting for upstream distributions as well.

Version-Release number of selected component (if applicable):
KDE spin of Fedora 35; 36 not yet tested for this issue.

How reproducible:
Use anaconda to install Fedora with storage configuration "Custom" or "Advanced Custom (Blivet-GUI)" (both behave equal in this respect) and enable disk encryption.

Actual results:
aes-xts encryption on hardware without aes-ni

Expected results:
xchacha-adiantum encryption on hardware without aes-ni

Additional info:
It is possible to create the xchacha-adiantum storage in advance using

cryptsetup --type luks2 --sector-size 4096 --cipher=xchacha12,aes-adiantum-plain64 --offset=0 --pbkdf argon2id --iter-time 2000 luksFormat /dev/sdx"; cryptsetup luksOpen /dev/sdx x1; mkfs.ext4 /dev/mapper/x1; cryptsetup luksClose x1;

Anaconda storage configuration "custom" (Blivet not yet tested with this) is properly able to decrypt and open the xchacha12-adiantum later to use it in the installation. Installation works properly since. At first glance, no errors in this process.

---

Casper added a related benchmark with a comparison of 256bit AES (XTS-512) against 256bit XChaCha20, which illustrates the impact on machines without AES-NI:

blackbird:~ # cryptsetup benchmark -c xchacha20,aes-adiantum                
# Tests approximatifs en utilisant uniquement la mémoire (pas de stockage E/S).
#            Algorithme |       Clé |     Chiffrement |    Déchiffrement
xchacha20,aes-adiantum        256b       327,8 MiB/s       345,0 MiB/s

blackbird:~ # cryptsetup benchmark -c aes-xts-plain64 --key-size 512
# Tests approximatifs en utilisant uniquement la mémoire (pas de stockage E/S).
# Algorithme |       Clé |     Chiffrement |    Déchiffrement
    aes-xts        512b        84,3 MiB/s        83,5 MiB/s

His note that Raspberry Pi models up to and including the current 4(B) have no AES-NI might be relevant, too.

See devel mailing list topic "Hardware without AES-NI: use xchacha12/Adiantum instead of AES-XTS".

---

I use it on several dm-crypt partitions on my Fedora for several months now.

[py0xc3]

@thestinger just made me aware that arm/aarch64 implement AES differently than x86_64.

This is relevant only for arm/aarch64 architectures and does not impact my proposal as far as it concerns x86_64, but when it comes to arm/aarch64, we have to be careful when implementing this: even if no AES-NI is available, the platform can still implement hardware AES if it is arm/aarch64.

[py0xc3]

Sorry, I accidentally closed, my bad -> now reopened.

[vojtechtrefny]

This is relevant only for arm/aarch64 architectures and does not impact my proposal as far as it concerns x86_64, but when it comes to arm/aarch64, we have to be careful when implementing this: even if no AES-NI is available, the platform can still implement hardware AES if it is arm/aarch64.

So is there a simple way to check whether a system has some sort of hardware AES support or not?

[py0xc3]

On x86_64: yes, it remains as it is: e.g., lscpu | grep aes -> if no output == AES-NI false / if Flags output == AES-NI true. You just need to access the CPU flags and check if aes is contained.

On aarch64/arm, I don't know. My experience with this architecture is limited. I cannot verify if there is any aes flag in aarch64/arm systems since I have no such hardware. Because the aes implementation seems to be not necessarily part of the CPU but can be separated on the SoC, I don't know if it would be contained in the CPU flags in such cases.

Maybe someone has such a hardware available and can check.

[thestinger]

There are standard AArch64 AES instructions, which are comparable to AES-NI. These are supported on nearly every real world device. It's the aes feature in the CPU features. There are similar architecture features for sha2 and other things. AArch64 AES acceleration is not AES-NI. It's an ARM implementation of a similar feature.

What's different about mobile devices is that they typically provide the SSD controller as part of the SoC and include inline encryption support as part of it. This is far faster than the AES-NI style approach because no CPU cycles need to be used at all but rather data is decrypted/encrypted as it passes through the disk controller.

The inline encryption hardware also provides the ability to support a wrapped key feature, where the OS can choose to pass the inputs for obtaining the encryption key to the SoC and have it do the final key derivation and set up the inline encryption itself, with the OS having handles to the keys rather than access to the keys themselves, which provides the minor security property of the keys not being leakable via an OS information disclosure vulnerability.

On modern Android devices, AES CPU instructions are used for stuff like TLS and the disk controller's inline encryption hardware is used for disk encryption for far closer to zero performance or power overhead along with the wrapped key feature.

[py0xc3]

Thank you very much Daniel!

In this case, the different implementation of AES does not make a difference in our approach: it remains the aes flag on both x86_64 and aarch64. If the flag is true, there is AES, if it's false, there is no AES.

...learned something new today :)

These are supported on nearly every real world device

Not sure if I can agree on this. I have some devices (two netbooks, x86_64) that have no AES, one is build in 2016, the other I don't know but it is newer. An argument in the debate for adding Adiantum to the kernel was also that low budget devices often keep lacking AES, which was debated in 2019 and led Adiantum to be added to kernel 5.0. The cryptographic advantage of Adiantum was of minor relevance since its more theoretical.

But obviously my general assumption about devices having no AES because there was no AES-NI was wrong. So it's less worse than I thought.

[thestinger]

AArch64 CPUs mostly have the AES acceleration instruction set but all decent smartphones have inline encryption support that's far lower overhead than CPU AES instructions. Adiantum is for incredibly low end devices including ones that are still 32-bit ARMv7 devices.

SHA acceleration is also very important for Android due to verified boot for more than just boot time since there's continuous verification of all data read from the high level OS images via dm-verity that aren't simply read once, verified and then never read again. There's also fs-verity which we enforce in GrapheneOS for out-of-band system app updates to properly extend verified boot to those.

[thestinger]

Not sure if I can agree on this. I have some devices (two netbooks, x86_64) that have no AES, one is build in 2016, the other I don't know but it is newer. An argument in the debate for adding Adiantum to the kernel was also that low budget devices often keep lacking AES, which was debated in 2019 and led Adiantum to be added to kernel 5.0. The cryptographic advantage of Adiantum was of minor relevance since its more theoretical.

I'm talking about AArch64, not x86_64.

[py0xc3]

AArch64 CPUs mostly have the AES acceleration instruction

I'm talking about AArch64, not x86_64.

Sorry, I read your original sentence mistakenly as generally applicable to AES-NI and AArch64 AES. I can not say much about AArch64 of course

Adiantum is for incredibly low end devices including ones that are still 32-bit ARMv7 devices.

Well, it's for devices that have no AES hardware acceleration. If no AES hardware is available, Adiantum tends to be faster. The security level is practically equal, while their theoretical security depends on the emphasis since they have different advantages/disadvantageous but these differences are not yet relevant in practice.

As I said, I cannot say much about aarch64, but on x86_64, there are still many devices around that have no AES-NI and thus much better performance with Adiantum. So the x86_64 case is the primary target of this issue (and most widespread in Fedora). But Fedora also supports aarch64 so we have to consider it and of course avoid that an aarch64 system with AES hardware acceleration gets accidentally Adiantum. So that's why your incentives have been so valuable.

[thestinger]

The first standard 64-bit ARM cores (Cortex-A53 and Cortex-A57) had AES acceleration. Anything using the standard cores has it. I'm not sure if there are actually any production AArch64 CPUs without AES acceleration. It's technically optional, but that doesn't mean much when ARM has included it in their standard cores and seemingly everyone making custom cores included it.

[py0xc3]

64-bit ARM cores (Cortex-A53 and Cortex-A57)

I just remembered that during our discussion in the Fedora devel mailing list, another Fedora member has checked [1] the Raspberry PI's 2, 3, 4, and they all do not have an aes flag. I cannot verify it of course.

Don't these Raspberrys contain Cortex-A53 and successors?

Raspberrys are obviously a special case, but I'm curious now :)

[1] https://lists.fedoraproject.org/archives/list/[email protected]/message/PLHDMYFYENKKY4UUTBTFLJBGISF5ZXJU/

[thestinger]

For Cortex-A53, it seems it's an optional feature which can be excluded by the SoC manufacturer if they don't want to license AES and advanced SIMD support, so I guess there are actually low-end SoCs without it despite it being available with the standard cores from the beginning.

The optional Cryptography Extension is not included in the base product
of the processor. ARM requires licensees to have contractual rights to
obtain the Cryptography Extension.

I didn't realize that. I'm used to it always being there since AArch64 came out.

For the Cortex-A57, the same document implies it's always present.