5 ms·

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 constrain

by yk 8y ago

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.

arghwhat 8y ago
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.
- the8472 8y ago
  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.
  - arghwhat 8y ago
    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.
    - ciphergoth 8y ago
      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.
- tptacek 8y ago
  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 https://gimli.cr.yp.to/gimli-20170627.pdf
- ciphergoth 8y ago
  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.
  - arghwhat 8y ago
    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.
beefhash 8y ago
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.
tonyarkles 8y ago
> 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.

by yk 8y ago

arghwhat 8y ago

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.

the8472 8y ago
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.
- arghwhat 8y ago
  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.
  - ciphergoth 8y ago
    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.
tptacek 8y ago
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 https://gimli.cr.yp.to/gimli-20170627.pdf
ciphergoth 8y ago
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.
- arghwhat 8y ago
  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.

beefhash 8y ago

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.

tonyarkles 8y ago

> 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.