Adiantum - Storage encryption for those without AES-NI

Why?

Adiantum is a solution for encrypting store when there isn't enough CPU power for the traditional solution. This is a real problem in cell phones, where the low-end models are very CPU and energy constrained, and don't have the instruction set necessary for making disk encryption work efficiently otherwise.

On modern laptop/desktop machines, where FreeBSD typically runs, this is not a serious problem; those CPUs have more than enough horsepower for encrypting disks (BTDT). And unlike Google's cellphone OS (Android) and Linux (which runs on many embedded platforms, and in some fashion I don't understand shares source code with Android), FreeBSD is not used much in the portable and embedded world.

Now I'm not saying that it shouldn't be done; only that it is probably not a high priority for FreeBSD. But if someone has an argument for why it would be valuable, let's hear it.
 
The developers of modern software are often biased towards recent hardware and older still useful hardware gets scrapped for no other reason than it doesn't support 'XYZ' that is in whatever cpu or gpu architecture. If you are used to living in an an environment with continuous mains AC power, continuous broadband or 4G internet, and affordable brand new computers to unbox, your view on what is modern will be different to those that don't enjoy these benefits.

I live in less populated rural part of the United Kingdom. I can't afford to buy brand new computing kit. People like me that buy used computing hardware find that even 32 bit hardware is still useful in 2019 in a variety of cpu architectures particularly those low power consumers such as thin-client terminals.

'Thins' can be repurposed with FreeBSD for as long as 32-bit is still supported or until 2038 when the 32-bit unsigned integer date rollover occurs. They make great hardware choices for off grid locations with solar power or other limited locally generated power supply on land or sea. Those with VIA cpus have AES built in, but anything with an older intel Atom or a 'mobile' variant of a desktop cpu wont. For these machines, encrypton is an expensive cpu cycle luxury. An old 32-bit Atom based notebook computer can still be usuable with Gnome3 on FreeBSD 12.0 but disk encryption can make them too slow even with an SSD.

I currently use 1Ghz VIA Eden thin clients with 1GB RAM as Samba 4 Active Directory domain controllers. They are running 32-bit FreeBSD 12.0 with tuned ZFS perfectly with a UFS sysvol on ZFS. They are dedicated to that one task and are as rugged as a consumer router when a power failure occurs.

I am a relic from an 8-bit computing era. I remember the advances made jumping from 8-bit to 16-bit and then on to 32-bit. 64-bit hasn't delivered any real improvement for me over 32-bit for most of my use cases other than in server virtualisation. Most of my mains powered server and desktop equipment is now 64-bit. Predominantly four core intel Xeon with a few AMD quad cores, but none of them has AES-NI. The next version of pfSense will have a mandatory requirement for AES-NI. This is the first example I can think of for a FreeBSD based system forcing obsolescence of a perfectly usable 64-bit machine architecture (X86_64 non AES-NI).

I believe that free software developers should try to ensure that hardware can be used for as long as it can before it goes to landfill. If a benefit can be introduced in software that will increase the useful lifetime of computing hardware then I think that this benefits everybody. In the case of GELI using Adiantum, those of us with older 64-bit hardware without AES-NI won't have to make that performance, security or scrap it decision.
 
The next version of pfSense will have a mandatory requirement for AES-NI. This is the first example I can think of for a FreeBSD based system forcing obsolescence of a perfectly usable 64-bit machine architecture (X86_64 non AES-NI).
pfSense is a derivative, and this decision is theirs, it's not mandated by FreeBSD. FreeBSD has no control whatsoever over derivative projects. Whatever a derivative project decides to support or not is their prerogative.

You're basically barking up the wrong tree in this respect.
 
I like pfSense, and wish them well. I don't like the forced AES-NI thing, but I respect that it is that project's right to decide amongst themselves the direction they go in. I was simply using them as an example of modern software forcing obsolescence of a usable hardware platform.

I believe that Adiantum in GELI is something that is worth my time experimenting with. If some Linux developer puts Adiantum in to ZFS on Linux (ZoL) and it finds its way into ZFS on FreeBSD (ZoF) it would make Adiantum in GELI less important to me personally other than for encrypted swap.

I agree that Adiantum in GELI should be a low priority, particularly compared to modern wifi. GELI already supports more than just AES so without looking at the existing code it might not actually be a big problem to do.
 
I agree that Adiantum in GELI should be a low priority, particularly compared to modern wifi. GELI already supports more than just AES so without looking at the existing code it might not actually be a big problem to do.
It should be added to the crypto(9) framework. That way it's not only GELI that could benefit from it.
 
'Thins' can be repurposed with FreeBSD for as long as 32-bit is still supported or until 2038 when the 32-bit unsigned integer date rollover occurs.
Existing 32-bit CPUs are perfectly capable of performing 64-bit operations, just a bit slowly, and not atomically. The atomicity can be fixed by appropriate locking, which uses some extra CPU cycles. And timestamp operations are so rare that the performance impact (even with locking) is not a big deal. The 32-bit hardware does not prevent Unix from going to a timestamp format that continues to work after 2038. If there is any problem there, it's software, and traditional APIs.

...
but anything with an older intel Atom or a 'mobile' variant of a desktop cpu wont. For these machines, encrypton is an expensive cpu cycle luxury.
My server at home is exactly that: a 1 GHz 4-core Atom. I don't use software-based disk encryption on it, but I do use ZFS, which keeps checksums. Performance is adequate for home use; I get at least 50 MByte/s out of my file systems reading or writing, and since my network hardware within the house is only gigabit or WiFi, that's sufficient. Similar to your setup.

I just looked up the expected performance: On an Atom D525 (which I think is what I have at home), AES runs at ~20...50 MByte/s, which is probably not good enough for production use, except for hobbyists with low requirements. ChaCha (which is what Adiantum is based on) runs at ~100 MByte/s, which is probably good enough for a single disk drive, and marginal for an SSD. So from a performance viewpoint, the need for Adiantum is marginal on that hardware (yes for production, no for hobbyists). On more modern hardware, in particular those with the AES in the instruction set, Adiantum is not really necessary.

Again: Even when not necessary, it is still nice to have. So I'm not against doing it.
 
I have a Raspberry Pi 4 (aarch64), and I use it to run a non-exit Tor relay. The project recommends AES-NI, but the SoC on the Pi doesn't have it. Adiantum adds a significant improvement in speed, so it would be nice to have that in FreeBSD.
 
Looks like it is GPLed (2.0), so the algorithm would need to be re-implemented. Probably not too big a deal but still annoying.
 
I have a Raspberry Pi 4 (aarch64), and I use it to run a non-exit Tor relay. The project recommends AES-NI, but the SoC on the Pi doesn't have it. Adiantum adds a significant improvement in speed, so it would be nice to have that in FreeBSD.
Do you happen to have numbers from the Pi of AES versus Adiantum when used in the disk layer?
 
Well, looks desirable. Half the CPU time is good. But somebody has to actually sit down and make a BSD license implementation. And since it's crypto, better not screw up.
 
Back
Top