
Crypto: speck – remove Speck - doener
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git/commit/?id=578bdaabd015b9b164842c3e8ace9802f38e7ecc
======
LadyNike
For those interested, Eric Biggers, the author of the patch which added Speck
support, sent an RFC the previous day to add HPolyC support to the kernel.

[http://lkml.iu.edu/hypermail/linux/kernel/1808.0/05226.html](http://lkml.iu.edu/hypermail/linux/kernel/1808.0/05226.html)

------
cjhanks
So is the presumption that Google would write a more honest and correct
encryption algorithm than the NSA? The irony is at least a little funny.
People distrust the NSA because they use highly invasive technology to
identify suspicious behavior. But Google is trusted, and they use highly
invasive technology for profit.

Honestly, I generally trust both of them. But, technology politics are very
confusing.

~~~
bjoli
Google's track record regarding crypto is high. NSA has done a lot of good,
but recently behaved bad (backdoored random number generator) weird (not
explaining uncommon design decisions) and counterproductive (representatives
either being or acting stupid on various cryptography standard body mailing
lists).

Google on the other hand has been doing a very nice job

------
dmitrygr
I actually used speck in a project of mine. It compiles to very very tight
code even on an 8-bit micro, much smaller than AES. Since my attack profile
does not include nation-states I see no issues in using it in my use case.
Sometimes even speck may be the right tool for the job.

~~~
craftyguy
> Sometimes even speck may be the right tool for the job.

I disagree. Proliferation of very-likely-backdoored crypto is dangerous. By
using it you're demonstrating that it is OK to use crap the NSA is pushing. If
it gains in popularity, you'll have people trying to use it for sensitive
communications, etc, without understanding why it is a terrible idea.

~~~
tptacek
It is extraordinarily _unlikely_ that Speck is backdoored, since it's a
(deliberately) simple ARX block cipher transform, a close cousin to a variety
of other block cipher designs from academic cryptography.

~~~
tialaramex
Yeah, [https://lwn.net/Articles/762152/](https://lwn.net/Articles/762152/) has
a full source code to Speck. It's like - OK, where is the backdoor, is eight
the backdoor, or is three? Did the NSA sneak a backdoor into the idea of
binary arithmetic when that was invented?

If people want to pick fights with the NSA, fine, but this may have been the
dumbest possible fight to pick.

How does the implementation of HPolyC look in terms of whether I would notice
if you hid something naughty in there?

~~~
tptacek
Speck was announced to the world in a paper with design documentation,
diagrams, and source code. Just read the Shors paper.

[https://eprint.iacr.org/2017/560](https://eprint.iacr.org/2017/560)

Nobody is hiding anything in HPolyC either.

~~~
tialaramex
My concern wasn't with speculating that anybody _is_ hiding anything in HPolyC
but with the comparable amount of code amongst which naughty things _might_ be
hidden, today or in future, in Linux, or more likely, in something else.

Unfortunately HPolyC is _much_ bigger and more complicated. I'm sure it gets
Google's job done, but I think overall purging Speck because of people's weird
paranoia about the NSA was an unforced error and we'll regret it.

~~~
tptacek
HPolyC is "bigger" but is built out of cryptographic components you generally
already have to trust: the Poly1305 MAC and the XChaCha cipher. It's a
construction, not a new block cipher transform. So obviously it takes more
lines of code to run it. But it introduces fewer new primitives.

------
hexsprite
I love deleting unused code

~~~
anilakar
Deleting whole deprecated features is even better. Often it's an indication of
a modular architecture and proper upgrade path when an old, unused piece of
code has been superseded without breaking any major parts of the whole system.

------
danielhlockard
This is interesting... If speck isn't used I'm all for less poor crypto that
can be used in the kernel... Just like OpenSSL removing Export ciphers (thanks
FREAK attack)

