Will Speck, the NSA encryption in the Linux kernel, finally be removed?

tux-nsa

There was a great stir (and a lot of discussion) with the inclusion of Speck encryption in the Linux kernel a few months ago and during this time he has given much to talk about during this time.

The reason behind this hostility is the origin of the algorithm: Speck it was in fact created by the NSA, a fact that raises more than a few suspects from insiders.

The US government agency has not built a good reputation other than back door insertion and respect for privacy.

But beyond that you don't even have to give valid reasons for many of the algorithm implementation options.

Controversy

In fact, the NSA has declined to explain why a certain number of rounds were chosen, for example, when a comparison was requested from cryptologists.

The NSA had even targeted the creator of Linux, Linus Torvalds, to create a backdoor in the Linux Kernel. An offer that Linus Torvalds immediately refused.

The NSA's reluctance to provide more details on the algorithm below has fueled suspicions that some decisions have been made consciously.

Intended to conceal backdoor that would allow the agency to penetrate the undisturbed defenses of cryptographic systems.

The algorithm in question, Speck, is a 'weak cipher (lightweight block encryption) designed for devices with low computing powers, i.e. IoT devices.

The NSA wanted Speck and his fellow algorithm Simon to become a global standard for the next generation of Internet-of-Things gizmos and sensors.

The NSA tried aggressively to push this algorithm to the point where some cryptographers alleged harassment and harassment at the hands of the NSA.

The problem with the algorithm is that the International Standards Organization (ISO) rejected Speck and Simon.

Speck was included in Linux kernel 4.17 between supported algorithms and Linux 4.18 had seen its arrival among the algorithms used in file system encryption (via fscrypt).

nsa-logo

The reason behind the inclusion, despite the worries, it was on the part of Google's request to include the algorithm for use on some low-end Android devices, for which other encryption algorithms do not guarantee a sufficient level of security.

The problem persists, but ...

This request, however, fell after the NSA did not provide sufficient explanations to design options.

So much so that Google created the new HPolyC algorithm specifically for devices with low computing power.

Although also early last month Google reversed its plans to use Speck as a cheap filesystem encryption medium for lower-end Android Go devices.

Instead he is developing HPolyC as a new and safer approach. Google developers said they would not oppose the Linux kernel's Speck code.

There was then an RFC to remove the Speck code from the Linux kernel, but to date it has not been acted upon.

With the current updates to the cryptographic code for Linux 4.19 there are no changes to the Speck code.

Also, since Linux 4.18 and in Git 4.19 so far, Speck-based fscrypt support remains like this that the more time there is in the nucleus.

The greater the likelihood that Speck will stick to the mainstream so as not to break existing support for anyone who has already tried this method of file system encryption.

Therefore, there are no other major sponsors for Speck that can justify its inclusion in the kernel: for this reason it was decided to completely remove the encryption.

The patches are now ready for removal, to be completed with Linux 4.20 / 5.0, but it is possible that Speck will be removed even before the patches are ready as backup ports for current kernels.


Leave a Comment

Your email address will not be published. Required fields are marked with *

*

*

  1. Responsible for the data: Miguel Ángel Gatón
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.