FFS Linus you fucking traitor.

https://itsfoss.com/nsas-encryption...

WHAT :O

Should be mad at Google.

Interesting. The concerns about it raise a bit of a dilemma. If the security of open source is derived from it's openness, why the concern about who wrote it? And, if it's not easy to verify the code, isn't that a problem in general?

Granted, it's the NSA who have huge resources and a poor agenda, but, still...

Why's it on by default in Arch?

Lmao

Because clearly the NSA is contributing this to the open-source community out of the goodness of their hearts. No ulterior motives whatsoever. Pinky swear.

@platypus it's crypto, and crypto is not just the code. It's also the whole math stuff and analysis behind it. From what the article says, the NSA didn't provide the full background analysis, which makes it fishy. The backdoor wouldn't be on code level, but in the math itself.

@devios1 Clearly their motives should be suspect, but does the model rely on all contributors to be altruistic? Is the "many eyeballs" thing more theoretical than practical?

@Fast-Nop So code can be validated, but not the underlying algorithms?

I guess the key is that they are not making it *easy* to validate, which should draw suspicion.

@platypus Code validation is relatively easy (though still hard enough for crypto because of more attack ways), but there just aren't that many crypto experts world wide who can validate the underlying math. It's so hard that regular devs like you and me wouldn't even understand what they are talking about.

@platypus Certainly being open source is better than not, but just because something is open source doesn’t mean weaknesses or exploits would be necessarily obvious from the get-go. I would always be worried in the back of my mind that they might have some way to crack it that they’re keeping secret, OR they just want to push a weak algorithm so it will be easier for them to snoop on people and things in general. I mean honestly though, what other reason could they possibly have? The NSA is not in the habit of doing things in the public interest.

@Fast-Nop Yes. I'm just trying to get my head round why this differs from other hard stuff (eg other crypto) in open source. And I guess it's the lack of detail provided by the NSA (according to the article). So, the general principle might be don't trust code where you have an objective reason to believe data has been withheld.

@platypus yeah. Actually, the C source code is already the compiled math formula and proof documents, which are the real source code, so to say. Openness would also involve that stuff.

@devios1 I fully agree that their motives are a concern. I'm just using the situation to ponder the management of open source. Always useful to reflect on these things, I find.

Presumably Bruce Schneier (sp?) will blog on it. Should be an interesting read.

@platypus I’m certainly not an expert, but I fully expect there will be lots of experts looking at it, which surely the NSA would have expected, so if they did try to get away with anything it would have to be pretty ingeniously hidden deep in the math.

@devios1 Yes. But this is an area where the NSA may well have more full-time experts, and considerably more resources, then the rest of the world combined. Well, maybe if we exclude China, but can't see their security services publishing a flaw.

The private sector just hasn't really valued encryption---hence the unusual imbalance.

@platypus I think that’s exactly what worries us. It wouldn’t be a flaw. At least not in the accidental sense.

Come to think of it, why would Google allow this, I mean what will Google gain? They could have used some other encryption standards, I am sure there are plenty available. This will simply lead to mistrust and indulgence of judiciary, just like FB. Wouldn't it?

Time to compile a custom kernel without that crappy speck of shit on all my hosts..

Looks like it's meant to be included solely for Android Go, for low-power devices.. which would be an improvement because they're not encrypted yet. Seems legit actually, but still with the current status quo of OEM's not providing Android kernel source, what stops them from compiling it even into the flagship devices? Things need to change, and they better change fast.

@Condor I don't think my servers are at risk running 3.10 but I am using 4.17 on my home machine. I should do some research before I go fiddle with my kernel though. 😦

Most distros aren't on it yet but it wouldn't surprise me if a number of them disable it.

@starrynights89 Exactly. The only distro that's on 4.17 already as far as I know, is Arch. If you're running the stock kernel, I think that you can check for it by doing something like this:
$ zgrep CONFIG_CRYPTO_SPECK /proc/config.gz
If that returns CONFIG_CRYPTO_SPECK=M or CONFIG_CRYPTO_SPECK=y you'll want to blacklist or install a different kernel respectively.

On Arch it's a module. Blacklisting would be a nice fix, but if at all possible compile your own and file complaints with Arch's maintainers.

@Condor I checked it out and it's been disabled. I'm running Manjaro so it looks like they moved ahead of whatever decisions the Arch distro made.

