The NSA developed some light-weight algorithms that were submitted to the ISO, but they were initially rejected due to lingering suspicions:<p>* <a href="https://techmonitor.ai/techonology/cybersecurity/nsa-ciphers-iso" rel="nofollow">https://techmonitor.ai/techonology/cybersecurity/nsa-ciphers...</a><p>* <a href="https://en.wikipedia.org/wiki/Simon_(cipher)" rel="nofollow">https://en.wikipedia.org/wiki/Simon_(cipher)</a><p>* <a href="https://en.wikipedia.org/wiki/Speck_(cipher)" rel="nofollow">https://en.wikipedia.org/wiki/Speck_(cipher)</a><p>The ISO went with PRESENT and CLEFIA for ISO/IEC 29192 ("Information technology - Security techniques - Lightweight cryptography"):<p>* <a href="https://en.wikipedia.org/wiki/PRESENT" rel="nofollow">https://en.wikipedia.org/wiki/PRESENT</a><p>* <a href="https://en.wikipedia.org/wiki/CLEFIA" rel="nofollow">https://en.wikipedia.org/wiki/CLEFIA</a><p>A bit of a history of that episode:<p>* <a href="https://link.springer.com/chapter/10.1007/978-3-030-10591-4_4" rel="nofollow">https://link.springer.com/chapter/10.1007/978-3-030-10591-4_...</a><p>S&S were eventually accepted for ISO 29167.
One really good thing with the finalist algorithms is that they all provide authenticated encryption. For many IoT systems, authentication and integrity protection is way more important than condidentiality.<p>Many older lightweight algorithms (or AES) for that matter requires adding either an authentication mode, or another primitive (a hash function used in HMAC for example)<p>I believe that has led to a problematic proliferation of only having confidentiality protection in too many IoT systems deployed.<p>These candidates makes it easier for developers to add the security properties their system actually needs.
Can someone point to a resource describing why various candidates got rejected in round 1 and round 2?<p>Any comments on the decisions or was it just voting without explaining?
One nice thing about lightweight crypto is that it's easy to port. Implementing ASCON in Go was pretty fun and only took an hour or two: <a href="https://github.com/lukechampine/ascon/blob/master/ascon.go" rel="nofollow">https://github.com/lukechampine/ascon/blob/master/ascon.go</a><p>(Obviously it wouldn't make a ton of sense to use Go if you're resource-constrained, but having a library is worthwhile for compatibility reasons regardless.)
Last time I checked, all the computers were growing powerful and crypto was relevant neither for latency nor for power consumption on any device capable of joining a network.<p>It helps that one of the largest factors on choosing crypto algorithms is speed on both general purpose and specialized hardware.<p>So, count me in the group of people that don't understand why the NIST is doing this. Will they trade any security guarantee for speed? If so, nobody should ever use one of those algorithms. If not, whatever algorithm wins here would also win a new round of general purpose crypto contest.