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)
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.
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.
> 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.
Even if it comes from the NSA it doesn't necessarily mean it's backdoored. Speck is a good algorithm for performance constrained devices. It was removed from the kernel since it couldn't be included into Android systems due to political reasons, and the authors of the module wrote an implementation of an alternative algorithm for this use-case.
> Even if it comes from the NSA it doesn't necessarily mean it's backdoored
I suppose you could say the same thing about someone with a history of robbing banks.. just because they walked into your bank doesn't mean they are about to rob it (but it's highly likely they are).
If someone with a history of robbing banks arrived at my bank with a ski mask and a bulging duffle bag, I would say "go away, bank robber". The analogy to cryptography would be the NSA proposing yet another PKRNG, of any kind.
On the other hand, if someone with a history of robbing banks called me on the phone and asked me what the interest rates on my checking accounts were, I would tell them, because they can't rob my bank over the phone. The analogy here would be to the NSA suggesting a streamlined, simplified ARX block cipher transform, a backdoor in which would imply some fundamentally unknown property of block ciphers that would presumably jeopardize a whole variety of other academic ciphers, and would not accomplish the NOBUS property that NSA requires of backdoors in things they encourage USG assets to use themselves.
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.
Yeah, 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?
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.
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.
I have read the paper for speck. The actaully cipher is very unlikely to have been back doored. The only isue I have is the mode of operation with 64 bit blocks and short keys. In my opinion just ignore the 64bit variants and keys less than 96 bits in lenth. The cipher is rather simple so hiding a back door would require a method of attack not known to anyone publicly. Theres just too small of a surface, and uses pretty stanard operations.
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.
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.
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
No, as explained in the RFC (linked in the article) they're trying to get disk encryption on low-end devices that aren't capable of supporting AES. It's not an argument that AES is in any way incorrect.
I suppose it could be an elaborate scheme to add a backdoor, although presumably it will see significant review and anyway that hardly seems necessary given that the current alternative on those devices is no encryption at all.
25 comments
[ 3.9 ms ] story [ 71.4 ms ] threadI 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.
I suppose you could say the same thing about someone with a history of robbing banks.. just because they walked into your bank doesn't mean they are about to rob it (but it's highly likely they are).
On the other hand, if someone with a history of robbing banks called me on the phone and asked me what the interest rates on my checking accounts were, I would tell them, because they can't rob my bank over the phone. The analogy here would be to the NSA suggesting a streamlined, simplified ARX block cipher transform, a backdoor in which would imply some fundamentally unknown property of block ciphers that would presumably jeopardize a whole variety of other academic ciphers, and would not accomplish the NOBUS property that NSA requires of backdoors in things they encourage USG assets to use themselves.
https://en.wikipedia.org/wiki/Data_Encryption_Standard
https://en.wikipedia.org/wiki/SHA-1
https://en.wikipedia.org/wiki/Skipjack_(cipher)
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?
https://eprint.iacr.org/2017/560
Nobody is hiding anything in HPolyC either.
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.
This may be a silly comment but I'm glad you made it. It inspired more interesting and informative response than TFA and all the rest of this page.
http://lkml.iu.edu/hypermail/linux/kernel/1808.0/05226.html
Honestly, I generally trust both of them. But, technology politics are very confusing.
Google on the other hand has been doing a very nice job
I suppose it could be an elaborate scheme to add a backdoor, although presumably it will see significant review and anyway that hardly seems necessary given that the current alternative on those devices is no encryption at all.