It's BS that it was put in the Kernel but at least the user base has control over it.

@starrynights89 Just asked around in #archlinux as well, and was met by.. well let's say very inappropriate responses and being called names like tinfoil hat. I sincerely hope that they were all users but even some of the moderators participated in the ridicule. Absolutely insane. If you'd like I can post a log of it, but it ain't pretty.

@Condor I’d be interested in seeing that as well.

@Condor If you want to, I'd find it entertaining. :P The Arch Wiki is helpful but the user base is...less than helpful.

@starrynights89 I've recently uploaded it. Quite a long read but the gist of it is that they apparently understood the concern, but still found it appropriate to ridicule people for asking justification or removal. https://clbin.com/Uk6R3

@starrynights89 Oh, one line in particular that I find entertaining..
Foxboron j605: i dont think its default in upstream.... dunno how to check

Such leetiness!!! Holy shit, OMG that sakurity pro level!!! :O

@codechimp Yeah I'd rather have no idea what vulnerabilities the NSA is trying to (and succeeding to) include in the proprietary equivalents of an OS. /s

@Condor Users != Developers. We're different animals. :)

@starrynights89 Absolutely. After digging a bit deeper, I hope that I'll be able to - if necessary - convince the maintainers better in the mailing list. Hopefully it'll be safe to assume that they all know their kernel stuff and how to look something up in a kernel config.

Still, if only the community could make itself as good as their Holy Wiki (that is honestly not so holy when it concerns kernel configs, Gentoo Handbook is way better for that)... Eh, I guess that's the price you pay for being part of a community that enjoys the ease of a binary distribution. As for me, I'm migrating most of my newer hosts to a custom kernel as well now. Hopefully that won't nuke the server whose fans are already spinning pretty violently in this heat...

@platypus I find that this line is a very good argument: 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.

And then, do we remember the backdoored algo that was pushed (not proven to be backdoored but no other explanation as to why someone would want to push an extremely slow algo so badly) into the world with force years ago by the NSA? They want to break every algo available so I definitely get the concern.

@codechimp oh yeah sure let me switch to an OS which can't be verified as for source code at all and of which the companies are already integrated within a huge NSA powered mass surveillance network.

Also, how has this to do with being a fanboy? And hobby os?! I make my living with being a Linux engineer, thanks.

Do you want to see the market share of Linux as for servers? ;)

@linuxxx
Not only that but it doesn't find any use outside of IoT, which Arch Linux doesn't target. While it may be useful for low-power devices (that should really just get a decent cryptographic module already), it has no place in desktop or server Linux where AES performance is often pretty decent. Even a Raspberry Pi can do it. Androids on the other hand.. well yeah maybe watches, but phones? Sure full system encryption is important, but I'd always prefer strong over cheap cryptography in its full disk encryption (dm-crypt) scheme.

@Condor Fucking agreed.

My favorite part from that article: "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."

@linuxxx Yeah, if there is no backdoor why wouldn't you show the full spec wtf

@linuxxx You can monitor your network activity and assess the packets in ANY OS.

'Enabled in Arch Linux by default'

Good luck isn't one of the things I usually have. :(

@linuxxx
You make you living of it does not make it great and secure.
Many part of the kernel can not be inspected and is not free.

The hell, the only OS that has real security in mind is OpenBSD. They disabled multithreading because it MIGHT be an security issue.
For me, they do not compromise with security.

With that said, do I hate Linux? Not at all! But we NEED to see the flaws and problems with it. And when we can do that - we can inprove it.

@Stallman Every system has security flaws. If the NSA truly wanted to go after me I'd have no real repercussions beyond seeking asylum from the US. Kim Dotcom is still fighting the extradition demand from the US government going on its 5th year.

Linux is as insecure as is BSD as is Windows and Mac. The best encryption is how far the user is willing to go to stay secure. /endrant

But you're correct, the Kernel does have a number of known security flaws that have yet to be fixed. I'm not a security expert but I know Specter was a known issue from Intel for 16 years before it was discovered by security research teams?

@starrynights89

Well said.

Every system has flaws, but the ignorance from Linus sometimes makes me angry as fuck. Not too long ago he admitted that he knew about some flaws since many year - but he did not fix it because it was "quite annoying and hard bug".

When people like him do stuff like that, he should shut up when he throws shit at other devs when they are contributing to the kernel.

@starrynights89
Agreed.

