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.