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: 2) by Pino P on Friday August 10 2018, @06:13PM (9 children)
Would you prefer to have to charge or replace devices' batteries far more often so that they can run high-grade encryption?
(Score: 2) by Arik on Friday August 10 2018, @06:21PM (2 children)
And as long as we're talking about battery life, get rid of the stupid touch-screen and the google adware and your time between charge will go down dramatically.
If laughter is the best medicine, who are the best doctors?
(Score: 1, Touché) by Anonymous Coward on Friday August 10 2018, @08:38PM
I don't think this means what you think it does...
(Score: 2) by Thexalon on Friday August 10 2018, @11:54PM
Not to mention the backdoor crypto-currency mining that has probably been added to these devices. Either by the manufacturer, or by someone who got in due to your weak encryption, or both.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2) by insanumingenium on Friday August 10 2018, @07:14PM
Even if your false equivalence was accurate, the answer would be a resounding yes.
(Score: 2) by Runaway1956 on Friday August 10 2018, @07:27PM (2 children)
That may be the wrong question.
If this particular encryption is widely accepted for phones and other devices with limited power - then people are going to assume that it must be pretty good encryption. These encryption standards will then be adopted for use pretty much everywhere. The exceptions will be tech savvy people who know better, and/or the paranoid.
And, that is pretty much where we are today, anyway. Most people find that encryption is just too much of a hassle. Most people can't be bothered with anything as complicated as encrypting their mail, or even using HTTPS by default.
So, if a poor standard becomes widely accepted, then your average Joe is going to have a false sense of security. "Oh, everyone is using ROT13, it must be pretty good encryption!"
But, in response to the question you asked: Arik has it exactly right. The paying customer should be making that choice, not the NSA, the telephone vendor, the telco, or anyone else. Maybe I'll have to pay an extra $75 for the device capable of doing proper encryption - maybe I'll have to pay an extra $150. But, that choice should be mine, and it should be yours. It should not be the choice of corporate CEO's or government agencies.
(Score: 3, Touché) by insanumingenium on Friday August 10 2018, @08:39PM
Come on Runaway, no-one uses ROT13 anymore, we all went digital and use XOR 0xFF instead.
(Score: 1, Interesting) by Anonymous Coward on Saturday August 11 2018, @08:05AM
Then logically in order to have that choice this weak crypto SHOULD be included in the kernel. Because not allowing it in kernel is more likely to reduce choice than increase it. Without the code you don't have the choice of enabling/including it or disabling/removing it. The choice of not having it will have been made by someone else other than you or the customer. It's generally easier to disable existing code than to add code that's not included.
As for my opinion, having more choices is way OVERRATED! People don't need more choices. People need more GOOD choices (and fewer bad choices). More good choices increases the chance of making the right choice even if accidentally/ignorantly/mistakenly. Whereas just having more choices doesn't, and more bad choices increases the chances of making the wrong choice. Adding a weak crypto choice seems more like adding a bad choice. It's like adding another shit cake option to the shit cakes and chocolate cakes options for people to choose from.
Just look at WiFi to see what happens when crap security becomes a standard. You're stuck with crap security for decades even when the hardware can do so much better. Even though SSL2 was flawed if the WiFi bunch copied it back in the 1990s the security issues today would be on a different and more advanced level (and we would more likely to be able to have secure anonymous WiFi at Starbucks etc, rather than far weaker disgusting crap where everyone shares the same key and attackers can thus decrypt stuff if they get the handshakes).
(Score: 1) by khallow on Saturday August 11 2018, @10:56AM
(Score: 2) by sjames on Sunday August 12 2018, @11:55PM
That's not necessarily an issue anymore. It's easy to get an ARM suitable for Linux with AES in hardware. If that's too much power, it's also available in the Cortex-M line.
Why would anyone sane want to leave the dedicated hardware idle and crunch a much weaker cipher on the main CPU?