Eric Biggers and Paul Crowley were unhappy with the disk encryption
\noptions available for Android on low-end phones and watches. For
\nthem, it was an ethical issue. Eric said:<\/p>\n
We believe encryption is
\nfor everyone, not just those who can afford it. And while it’s
\nunknown how long CPUs without AES support will be around, there
\nwill likely always be a “low end”; and in any case, it’s immensely
\nvaluable to provide a software-optimized cipher that doesn’t depend
\non hardware support. Lack of hardware support should not be an
\nexcuse for no encryption.<\/p><\/blockquote>\nUnfortunately, they were not able to find any existing encryption
\nalgorithm that was both fast and secure, and that would work with existing
\nLinux kernel infrastructure. They, therefore, designed the Adiantum
\nencryption mode, which they described in a light, easy-to-read and
\ncompletely non-mathematical way<\/a>.<\/p>\nEssentially, Adiantum is not a new form of encryption; it relies
\non the ChaCha stream cipher developed by D. J. Bernstein in 2008.
\nAs Eric put it, “Adiantum is a construction, not a primitive. Its
\nsecurity is reducible to that of XChaCha12 and AES-256, subject to
\na security bound; the proof is in Section 5 of our paper. Therefore,
\none need not ‘trust’ Adiantum; they only need trust XChaCha12 and
\nAES-256.”<\/p>\nEric reported that Adiantum offered a 20% speed improvement over
\nhis and Paul’s earlier HPolyC encryption mode, and it offered a very
\nslight improvement in actual security.<\/p>\nEric posted some patches, adding Adiantum to the Linux kernel’s
\ncrypto API. He remarked, “Some of these patches conflict with the
\nnew ‘Zinc’ crypto library. But I don’t know when Zinc will be
\nmerged, so for now, I’ve continued to base this patchset on the
\ncurrent ‘cryptodev’.”<\/p>\nJason A. Donenfeld’s Zinc (“Zinc Is Not crypto\/”) is a front-runner
\nto replace the existing kernel crypto API, and it’s more simple and
\nlow-level than that API, offering a less terrifying coding experience.<\/p>\nJason replied to Eric’s initial announcement. He was very happy to
\nsee such a good disk encryption alternative for low-end hardware,
\nbut he asked Eric and Paul to hold off on trying to merge their
\npatches until they could rework them to use the new Zinc security
\ninfrastructure. He said, “In fact, if you already want to build it
\non top of Zinc, I’m happy to work with you on that in a shared repo
\nor similar.”<\/p>\nHe also suggested that Eric and Paul send their paper through various
\nacademic circles to catch any unanticipated problems with their
\nencryption system.<\/p>\nBut Paul replied:<\/p>\n
Unlike a new primitive whose strength can only
\nbe known through attempts at cryptanalysis, Adiantum is a construction
\nbased on well-understood and trusted primitives; it is secure if
\nthe proof accompanying it is correct. Given that (outside competitions
\nor standardization efforts) no-one ever issues public statements
\nthat they think algorithms or proofs are good, what I’m expecting
\nfrom academia is silence \ud83d\ude42 The most we could hope for would be
\ngetting the paper accepted at a conference, and we’re pursuing that
\nbut there’s a good chance that won’t happen simply because it’s not
\nvery novel. It basically takes existing ideas and applies them using
\na stream cipher instead of a block cipher, and a faster hashing
\nmode; it’s also a small update from HPolyC. I’ve had some private
\nfeedback that the proof seems correct, and that’s all I’m expecting
\nto get.<\/p><\/blockquote>\nEric also replied, regarding Zinc integration:<\/p>\n
For now
\nI’m hesitant to completely abandon the current approach and bet the
\nfarm on Zinc. Zinc has a large scope and various controversies
\nthat haven’t yet been fully resolved to everyone’s satisfaction,
\nincluding unclear licenses on some of the essential assembly files.
\nIt’s not appropriate to grind kernel crypto development to a halt
\nwhile everyone waits for Zinc.<\/p><\/blockquote>\nHe added that if Zinc is ready, he’d be happy to use it. He just
\nwasn’t sure whether it was.<\/p>\nHowever, in spite of the uncertainty, Eric later said, “I started
\na branch based on Zinc:
\nhttps:\/\/git.kernel.org\/pub\/scm\/linux\/kernel\/git\/ebiggers\/linux.git<\/a>, branch
\n‘adiantum-zinc’.”<\/p>\nHe listed the work he’d done so far and the work that remained to
\nbe done. But regarding Zinc’s remaining non-technical issues, he said:<\/p>\nBoth
\nmyself and others have expressed concerns about these issues
\npreviously too, yet they remain unaddressed nor is there a documentation
\nfile explaining things. So please understand that until it’s clear
\nthat Zinc is ready, I still have to have Adiantum ready to go without
\nZinc, just in case.<\/p><\/blockquote>\nJason was happy to see the Zinc-based repository and promised to
\nlook it over. He also promised to add a documentation file covering
\nmany of Eric’s concerns before posting another series of Zinc
\npatches. And as far as Eric and Paul being ready to go without Zinc
\nintegration, he added, “I do really appreciate you taking the time,
\nthough, to try this out with Zinc as well. Thanks for that.”<\/p>\nMeanwhile, Herbert Xu accepted Eric and Paul’s original patch-set,
\nso there may be a bit of friendly shuffling as both Zinc and Adiantum
\nprogress.<\/p>\nIt’s nice to see this sort of attention being given to low-end
\nhardware. But, it’s nothing new. The entire Linux kernel is supposed
\nto be able to run on absolutely everything\u2014or at least everything
\nthat’s still in use in the world. I don’t think there are too many
\nactual 386 systems in use anymore, but for real hardware in the
\nreal world, pretty much all of it should be able to run a fully
\nfeatured Linux OS.<\/p>\nNote: 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.<\/em><\/p>\n