Speck Crypto Code Called For Removal From The Linux Kernel

[phoronix]

Phoronix: Speck Crypto Code Called For Removal From The Linux Kernel

Now that Google will not be using the Speck crypto code for disk encryption on low-end Android devices but instead developing "HPolyC" as outlined in the aforelinked article, a plea has already been submitted to remove the current Speck code from the mainline Linux kernel...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-RFC-Remove-Speck

[squash]

That sure didn't take long!

As Google was the only driver for Speck and has determined they can do better, it would make sense to follow them to a superior solution. A bad solution is worse than no solution.

[DrYak]

Not everyone though seems in favor of dropping this Speck support as it may prove useful in some verticals where an efficient (albeit not necessarily the strongest) encryption implementation may be desired

...and we have already the chacha20-poly1305 for these use case, which is very efficient too, but unlike speck doesn't compromise strenght and doesn't have a dubious origin.
(chacha20-poly1305 is even currently the preferred algo for SSH when there's no hardware AES).

speck doesn't bring anything worth on the table that isn't already better handled by others.

[Weasel]

...and we have already the chacha20-poly1305 for these use case, which is very efficient too, but unlike speck doesn't compromise strenght and doesn't have a dubious origin.
(chacha20-poly1305 is even currently the preferred algo for SSH when there's no hardware AES).

speck doesn't bring anything worth on the table that isn't already better handled by others.

Probably NSA shills.

[c117152]

Probably NSA shills.

Without actually looking into it, as a general rule of thumb, an efficient cipher is an insecure cipher. After all, the whole point is to make it computationally hard to brute force so if you're not paying a lot in time and power, the adversary will just throw more machines on it.

But my math is WAY too rusty to actually weight in on any of this.

[DrYak]

The key derivation function - the thing you use to get a n-bit vector key (usually n=256 or more) out of the password typed by the end user - is the part that needs to be computationally hard, because the total of possible password a human brain can come with is abysmally tiny, and an attacker could (and usually does) bruteforce the whole range.
(See things like PBKDF2, Scrypt, Argon2, etc.)
That's the reason why you don't simply use a salted *HASH* (like SHA256) to store password, it's too fast, rely on a key derivation function.


Once you've got a n-bit key vector to input into your crypto algo, brute forcing is out of the question.
If the algo is any good (if it isn't DES or RC4) brute-forceing would require to scan all possible 256bit numbers, which isn't practically possible (downfall of civilisation, and possibly heat death of the universe - depending on the key size - would happen first).
At that point you need to crypto algorithm to be :

- as fast as possible so you can process a lot of data.
AES is very efficient when done in hardware.
Poly1305-chacha20 is very efficient even in software implementation.
Speck was supposed to bring something similarly fast, but might be broken (and could be broken intentionnally).

- this speed should NOT be data dependent.
There are way to make AES faster in software, but you would need to do branches and memory access depending on data, instead of straight math/deterministic table look-ups. By carefully measuring timings, caches access, etc. it's possible to gues *what* this optimized AES was encrypting.
That why the efficient AES software implementation are insecure. It's not the speed *by itself*, but the type of optimisation done to gain the speed come with side channel risks.
Instead we rely on slower AES implementation that always behave exactly the same, no matter what the data currently being encrypted. It's slower but better.
Hardware was a way to bump that a bit faster while keeping the secure approach.

Poly1305-Chacha20 was subsequently developed (by Daniel J. Bernstein himself) as a better algorithm that can be written in a faster way without the side channel risk (even the high speed version always does exactly the same thing no matter the data, you can't guess anything by measuring).

Speck was then later developed for no clear reason (it's not even faster than Poly1305-Chacha20, that one already covers the need), that's why it's actually okay to throw away.

Google upcoming HPoly replacement seems to be their variation on the same concepts (it seems to *also* be based around chacha20).

[DrYak]

an efficient cipher is an insecure cipher. After all, the whole point is to make it computationally hard to brute force so if you're not paying a lot in time and power, the adversary will just throw more machines on it.

The TL;DR version of my above post.

If it's something that is a small search space (e.g.: the number of possible password that a human brain can spit out is <<< than 256+ bit number), you want slow processing, because the attacker can actually scan the whole range of input, rather than all the numbers
(again, use PBKDF2, Scrypt or Argon2 instead of salted SHA for your password needs)

If it's something that can accept any random 256+ bits number, you're safe and you can make it faster, specially if it needs to process lots of data (hardware AES, software Poly1305-Chacha20, etc.)

[smitty3268]

If the algo is any good (if it isn't DES or RC4) brute-forceing would require to scan all possible 256bit numbers, which isn't practically possible (downfall of civilisation, and possibly heat death of the universe - depending on the key size - would happen first).

Or you just invent a workable quantum computer. I'm sure the NSA isn't interested in anything like that.

[Girolamo_Cavazzoni]

Symmetric ciphers are quantum-proof. It's the asymmetric ciphers you should be worried about.