3 ms·
This email outlines some potential issues with Speck: https://www.spinics.net/lists/linux-crypto/msg33291.html https://www.spinics.net/lists/linux-crypto/msg332
by dagenix 8y ago
This email outlines some potential issues with Speck: https://www.spinics.net/lists/linux-crypto/msg33291.html https://www.spinics.net/lists/linux-crypto/msg33291.html
And that was discussed here: https://news.ycombinator.com/item?id=17214827 https://news.ycombinator.com/item?id=17214827
I really can't judge the quality of that critique of Speck, but, its a lot more interesting than just "NSA = bad".
- tptacek 8y agoA comment on the thread from the code's contributor is super useful: SPECK was added because on low-end Android devices with less than 50MB/s AES, it enables phones to have encryption enabled by default. That is, SPECK is useful in cases where the alternative would be no encryption at all. I'd be a little surprised if SPECK was the only workable answer here. Later: It isn't; Google is doing HPolyC instead.
- ebiggers 8y agoYou can read about some of the other options considered here: https://marc.info/?l=linux-crypto-vger&m=152573520705012 https://marc.info/?l=linux-crypto-vger&m=152573520705012. But in the end, a new ChaCha-based mode suitable for disk encryption (https://eprint.iacr.org/2018/720.pdf https://eprint.iacr.org/2018/720.pdf) had to be designed since there didn't seem to be any alternative block cipher that met the strict performance and security requirements. LEA-128 maybe comes close, but it hasn't undergone too much cryptanalysis yet (much less than Speck).