@Linux The greatest strength is also the biggest weakness of FOSS. Anyone who can contribute is welcome to but no one single person is in charge of the path. And if you really don't like things, fork it. Thus Linux is a different beast from distro to distro, and even in how the kernel works depending on the fork.

I have more respect for Linus then distaste but he does need to STFU a lot.

Long thread, could read it all but here's my view:

A. The NSA is known for spying, it's their job, but they also do security, and have written numerous security algorithms and programs which were standard and considered safe for a long time, notably SHA1 and SELINUX.

B. The NSA didn't ask for it to be put into the kernel, Google did. Because AES is too heavy. Obviously Google thinks it's good enough.

C. It's not required to use. Disable it if it makes you uncomfortable.

D. The NSA, like anyone who actually uses computers efficiently and with purpose, runs alot of Linux. They would not weaken it if without the ability to disable it.

@deadPix3l C. Can you reasonably ask every single user to blacklist it? People aren't going to change - no they aren't even going to notice - a bad part in their OS. It's up to the developers and maintainers to not succumb to a bad cipher that hasn't been scrutinized very well by independent researchers, and certainly didn't get received well by said people. The NSA even ended up calling researchers incompetent over their desire to learn more about the algorithm instead of just explaining the technical details.

@Stallman I never said that.

Sure, there are some proprietary drivers but as far as I know there are some distro's which come explicitly without those.

Any system with SELinux? That fucker is a security hardener for sure.

And I see those flaws but can't do anything about it myself right now.

@Condor no I can't and don't. It's available as one option for kernel level encryption. Not the only option. So unless it's an IoT device which can't handle it, AES will probably remain the default algorithm for people who haven't changed it. And as for IoT makers: well it's either NSA sponsored encryption which is rumored to be bad, verifiably bad encryption, or no encryption. Honestly it's the best we got right now in that field.

That is definitely going into my blacklist.

@deadPix3l but the Arch Linux kernel which doesn't target IoT, why does it need to be a module in there of all places? Its usefulness in IoT is theoretical, but Arch Linux isn't built for IoT. So why then would it need to be there at all?

I'm all for freedom of choice when it comes to implementations that best suit the purpose, and I'm all for distribution kernels supporting pretty much all hardware, filesystems, kernel compression algorithms and ciphers. But I don't want that to come at the cost of having a piece of (shit)code attempting to use Speck where it isn't necessary, especially when that means that the NSA could very well have a backdoor in the algorithm. I'd rather not have the NSA build cryptographic algorithms at all actually, since they really aren't the right organization for that.

@Condor agreed on the first part. And I will be disabling it personally. That's more of an outrage to be had at Arch rather than Linus or NSA.

On the algorithms point: I get it. It's conflicting. On the one hand, an agency who's job it is to spy on people writing algorithms is sketchy. On the other: their job is to break codes. Therefore they employ some of the nation's best cryptographers, and are therefore in a perfect position to write algorithms. Let's not forget they also are tasked with a defense mission as well.

@deadPix3l My thoughts exactly. I've disabled it in my own kernels because I won't ever be using it over proper AES for my LUKS volumes (and in phones I better not see Google use it in anything but the cheapest of the cheapest shit either). It has some theoretical use in IoT which I've mentioned in recent comment on my own rant as well.. but I doubt that aside from the oddball that wants to unlock and mount his IoT device's storage media, it should be used or supported for anything. And even then, if the NSA really cared about security in IoT, why didn't they invest in making AES-NI more viable in entry-level processors instead?

@Condor I'm assuming because AES-NI is good for low powered x86, it's not really an option for ARM or other RISC architectures. In those cases, a safe but not miserably slow algorithm is required because AES can't perform well in those cases

@codechimp How does that help me if the backdoor would be an RCE vulnerability hidden in the code somewhere? That wouldn't show any network traffic but could be exploited from a distance.

Umm.. looks like it's getting removed lol:

http://lkml.iu.edu/hypermail/linux/...

http://lkml.iu.edu/hypermail/linux/...

@MEGADROID as much as I get it, yes. State subverted crypto is bad, it's definitely not an improvement to go without encryption.

Y'know what's worse than using crypto that's know to be backdoored by someone, giving them unlimited access to your messages? NOT using crypto at all, giving everyone everywhere unlimited access to your messages...

Maybe we should fine a suitable replacement for low powered processors incapable of AES-NI before we dismiss these algorithms.