Reconsidering Speck

It's also worth pointing out that the key schedule is baked into the above code. Performant implementations can break out the key schedule and save some work on long streams. But what makes Speck so enticing is precisely how simple it is. It could be the new RC4. But therein lies the dilemma.

RC4 was so successful because it was so simple, easy to implement, and susceptible to copy+paste imports. Without RC4 cryptography on the internet may have been delayed even further; not just because of opaqueness of cryptographic engineering but because of the difficulty software management in general. The engineering benefit of this *should* *not* be underestimated. Not only does it make it easy to wield strong cryptography in novel ways (think SipHash), but there's less chance for getting it wrong. People have screwed up key mixing into bespoke ChaCha CSPRNGs. That would be more difficult to do with Spec because the obvious way to turn it into a CSPRNG doesn't involve tweaking the internals, particularly if you stick to the above code which doesn't break out the key schedule.

OTOH, RC4 ultimately proved too simple. And I think that's the fear with Speck. It's not the parameters, per se, that bother people. The only real parameter is the number of rounds, which qualitatively isn't the type of parameter that traditionally invites suspicion. What concerns people is whether the state-of-the-art in the community is sufficient that people can reasonably rely on the absence of evidence that its too weak as evidence of absence for the duration of its lifetime. DJB has stated in some papers that he thinks the community relies too heavily on proofs of security--they're not always properly verified, and people overlook explicit or implicit premises that leave room for future attacks. Which is another way of saying that he thinks there are still too many unknowns, that there's still an art to cryptography, and some amount of unquantifiable complexity is prudent.

Similarly, there's an argument that Speck is so simple and so enticing that it might displace future, stronger alternatives.

Those are really what the criticisms boil down to. They're reasonable perspectives but they're difficult arguments to make, and of course easy to conflate with NSA animus, which I think is what has actually happened.

I'm not a cryptographer but I've written lots of software that use cryptographic primitives. And I'm familiar with the limitations of existing libraries, including pre-packaged stacks like NaCL. From my perspective Speck is hugely enticing. Not to replace traditional primitives, but to augment the ecosystem. Two simple examples off the top of my head:

1) A simpler portable arc4random. Have you seen the "portable" ChaCha-based arc4random files floating around!? It's not the kind of code you'd ever want to touch, yet compiling it as its own unit file brings integration headaches, especially in libraries and modules, because of visibility issues. (Building cross-platform C code is really easy these days if you keep things simple, *except* when managing symbol visibility beyond the standard C extern or static scopes.)

2) Permutation generators. I once used XTEA to write a 16-bit Feistel cipher for a DNS QID permutation generator that used only a few bytes of state per context, rather than the typical solution of using a Fisher–Yates shuffle on a 128KB array (or keeping a cached of used QIDs), which isn't user friendly if you're trying to avoid dynamic memory, sharing data structures, or introducing non-obvious edge cases. It didn't matter that XTEA wasn't a particularly strong cryptographic cipher; it was strong enough to generate 16-bit QIDs such that it was no easier to break than a system shuffling an array with a provably secure CSPRNG.