Will Arch enable Speck in kernel 4.17? Should it?

johnnyFive · 2018-06-06 13:53:18

My hope is that the answer is no, but I wanted to see what others thought rather than simply making the request myself.

This flew surprisingly under the radar; granted I'm not a professional infoSec guy, but it's an area I still try to keep up with. I'm sure other people here have heard of this, but I've provided some background on my question for those who haven't. I've tried to be as fair as I can to both sides, but I come down strongly in the "Speck should never be used" camp, so please bear that in mind.

Background

Speck (along with another algorithim called Simon) are ciphers developed in-house by the NSA, and first released in 2013. Their stated purpose is to provide a lightweight block cipher for a wide range of hardware, specifically those that are too slow to effectively use AES. A later paper by the authors was published (PDF) in 2015, and mentions that they had IoT devices in mind.

Around 2014, both algorithms were submitted to ISO for standardization. However, it met stiff resistence from the cryptography working group. First and foremost, some members from other countries simply didn't trust the NSA. They cited some of the Snowden documents, which included plans by the NSA to weaken publically-available cryptography, as well as other incidents like the Dual_EC_DRBG thing. (The tl;dr on that is the NSA submitted an algorithm for generating random numbers in cryptography to ISO without disclosing that they had a way to break it.) As Orr Dunkelman, an Israeli delegate to the ISO cryptography working group put it,

I don’t trust the designers. There are quite a lot of people in NSA who think their job is to subvert standards. My job is to secure standards.

The Japanese and German delegations also expressed misgivings. The NSA continued to lobby, but as described in a recent listserv post) by Dr. Tomer Ashur, who represented Belgium during those deliberations, the NSA was less than forthcoming, and was often dismissive of criticism and the critics. He also accused the NSA of using at best misleading information to support the security of these to ciphers, and of not responding adequately to criticsm and to existing attacks. (It's worth pointing out that despite submitting Speck to ISO in 2014, much of the information about it wasn't submitted until 2017). Other delegations were more comfortable with it, such as the British. Speck made it past the first round of votes at the ISO, those by individuals, only to lose at the next round (where each country gets a vote). The NSA also agreed to drop the weakest (i.e. lowest key size) versions from their proposal. These versions made it through by a single vote, but still had to undergo one more round of voting to be approved.

In May 2018, the ISO's cryptography working group and the subcommittee of which it was a part rejected Speck). The cancellation still requires a vote at the full committee level, which hasn't taken place yet.

Much of the criticism, as I mentioned earlier, was both with the NSA's reputation and with the way they handled the review process. One U.S.-based cryptography researcher, Nikos Komninos, said),

Unfortunately the NSA is lacking good reputation in academia. It’s not very long ago when AES was selected and the “optimised code” provided by the NSA had side channel flaws. Likewise, when the NSA proposed SHA-1 as a replacement of SHA then again there were security weaknesses. Bottom line is that in most cases, the NSA has pushed for adoptions/standards in which security vulnerabilities were found very soon after…

As for the NSA's handling of criticism, Dr. Ashur's e-mail that I linked above is absoultely worth reading. He says that the NSA was hostile to criticism (including attacking the credentials of the critics), and repeatedly refused to give details on how the algorithm worked. Even once information was provided, he found it to be misleading at best and even outright false in places. Dr. Ashur posted a shorter version) on Twitter, in which he described the NSA's behavior during the process as "outrageously adversarial." He also cited a general lack of trust in the NSA by the reviewers.

Speck and the Kernel

