Bug 2077532 - Hardware without AES-NI: use xchacha12/Adiantum instead of AES-XTS
Summary: Hardware without AES-NI: use xchacha12/Adiantum instead of AES-XTS
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: python-blivet
Version: 35
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Blivet Maintenance Team
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2022-04-21 14:29 UTC by Christopher Klooz
Modified: 2022-06-09 17:38 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Fedora 35 KDE spin on an old Intel Celeron N2940 (issue is anaconda-specific and thus, likely to exist on all Fedora Workstations and architectures).
Last Closed:
Type: Bug

Attachments (Terms of Use)

Description Christopher Klooz 2022-04-21 14:29:56 UTC
Description of problem:
This is a feature request, not a bug.

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.

Comment 1 Vendula Poncova 2022-05-03 13:11:37 UTC
It looks like it could be automatically detected by our storage library. Reassigning to Blivet for further investigation.

Comment 2 Christopher Klooz 2022-06-09 17:38:33 UTC
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".

Note You need to log in before you can comment on or make changes to this bug.