It seems that “Speck” is a long term project to standardize encryption that goes around the internet. It seems as the NSA has been the primary force proposing what is “pretty good” encryption and what is not. It doesn’t take a genius to assume that only encryption that can be decrypted by the NSA can be proposed. So this set of new rules is making its way into your open and free software. It is in Linux 4.17, not on 4.16 or previous ones, and 4.17.1 was just announced as stable yesterday.It is not what is in there but what is not that is important. We don’t feel knowledgeable enough to discuss the matter but we thought an alert to read and judge for yourselves is proper. Patches to remove the crap are being worked on and tested, but Linus is OK with Speck! I don’t know what Spock would think about this.
update: I found this interesting post in Arch Forums
Will Arch enable Speck in kernel 4.17? Should it? (and the answer is “they did enable it” and linux4.17.1 is out and unsuspecting users are upgrading from their 4.16) https://bbs.archlinux.org/viewtopic.php?pid=1790075
My hope is that the answer is no, but I wanted to see what others thought rather than simply making the request myself.
This flew surprisingly under the radar; granted I’m not a professional infoSec guy, but it’s an area I still try to keep up with. I’m sure other people here have heard of this, but I’ve provided some background on my question for those who haven’t. I’ve tried to be as fair as I can to both sides, but I come down strongly in the “Speck should never be used” camp, so please bear that in mind.
Speck (along with another algorithim called Simon) are ciphers developed in-house by the NSA, and first released in 2013. Their stated purpose is to provide a lightweight block cipher for a wide range of hardware, specifically those that are too slow to effectively use AES. A later paper by the authors was published (PDF) in 2015, and mentions that they had IoT devices in mind.
Around 2014, both algorithms were submitted to ISO for standardization. However, it met stiff resistence from the cryptography working group. First and foremost, some members from other countries simply didn’t trust the NSA. They cited some of the Snowden documents, which included plans by the NSA to weaken publically-available cryptography, as well as other incidents like the Dual_EC_DRBG thing. (The tl;dr on that is the NSA submitted an algorithm for generating random numbers in cryptography to ISO without disclosing that they had a way to break it.) As Orr Dunkelman, an Israeli delegate to the ISO cryptography working group put it,
I don’t trust the designers. There are quite a lot of people in NSA who think their job is to subvert standards. My job is to secure standards.
The Japanese and German delegations also expressed misgivings. The NSA continued to lobby, but as described in a recent listserv post) by Dr. Tomer Ashur, who represented Belgium during those deliberations, the NSA was less than forthcoming, and was often dismissive of criticism and the critics. He also accused the NSA of using at best misleading information to support the security of these to ciphers, and of not responding adequately to criticsm and to existing attacks. (It’s worth pointing out that despite submitting Speck to ISO in 2014, much of the information about it wasn’t submitted until 2017). Other delegations were more comfortable with it, such as the British. Speck made it past the first round of votes at the ISO, those by individuals, only to lose at the next round (where each country gets a vote). The NSA also agreed to drop the weakest (i.e. lowest key size) versions from their proposal. These versions made it through by a single vote, but still had to undergo one more round of voting to be approved.
In May 2018, the ISO’s cryptography working group and the subcommittee of which it was a part rejected Speck). The cancellation still requires a vote at the full committee level, which hasn’t taken place yet.
Much of the criticism, as I mentioned earlier, was both with the NSA’s reputation and with the way they handled the review process. One U.S.-based cryptography researcher, Nikos Komninos, said),
Unfortunately the NSA is lacking good reputation in academia. It’s not very long ago when AES was selected and the “optimised code” provided by the NSA had side channel flaws. Likewise, when the NSA proposed SHA-1 as a replacement of SHA then again there were security weaknesses. Bottom line is that in most cases, the NSA has pushed for adoptions/standards in which security vulnerabilities were found very soon after…
As for the NSA’s handling of criticism, Dr. Ashur’s e-mail that I linked above is absoultely worth reading. He says that the NSA was hostile to criticism (including attacking the credentials of the critics), and repeatedly refused to give details on how the algorithm worked. Even once information was provided, he found it to be misleading at best and even outright false in places. Dr. Ashur posted a shorter version) on Twitter, in which he described the NSA’s behavior during the process as “outrageously adversarial.” He also cited a general lack of trust in the NSA by the reviewers.
Speck and the Kernel
(I feel like there is an opening for a much cleverer title here, but I couldn’t think of one.)
So now we come to the issue for Arch. Eric Beggers, a kernel contributor employed by Google, submitted a patch) for kernel 4.17 that includes support for Speck-128 in dm-crypt and fscrypt. His stated reasoning) seems to primarily focus on the speed aspect, saying that Google (or at least he) thinks it should be in there to allow low-end processors (such as ARMv7, which doesn’t have built-in crypto) to have a viable way to use an encrypted file system. His initial responses to pushback are surprisingly condescending), and basically accuse critics of being inherently biased against the NSA while also arguing that “some encryption is better than no encryption.” There’s more technical detail later in the thread, but it still basically comes down to “something is better than nothing” (and he never does provide a good explanation for why the patch includes Speck-64, despite saying outright that a 128-bit key is the minimum).
This obviously doesn’t have a ton of relevence to Arch, but again I wanted to give context. And, I think this further supports my argument that Speck should be disabled in Arch’s version of the kernel. If it’s a questionable algorithm (which it is, both in provenance and cryptanalysis) and it’s designed for low-end hardware that isn’t generally what people use Arch for, I don’t think there’s a reason to include it. Arch has a reputation as a tech-savvy distro, and every distro that accepts Speck is one more little bit of legitimacy for it that has not, from what I can tell, been earned.
To an extent this may just be a “principle of the thing” situation, as most people using Arch probably know better than to use some untested algorithm that few people have heard of. But that may not be the case, now or in the future, and there are also other distros that piggyback on Arch (such as Antergos) that geared towards less experienced or knowledgable people.
[note Jul-12-2018: As of now antiX artix and void have the module turned off in their versions of linux-4.17 – Arch has intentinally turned on the module that defaulted as off from kernel.org ]