SoylentNews is people
SoylentNews
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.
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.
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.
(Score: 4, Informative) by Rich on Friday August 10 2018, @07:30PM (1 child)
I just looked up the AES speed of an STM32. Found measurements of a 50 MHz ARM Cortex M3 for one implementation:
https://realtimelogic.com/products/sharkssl/Cortex-M3/ [realtimelogic.com]
Between 250 (slowest mode) and 750 (fastest mode) KB/sec. That's the baseline of the cheapest CPU available for gadgets. Today's eBay price for a bluepill board: 1,67 EUR + shipping within Germany. This CPU is way too small to run Linux. Even if that is only the remote IoT device, I don't see any use case where such a small system would require transmitting the amount of data it could encrypt or decrypt on the fly.
We might assume micropower-8-bit IoT clients, but then on the host side, a userland library for such fringe cases would easily do. Besides, if anything has enough power for a TCP stack, it should easily do AES on the side.
Conclusion: The inclusion is not a good idea, because in the end it will be included in the major distro kernels and then be a risk for all kinds of breakage, where connections can "accidentally" fall back.
(Score: 1, Informative) by Anonymous Coward on Friday August 10 2018, @09:09PM
Also, it is not uncommon for SoC to have AES hardware engine for offloading encryption.