NSA’s Encryption Algorithm in Linux Kernel is Creating Unease in the Community

Linux Kernel 4.17 saw the inclusion of NSA’s ‘controversial’ encryption algorithm Speck. Linux Kernel 4.18 will see Speck being available as a supported algorithm with fscrypt and not everyone is happy about it.

Before you panic or form wrong conclusions, you should know that Speck is not a backdoor. It’s just a not-so-strong encryption algorithm from American agency NSA and it’s available as a module in Linux Kernel.

USA’s National Security Agency (NSA) is infamous for being privacy-invasive. It’s past actions cast doubts on every step it takes.

NSA had even approached Linux creator Linus Torvalds to create a backdoor in Linux kernel. An offer, Linus Torvalds refused immediately.

The dark story behind NSA’s Speck Algorithm

NSA's controversial Speck encryption is now in Linux Kernel 4.17

The algorithm in question, Speck, is a ‘weak’ encryption (lightweight block cipher) designed for devices with low computing powers i.e., IoT devices.

NSA wanted Speck and its companion algorithm Simon to become a global standard for next generation of internet-of-things gizmos and sensors.

NSA tried to aggressively push this algorithm to an extent that some cryptographer alleged bullying and harassment at the hands of NSA.

The problem with the algorithm is that the International Organization of Standards (ISO) rejected Speck and Simon.

International Organization of Standards (ISO) blocked NSA’s “Simon” and “Speck” algorithms amid concerns that they contained a backdoor that would allow US spies to break the encryption.

The Register

Though no researcher found any backdoor in Simon and Speck, the algorithms were rejected by ISO because NSA didn’t even provide the normal level of technical detail to researchers. This increased the speculation of a backdoor in the algorithm.

If Speck algorithm was rejected by ISO, then how come it landed in Linux Kernel 4.17?

The quick answer is: Google.

Google engineer Eric Biggers requested the inclusion of Speck in Kernel 4.17 because Google is going to provide Speck as an option for dm-crypt and fscrypt on Android.

The focus is on providing encryption on Android Go, an Android version tailored to run on entry-level smartphones. As of today, these devices are not encrypted because AES is not fast enough for the low-end devices.

Lots of speculation in the Linux community over Speck

Alert Linux users spotted the inclusion of Speck in the Kernel 4.17 and since then it has become a debate topic in various Linux communities on the internet.

Arch Linux users already started discussions on blocking the Speck module from Kernel.

What’s interesting is that the Speck module has defaulted as off from kernel.org but Arch Linux has it turned on by default. Don’t ask me why.

How to disable Speck from Linux Kernel [Advanced users only]

If you are an average Linux user with Ubuntu, Mint, Fedora and other non-rolling release distributions, chances are that you are not even using Kernel 4.17.

I don’t recommend it for everyone but if you are an advanced user who is habitual of messing with the kernel, check the Linux kernel version and if it uses Kernel 4.17, you may blacklist the Speck kernel module.

If it doesn’t exist already, create /etc/modprobe.d/blacklist.conf file and add the following lines to it:

blacklist CONFIG_CRYPTO_SPECK

Update: I am not sure if it was the impact of our story here but it looks like Speck will be removed from Linux Kernel. Apparently, Google has now dropped the idea of using Speck for Android Go and since no one is going to use this algorithm, there is no point in keeping it in Kernel.

What do you think of Speck and its inclusion in Linux Kernel 4.17?

I’ll repeat that no one has proved that Speck has a backdoor. It’s just the ill reputation of NSA that is causing the speculations.

What do you think of the entire episode? Do you think it’s right to include Speck encryption in the Kernel? Should it not be disabled by default by all the distributions unless it is intended to be used on a device?

Featured image via DeviantArt

Similar Posts

  • The first half of the article alludes to the NSA being the driving force of a kernel patch for Speck, to only then reveal Google as the patch submitter. Google, in being the maintainer of one of the largest forks of Linux, Android (AOSP and/or Google Play), would expectantly submit kernel patches. Google’s choice in algorithm (Speck) may be questionable, and there’s little indication, beyond an engineer’s decision, of overt NSA influence at work.

    Google’s Android has long supported dm-crypt (LUKS) for full device encryption. While I found it good to see Google concerning themselves with file level encryption, I was a bit perplexed as to why AES or other alternative ciphers wouldn’t work; Unless, and especially, if using completely antiquated CPUs. Again, back to engineering decisions, to which I can’t glean from referenced materials.

    • Google id “deep state” along with NSA (natch) – as Windows is on the wane they need to backdoor all platforms – it is their goal. Step one – the Kernel – And believe me they are/will be pushing plenty more “Trojan Horses” into the Linux kernel/GNU in covert operations – Beware Peoples!

      I would not trust Google with ANYTHING – They have proven they are EVIL. It’s obvious – if their intentions were true they would put strong, validate encryption – LUKS, AES, whatever.

      Think again – why indeed woud the “super-power security agency” aka NSA even have a “half-baked” encryption in their cupboard to give away – come-on I think you can work that out…

  • Remember when they(MS) pushed compromised drivers to add backdoors on windows and then they(NSA) asked the companies to sign them