Hacker News Reader

Comment by yk | Hacker News Reader

Can someone point me to a concrete use case for speck? As far as I understand, Speck is designed to use less resources than AES. However, even on very constrained devices I believe one needs at worst hundreds of kB of RAM and even a low end micro controller should be able to deliver 1 kb/s encrypted bandwith. So I have a hard time to think of any application were a chip that is designed now does not have enough power to encrypt using AES, but has a need for somewhat high bandwidth communication.

View on HN

AES is extremely slow when implemented in software. Many mobile and embedded processors do not have AES hardware acceleration. With hardware acceleration, AES becomes crazy fast, but that's because hard silicon can do crazy things.

However, Speck does not have a user-case, as there are sensible options available. If you don't have AES hardware acceleration, ChaCha20 can get very close in software, which is one of the primary reasons ChaCha20Poly1305 is being adopted as a common TLS cipher suite. Cloudflare has some nice benchmarks on it.

The linked mail talks about XTS constructions, so the thread is about block encryption commonly used in disk encryption schemes. They also mention that they'd have to handroll such a scheme with ChaCha. I assume that Speck offers a native wide block mode which would make a better candidate for software disk encryption if it weren't for the backdoor concerns.

That is fair, but that is by no means an argument for Speck, but instead just an argument for a block mode cipher.

What they would need to do would be to find a different sensible block mode cipher, rolling a cipher-text stealing operation mode like XTS for a stream cipher (which is not that complicated, although one should do their homework first), or using a construct to convert a stream cipher to a block mode cipher so it can use XTS directly (which is possible, but care must be taken).

#2 would probably be best. I am not sure if it a trend, but I seem to mostly see new stream ciphers popping up, so this solution is likely more sensible.

We have a stream cipher based proposal, but it's a much bigger change and needs much more review, so it can't be landed for P. A drop-in replacement for AES is a much simpler change to make.

ChaCha20 gets very close in software on machines that have fast 32-bit ARX and can handle ChaCha20's key size. Part of the point of lightweight ciphers is to provide "as secure as possible" variants with smaller keys and tiny block sizes, workable on 8- and 16- bit embedded processors.

Speck is far from the only lightweight cipher design, and the other designs don't get this kind of shade from academic cryptographers. In fact, Bernstein designed one, based on the ChaCha20 design: Gimli.

https://gimli.cr.yp.to/gimli-20170627.pdf

It's worth bearing in mind that it's poorer people and people in poorer countries who don't have AES-supporting hardware, and are currently without encryption as a result.

Note that this is only true for smartphones, and it the gap is likely fading.

However, even with AES-supporting hardware arriving in cheap crap android phones, there's too little focus on performance on cheap crap phones and terrible network coverage that is the reality in by far the majority of the world.

This is a super niche use case, but maybe this:

For DRM, you may be interested in using a cipher that is both easy to implement (though the spec makes this surprisingly confusing because they can't keep their orders of stuff straight), relatively fast (because you might be running it through a VM) and has no known constants that could be used to identify it quickly.

> hundreds of kB of RAM

You're not looking low enough! (and I don't think the author is either). There are tons of super low power devices going into service with 1kB of RAM or less. Think of remote sensing, where 5-10 years of battery life is common.

Reply on news.ycombinator.com