Eric Biggers and Paul Crowley were unhappy with the disk encryption options available for Android on low-end phones and watches. For them, it was an ethical issue. Eric said:

We believe encryption is for everyone, not just those who can afford it. And while it's unknown how long CPUs without AES support will be around, there will likely always be a "low end"; and in any case, it's immensely valuable to provide a software-optimized cipher that doesn't depend on hardware support. Lack of hardware support should not be an excuse for no encryption.

Unfortunately, they were not able to find any existing encryption algorithm that was both fast and secure, and that would work with existing Linux kernel infrastructure. They, therefore, designed the Adiantum encryption mode, which they described in a light, easy-to-read and completely non-mathematical way.

Essentially, Adiantum is not a new form of encryption; it relies on the ChaCha stream cipher developed by D. J. Bernstein in 2008. As Eric put it, "Adiantum is a construction, not a primitive. Its security is reducible to that of XChaCha12 and AES-256, subject to a security bound; the proof is in Section 5 of our paper. Therefore, one need not 'trust' Adiantum; they only need trust XChaCha12 and AES-256."

Eric reported that Adiantum offered a 20% speed improvement over his and Paul's earlier HPolyC encryption mode, and it offered a very slight improvement in actual security.

Eric posted some patches, adding Adiantum to the Linux kernel's crypto API. He remarked, "Some of these patches conflict with the new 'Zinc' crypto library. But I don't know when Zinc will be merged, so for now, I've continued to base this patchset on the current 'cryptodev'."

Jason A. Donenfeld's Zinc ("Zinc Is Not crypto/") is a front-runner to replace the existing kernel crypto API, and it's more simple and low-level than that API, offering a less terrifying coding experience.

Jason replied to Eric's initial announcement. He was very happy to see such a good disk encryption alternative for low-end hardware, but he asked Eric and Paul to hold off on trying to merge their patches until they could rework them to use the new Zinc security infrastructure. He said, "In fact, if you already want to build it on top of Zinc, I'm happy to work with you on that in a shared repo or similar."

He also suggested that Eric and Paul send their paper through various academic circles to catch any unanticipated problems with their encryption system.

But Paul replied:

Unlike a new primitive whose strength can only be known through attempts at cryptanalysis, Adiantum is a construction based on well-understood and trusted primitives; it is secure if the proof accompanying it is correct. Given that (outside competitions or standardization efforts) no-one ever issues public statements that they think algorithms or proofs are good, what I'm expecting from academia is silence :) The most we could hope for would be getting the paper accepted at a conference, and we're pursuing that but there's a good chance that won't happen simply because it's not very novel. It basically takes existing ideas and applies them using a stream cipher instead of a block cipher, and a faster hashing mode; it's also a small update from HPolyC. I've had some private feedback that the proof seems correct, and that's all I'm expecting to get.

Eric also replied, regarding Zinc integration:

For now I'm hesitant to completely abandon the current approach and bet the farm on Zinc. Zinc has a large scope and various controversies that haven't yet been fully resolved to everyone's satisfaction, including unclear licenses on some of the essential assembly files. It's not appropriate to grind kernel crypto development to a halt while everyone waits for Zinc.

He added that if Zinc is ready, he'd be happy to use it. He just wasn't sure whether it was.

However, in spite of the uncertainty, Eric later said, "I started a branch based on Zinc: https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git, branch 'adiantum-zinc'."

He listed the work he'd done so far and the work that remained to be done. But regarding Zinc's remaining non-technical issues, he said:

Both myself and others have expressed concerns about these issues previously too, yet they remain unaddressed nor is there a documentation file explaining things. So please understand that until it's clear that Zinc is ready, I still have to have Adiantum ready to go without Zinc, just in case.

Jason was happy to see the Zinc-based repository and promised to look it over. He also promised to add a documentation file covering many of Eric's concerns before posting another series of Zinc patches. And as far as Eric and Paul being ready to go without Zinc integration, he added, "I do really appreciate you taking the time, though, to try this out with Zinc as well. Thanks for that."

Meanwhile, Herbert Xu accepted Eric and Paul's original patch-set, so there may be a bit of friendly shuffling as both Zinc and Adiantum progress.

It's nice to see this sort of attention being given to low-end hardware. But, it's nothing new. The entire Linux kernel is supposed to be able to run on absolutely everything—or at least everything that's still in use in the world. I don't think there are too many actual 386 systems in use anymore, but for real hardware in the real world, pretty much all of it should be able to run a fully featured Linux OS.

Note: if you're mentioned above and want to post a response above the comment section, send a message with your response text to ljeditor@linuxjournal.com.