(I feel like there is an opening for a much cleverer title here, but I couldn't think of one.)

So now we come to the issue for Arch. Eric Beggers, a kernel contributor employed by Google, submitted a patch) for kernel 4.17 that includes support for Speck-128 in dm-crypt and fscrypt. His stated reasoning) seems to primarily focus on the speed aspect, saying that Google (or at least he) thinks it should be in there to allow low-end processors (such as ARMv7, which doesn't have built-in crypto) to have a viable way to use an encrypted file system. His initial responses to pushback are surprisingly condescending), and basically accuse critics of being inherently biased against the NSA while also arguing that "some encryption is better than no encryption." There's more technical detail later in the thread, but it still basically comes down to "something is better than nothing" (and he never does provide a good explanation for why the patch includes Speck-64, despite saying outright that a 128-bit key is the minimum).

This obviously doesn't have a ton of relevence to Arch, but again I wanted to give context. And, I think this further supports my argument that Speck should be disabled in Arch's version of the kernel. If it's a questionable algorithm (which it is, both in provenance and cryptanalysis) and it's designed for low-end hardware that isn't generally what people use Arch for, I don't think there's a reason to include it. Arch has a reputation as a tech-savvy distro, and every distro that accepts Speck is one more little bit of legitimacy for it that has not, from what I can tell, been earned.

To an extent this may just be a "principle of the thing" situation, as most people using Arch probably know better than to use some untested algorithm that few people have heard of. But that may not be the case, now or in the future, and there are also other distros that piggyback on Arch (such as Antergos) that geared towards less experienced or knowledgable people.

Last edited by johnnyFive (2018-06-06 13:59:34)

ooo · 2018-06-06 14:17:00

It's enabled as a module just like most of the other ciphers, so you can simply blacklist it if you don't want to use it.

vuudochile · 2018-06-13 19:58:22

would adding this to the bootloader's linux line effectively disable the module?

CONFIG_CRYPTO_SPECK=0

WorMzy · 2018-06-13 20:03:07

No.

https://wiki.archlinux.org/index.php/Ke … acklisting

progandy · 2018-06-13 20:06:38

You could also prevent pacman from installing the module in pacman.conf.

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

Last edited by progandy (2018-06-13 20:07:09)

Trilby · 2018-06-13 20:33:47

Blacklisting, kernel command line options (if they worked) and preventing pacman from extracting the module all have the same problem as I see it: it applies only to the system it is done on.

I know *nothing* about Speck, and care not much more than that. But as I understand it - correct me if I'm wrong - JohnnyFive's argument is that if Speck is readily available for use that could be read as an endorsement, and an unsuspecting user could use what may be an inadequate cipher. Anyone who already knows/believes Speck is inadequate will simply not use it in the first place, so there is no need for such people to take any of the above approaches to preventing themselves from using it.

I refrain from buying too much ice cream as if it is near by, I'll eat it. I don't need to refrain from buying a surplus of staples, as there is virtually no risk of me eating those. Any user who knows not to use Speck need not blacklisted it or prevent the module installation. The question is does providing Speck "built in" make it sufficiently more likely that some poor pica-afflicted individual will eat the staples and use the readily-available Speck cipher such that we'd be doing them a service by preventing that opportunity.

The decision to intervene in this way relies on two premises: 1) that there is sufficient justification to call Speck "bad", and 2) that we feel a need to nanny users and prevent them from potentially doing something "bad".

The first point may be controversial - but I believe it is irrelevant as the second point will never - in my mind - be valid. *nix doesn't prevent you from doing stupid things. Nor should it. If we wanted to prevent archers from doing truly horrible self-harmful things, we would not have emacs in the repos

That said, things like '--force' have been removed from pacman. So in cases where a tool that might have had good use just lead to far too much staple-eating, there may be cause for disabling that tool.

I do have to say though, that in any case, the following is just barking up the wrong tree:

johnnyFive wrote:

... there are also other distros that piggyback on Arch (such as Antergos) that geared towards less experienced or knowledgable people.

I'm not in favor of nannying arch linux users, but even if we did have cause for some nannying of archers, we really have absolutely no responsibility to cater to the users of derivative distros.

Last edited by Trilby (2018-06-13 20:41:32)

eschwartz · 2018-06-13 20:41:45

The other issue I see is that from the sound of it, it isn't a very useful module unless you're using an old arm CPU. Which would mean this module is just a source of bloat. I think all x86_64 CPUs should have support for much better ciphers in hardware.

Trilby · 2018-06-13 20:46:29

Very true. But this is arch linux after all:

Eschwartz wrote:

Yeah, um, Arch Linux has never been afraid to compile packages --with-kitchen-sink and include the resulting non-optional dependencies because "packages with more features are nice".

