Thank you Arch Linux community for saying that caring about security (i.e. expressing concerns about NSA's Speck being included as a module in Arch's distribution kernel) means that you're a tinfoil hat. Much trust, very wow! Nothing to hide, nothing to fear.. right?

Really? That happened?

@ewpratten I even have chatlogs of it if you'd like.
https://clbin.com/Uk6R3

At first I read NASA, and I was *very* confused...

@Condor wow..

@ewpratten You gotta love the Arch community <3

Just filed a subscription request to the arch-security mailing list. Let's see what they have to say. Regardless of what it's doing or whether it's secure, this module doesn't belong in Arch Linux which targets x86_64 PC only, whereas the only place where Speck would be even worth considering is IoT and Android wearables like smart watches and *maybe* the cheapest of the cheapest in smartphones.

OpenBSD here I come

Well, it's a module. You can rebuild the kernel without, right?

@Vyrr That's exactly what I'm doing now, for a few of my more recent Proxmox VM's that haven't had a custom kernel compiled from them yet. I'm also looking at LXC to ease compilation needs by only having to compile a host kernel and having the containers all use that one, similar to how a chroot works (in fact I think that LXC even builds upon chroot as well).

The issue is that while I could compile my own kernel and I could ask everyone to compile their own (hah, wish me luck with that, many don't even know make), that's not the way that this should be addressed in the long run. This cipher has no place in Arch Linux, and while this is largely FUD, the NSA has been known to push weak cryptographic schemes before.

Also ISO declined the standardization request, and it's been widely criticized by security professionals in much higher positions than I am - and that holds true even at the upstream kernel which @Linux recently ranted about. As for me, I will contact the Arch Linux mailing list and express my concerns there soon, and after more research into this and further arguments against its implementation contact the kernel mailing list as well.

This is not a good idea, even in IoT and entry-level devices I highly doubt its usefulness. And on PC the performance of AES is plenty. It'd be irresponsible of Arch Linux' maintainers or the Linux development team to shove this under the rug IMO.

Recently I've submitted an email to the Arch Linux security mailing list.. hopefully they'll respond soon. Currently it's awaiting moderator approval.
s/protocol/cipher btw.. if only I could edit emails...

@Condor That chat log gave me the shivers. Even if irc is not the right place to start things, it looked like they just dismissed your opinion from the very beginning, and just made up "answers". Sort of odd, I've seen some of them being more patient on way dumber subjects.

Well, this sucks. I can't afford to build my own kernel on Arch (due to zfs-dkms being... Not so reliable), but FreeBSD looks like a great solution right now. I hope the e-mail you sent will work :<

Am I missing something or is this literally a for loop with some bit shifting? I don't see how that would affect the security of your system.

1/2

Honestly, I kinda see the point of the Arch guys. The inclusion of the module in the config was most likely a mistake when updating the config to a new kernel, maybe even the result of running make oldconfig.

However, I don't see how this might have any relavance to the security of a system. Since a.) it is build as a module and does not even load per default b.) as someone already said, it's just a bunch of loops, it's not like the module provides a way for code execution.

The only possible security implication arises when someone explicitly uses this cipher instead of something more secure like AES. In that case any backdoor in the algorithm could be leveraged to ease/allow the decryption of the encrypted data.

I'm not sure what your point really is. You can also just run `zcat /proc/config.gz | grep CONFIG_CRYPTO` and see that there are tons of other ciphers enabled as modules in the kernel config, some of them are most likely also unsafe to use.

2/2

Also the actual kernel commit was provided by a Google engineer and not the NSA itself. I did not check it, but the NSA most likely only provided some reference implementation in a whitepaper and not any concrete kernel code.

And personally if I were an Arch developer I would have disabled the option. But only to keep the kernel config simple (when it's possible - not on the Arch kernel) and not for security reasons.

@bootleg-dev @R01101111bert

You are absolutely correct. Especially when the encryption scheme used to create the LUKS volume is not using Speck (which it shouldn't), and there's a theoretical use for the occasional oddball who wants to unlock and mount the storage of their IoT device that uses this cipher. It should not however be used in any machine that has AES-NI, i.e. pretty much every modern x86_64 machine these days. And even on machines without these instructions, its use should be carefully thought over and compared against the alternatives.

This cipher is better than having nothing at all in IoT devices, but if the NSA really cared about the security of those, their solution shouldn't have been an algorithm that's weakened to achieve better performance. It should've been the effort to ensure the viability of these AES-NI instructions in entry-level processors.

And don't even get me started on the people that would use this Speck cipher on their "secure" LUKS-encrypted machine just because it's faster. Such a thing would not cause damage to the usual targets of the NSA, RCE and network analysis prevention. But usually you encrypt your system for a reason - to prevent unauthenticated people / organizations from accessing it. I haven't looked at its source code yet - will do so soon - but from what I understand so far, it's too weak to be used in LUKS / dm-crypt.

Needless to say, NSA with their track record of attempting to weaken cryptographic standards doesn't really help either.

...I completely forgot about it, but this simple line in pacman.conf really solves the issue on Arch:

NoExtract = usr/lib/modules/*/kernel/crypto/speck.ko.xz