Replace AES-XTS with Adiantum (when no AES-NI is available) to improve battery life time and performance (it is already available in the kernel; it can be used as option in cryptsetup/dm-crypt/fscrypt alternatively to AES-XTS)

[py0xc3]

On https://grapheneos.org/faq#encryption it is indicated, that disk encryption remains limited to AES-XTS.

However, Google developed "Adiantum" intentionally for Android in order to be used on devices without AES-NI (hardware AES implementation) because of the problems and disadvantageous implications with AES software implementations. Adiantum was added to the Linux kernel in 5.0, so it is reviewed by both Android developers and the Linux kernel community, and available in both the vanilla Linux kernel and in the Android kernel. You can find the discussions in the kernel mailing list archives if you want to review them. Adiantum is an alternative witihin cryptsetup/dm-crypt and fscrypt, so that it can be used as option instead of AES-XTS. Therefore, if something is compatible with cryptsetup/dm-crypt and/or fscrypt with AES-XTS, it is also compatible with Adiantum.

Hostile exploitation of the AES software implementation in the kernel might be unrealistic today in most circumstances, but AES-XTS remains a problem for the battery life time when no AES-NI is available. Of course the performance is also strongly impacted (negatively) if there is no AES-NI available because AES is not designed for software. In short, AES-XTS needs much more power, cpu resources and time to process data than Adiantum.

Thus, I would suggest to use Adiantum instead of AES-XTS when grapheneos is installed on devices without AES-NI.

On Fedora, we have it already on the To Do list, and I already elaborated this more deeply there (the arguments also apply to grapheneos), so I do not copy them but just provide links:
https://bugzilla.redhat.com/show_bug.cgi?id=2077532
storaged-project/blivet#1108

Relevant pages:
https://eprint.iacr.org/2018/720.pdf -> this is the official paper that is also referred to in the Kernel Docs
https://lwn.net/Articles/776721/ -> relevant for the use cases
https://www.kernel.org/doc/html/latest/filesystems/fscrypt.html -> relevant data about Adiantum; this page is formally only about fscrypt, but as far as it concerns Adiantum, most applies to its dm-crypt use as well.

At least most devices that are supported by grapheneos do not have an AES-NI. At a rough initial search, I haven't found a binding technical paper, but given all sources I found on the Internet, even the Tensor chips of Nexus 6/7 do not have it (lscpu | grep aes should indicate if AES-NI is available on a given device: if nothing is output, there is no AES-NI, if the flags are output, there is an AES-NI; I have not yet checked how to get a terminal on graphene :) ).

I have just started to work with grapheneos (and AOSP at all) and I have only limited time to focus on it, so my information for this proposal is currently limited to what I read on https://grapheneos.org/faq#encryption -> feel free to close this ticket if my information source is incomplete.

Besides the proposal, thanks for providing this elegant os ;)

[thestinger]

There aren't any devices we support without AES acceleration. AArch64 AES acceleration isn't AES-NI. AES-NI is an x86 instruction set extension.

[py0xc3]

Interesting. I didn't know arm/aarch64 implement AES differently. Thanks for letting me know ;)

[thestinger]

The devices we support have CPU acceleration for AES which is used by BoringSSL, etc. It's not used for disk encryption since that would waste CPU cycles on disk encryption. The SoC includes a UFS disk controller with support for AES acceleration and that's used to decrypt/encrypt data without spending CPU cycles on it. In fact, on the Pixel 6 and later, the encryption keys are never made available to the OS so an information leak vulnerability in the kernel, etc. being exploited isn't enough to obtain the keys for later decryption of the device's data from the storage. The acceleration is called inline encryption support and the key protection feature is called wrapped key. It's tied into how the key derivation is implemented:

https://grapheneos.org/faq#encryption

We don't yet explain wrapped key there since it's not particularly important compared to the rest.