(for clarity, I'd much prefer stripping out everything from every package that isn't essential for it's function. But going on precident, this is not the arch way.)

Last edited by Trilby (2018-06-13 20:47:28)

ewaller · 2018-06-13 21:37:09

Trilby wrote:

If we wanted to prevent archers from doing truly horrible self-harmful things, we would not have emacs in the repos

Hey!

TL;DR For those not up to speed, Speck is a encryption algorithm that is not computationally taxing in an attempt to keep down the amount of energy used for the encryption process. The idea being to allow extremely low power devices (IoT, et al) to provide encryption of sensitive information without killing the power budget. This was presented to, and rejected by, ISO because the United State's NSA were promoting it and (allegedly) where not forthcoming with technical details. There is a fear that there may exist a backdoor in the algorithm, hence the controversy. I note, sarcastically, that Speck is not one of the encryption methods approved for use by FIPS-140-2.

Edit: My take on the situation -- Assume it is compromised. Use it as appropriate. Maybe it would not be the best choice for protecting banking credentials, or bitcoin passphrases, or weapons design; but, if one is protecting biometric data, or someone's meal order, who cares? Encrypted data are only safe as long as the value of those data are less than the cost of breaking the encryption. Prevent casual snooping and discourage MITM attacks/data injection. So what if someone out there knows how to determine my heart rate?

Last edited by ewaller (2018-06-13 21:48:27)

Xyne · 2018-06-13 23:32:54

Anything from the NSA should be viewed with deep suspicion. Their objective is clearly to undermine and compromise everyone else's security regardless of the consequences. Only a fool would keep accepting drinks from someone who regularly slips roofies in them. Especially when that person has a key to the bar, the bottling plant and the glass maker. Checking everything is beyond most people's capability so it is better to err on the side of caution, especially when multiple experts voice their concerns.

That should inform each user's decision with regard to NSA's algorithms. Whether or not that algorithm is enabled by default in the kernel is nevertheless a decision of the upstream kernel developers and all arguments against Speck's inclusion should be made there. I agree that enabling Speck by default is an indirect endorsement of the algorithm but it is not one made by Arch. Arch has a policy of using each package's default settings which avoids endless arguments about which settings should be enabled or not. Given that the algorithm must be actively selected by a user and can be disabled through the mechanisms mentioned above, including it in the kernel does not directly impact anyone's security. Users who wish to avoid bloat, which is a separate and broader issue, can recompile the kernel without the module if they so wish, which I assume they would be likely to do anyway in order to adjust other options.

I agree with the sentiment that it is not Arch's job to protect users against their own ignorance or to even consider the consequences for derivative users. Anyone trying to hide something from the NSA without doing basic research first is not going to succeed. Even if you use a strong cipher, they can just grab you and use rubber-hose cryptanalysis. I expect that someone who can hide from the NSA would know which ciphers to avoid.

And even if the cipher is compromised, it will be "good enough"® to prevent your stoner roommate from accessing your cryptocurrency wallet or Steam/Netflix account details.

Trilby · 2018-06-13 23:40:53

Xyne wrote:

Only a fool would keep accepting drinks from someone who regularly slips roofies in them.

Hey a free drink is a free drink. Besides, that all depends on one's goal in being out drinking in the first place and the attractiveness of the roofie-dropper.

Xyne wrote:

it will be "good enough"® to prevent your stoner roommate from accessing your cryptocurrency wallet or Steam/Netflix account details.

Roofies are good enough for that too.

Last edited by Trilby (2018-06-13 23:43:20)

Xyne · 2018-06-14 01:05:41

Trilby wrote:

Hey a free drink is a free drink. Besides, that all depends on one's goal in being out drinking in the first place and the attractiveness of the roofie-dropper.

Meh, if you're not going to remember anything, does attractiveness really matter? Bonus: no need to worry about how to get home.

Trilby wrote:

Xyne wrote:
it will be "good enough"® to prevent your stoner roommate from accessing your cryptocurrency wallet or Steam/Netflix account details.
Roofies are good enough for that too.

So, does this "stoner roommate" of yours keeps saying crazy things like "I don't live here" and "please mister, let me go, I promise I won't tell anyone"?

Trilby · 2018-06-14 01:31:33

I don't know. I've never been able to make anything out through the ball gag.

Remember kids, a good safeword should be easily intelligible when muffled.

ewaller · 2018-06-14 02:17:29

Um, okay.

Last thought before we continue down this humorous side road. Given that a three-letter-agency (TLA) could decode your data and discover something about you that might be worthy of blackmail, or that you are involved in petty crime: As was poignantly depicted in "The Imitation Game", secrets are fleeting; once it is known to you that your encryption has been compromised by an adversary, the adversary has to assume that you will immediately change your secret (or algorithm if it is broken)(*). Therefore, the adversary, to protect their advantage, must not tip their hand that they are reading your messages. One would think that the aforementioned TLA, assuming they have gone out of their way to back door an international standard, are not going to provide any indication they have done so by prosecuting anything less than a state, or a large criminal organization in any way that is in the public view? OTOH, as pointed out in the referenced movie, they may come up with an alternate, plausible explanation how the data were discovered. But, why? Again, if the data are not worth the cost of obtaining (or using) them, the data are safe.

Edit: And again I note, it is not in FIPS-140-2, so Uncle Sam ain't gonna be using it....

Edit 2:
(*) Or, if you don't that you could be feeding them misinformation

Last edited by ewaller (2018-06-14 02:22:31)

Xyne · 2018-06-14 02:28:35

Trilby wrote:

I don't know. I've never been able to make anything out through the ball gag.
Remember kids, a good safeword should be easily intelligible when muffled.

At least we finally know what happend to Phrak and Dusty...

@ewaller
Parallel construction is a genuine concern. Besides, some secrets are important even if there are no probable legal repercussions from their revelation. It's also very difficult to foresee how such information may be used in negative ways beyond prosecution, or once the value of denying the backdoor is lost.

ewaller · 2018-06-14 04:04:55

Xyne wrote:

@ewaller
Parallel construction is a genuine concern. Besides, some secrets are important even if there are no probable legal repercussions from their revelation. It's also very difficult to foresee how such information may be used in negative ways beyond prosecution, or once the value of denying the backdoor is lost.

No argument there. I was merely giving a tour of the dark corners.

vuudochile · 2018-06-14 05:57:39

Even if one choses not to use it you guys miss the point of legitimacy. Any provider of email, bank accounts, customer information, etc etc. can and will use it as it came in the kernel. Whether the choice is innocent or suspect or whether ...else ... they will say "we didn't make this encryption cipher, they did, we just use it because everyone does". So ultimately it is Linus Tro. that undertakes the responsibility to legitimize such a thing. The fact that Gloogel passed it on to him and he cosigned it makes no difference, if it is Linux it has his signature on it.
How many people will go to their webmail or bank provider and inquire which encryption cipher are they employing to protect their data? Effectively none, even if some geeks ever get an answer instead of being expelled for asking.
Distributions now know it, they have the choice to continue underwriting the legitimacy of this or not. The excuse that it is fast so it can be used by arm devices is running thin.

Trilby · 2018-06-14 10:29:24

$ pacman -Qo /bin/md5sum
/usr/bin/md5sum is owned by coreutils 8.29-1

Huh. It's still there. I suppose this means GNU is signing off on using md5 as cryptographic hash. Right?

Xyne · 2018-06-14 13:10:45

@vuudochile
If your bank, email provider or other business is running their infrastructure on ARM devices, I would have some questions beyond which cipher they choose.
I would also have several questions if they use Arch Linux or anything with code crafted by Allan.*
If they choose a cipher without knowing what it is because it was the first one they saw in an options list, they I wouldn't trust them regardless of the cipher.
Even if they have a sound and secure infrastructure, the three-letter organizations still have (questionably) legal means to compel them to surrender your data.
The choice of a weak cipher may be intentional so that they can claim security with less overhead. If that is their motivation then they will simply re-enable the cipher even if their distribution disables it.

Banana analogy

If your organization chooses the banana, then they can't be trusted to make wise decisions even if the banana is taken off the table. Furthermore, removing the banana from our table doesn't necessarily remove it from theirs. Even if it did, they could still put it back on their own because the guy who gave them the table decided to give out free bananas. If they see bananas on other people's tables and conclude that a banana must be the best weapon on theirs while ignoring all of the other candidates on their table and the others, then they are incompetent.

However, I agree that including it by default implies an endorsement and legitimacy. It's like selling alternative "medicine" in a pharmacy alongside proven medicine, only we are not talking about products sold separately but rather questionable products bundled inside the box of indispensable ones. They should be removed upstream rather than asking everyone else to open the box and remove it themselves. That would be the best way to undermine the apparent legitimacy.

* I'm being facetious here, in case it's not clear. I understand that the argument is that by enabling this cipher, Arch's apparent support may be cited elsewhere.

p.s. Regardless of all technical and policy decisions, inevitably there will be at least one tired, incompetent or malicious person in charge of data management at some point in any organization who can compromise important security measures. Your data is never "safe" with a third party.

Trilby · 2018-06-14 13:51:29

You do realize the banana is the only one of those options that you can bring on a plane. Given that I feel a greater need for personal security while travelling than on an ordinary day, the banana makes a wise choice: it can get through security and offer plausible deniability.

Of course as soon as the one truly and completely useless three letter agency sees this post, they'll start confiscating banana's at airport security too.

Soon we'll have "banana control" as a political issue.

Last edited by Trilby (2018-06-14 13:52:19)

ewaller · 2018-06-14 14:18:32

Trilby wrote:

Of course as soon as the one truly and completely useless three letter agency sees this post, they'll start confiscating banana's at airport security too.

Snort! At least I managed not to spill my coffee down the front of me as I laughed.

Xyne · 2018-06-14 14:24:09

Donkey Kong, president of the National Banana Association, wrote:

I'll give you my banana when you pry it from my cold, dead paws!

progandy · 2018-06-14 14:41:54

Trilby wrote:

Soon we'll have "banana control" as a political issue.

That was already done http://www.europarl.europa.eu/unitedkin … nanas.html

Awebb · 2018-06-14 15:01:56

1. I hope they don't turn on $FEATURE.
2. The NSA made it.
3. Drugging and date rape.
4. Gagballs and hostages.
5. Eurobanana.

Finally a normal conversation on this Linux board! I was always afraid something was very wrong with you guys, but now I'm relieved.

vuudochile · 2018-06-15 14:12:37

Xyne wrote:

@vuudochile
1 The choice of a weak cipher may be intentional so that they can claim security with less overhead. If that is their motivation then they will simply re-enable the cipher even if their distribution disables it.
2 p.s. Regardless of all technical and policy decisions, inevitably there will be at least one tired, incompetent or malicious person in charge of data management at some point in any organization who can compromise important security measures. Your data is never "safe" with a third party.

1 If you have ever worked on large hierarchical organizations you know that nobody wants to take responsibility for things and those that must take some responsibility in order for anything to get done they choose "what the majority" chooses, because it is easier to defend. Sometimes they hold committee meetings to make a collective decision and take collective responsibility. They are not going to allow any hacker they hired yesterday at low level IT to make decisions, because his decisions are the responsibility of the supervisor ... etc. etc... This is where the issue of legitimacy comes into play. Debian is using it, Arch is using it, why am I at fault for choosing "a standard in the industry" - it is in linux anyway. This is where such efforts of blocking the arms of the hydra become effective. This is where you start thinking twice on how far you can trust linux and its choices. I am sure if someone really wanted to use this free and open "software" they still could even if it was hiding in the most remote git space on earth.

2 I can understand and fully agree, you can't really trust anyone but yourself, and your GNU compiler, with your data. So we have taken one risk, we trust the compiler, then we trust the kernel, then we trust hw sent down by the allmighty (inter/AMD-engineering) or we would hand write notes inside a faraday globe and sit on top of them with a gun - as data protection. Why are Luks developers still alive, I wonder Because 99% of the "important population" is using windows and macs.

3 The political aspect of all this is "why do we need to worry?".

Arch Linux

#1 2018-06-06 13:53:18