<div dir="ltr"><div>Hi all!</div><div><br></div><div>Over the last few months I've been working on optimized 32-bit implementations [1] of the 2nd round submissions to the NIST Lightweight Cryptography Competition [2].</div><div><br></div><div>A few years from now one of the LWC candidates will be standardised by NIST.  I thought I'd give an update as to what looks promising for future use in Noise.<br></div><div><br></div><div>A lot of the submissions use 128-bit keys where Noise requires at least 256-bit keys with a 128-bit tag.  The following submissions support 256-bit keys:</div><div><br></div><div>Gimli, 256-bit key, 128-bit nonce, 128-bit tag - this is the spiritual successor to ChaChaPoly from the Bernstein group of cryptographers.  It has good software performance and is probably the easiest to drag-and-drop into Noise.  It is a sponge, based around the 384-bit Gimli-24 permutation.<br></div><div><br></div><div>Schwaemm256-256, 256-bit key, 256-bit nonce, and 256-bit tag.  The nonce size doesn't matter much to Noise as we already zero-pad the 64-bit sequence number for AES-GCM.  For the tag, I suppose it could be truncated to 128-bit to fit into Noise.  Schwaemm256-256 is a sponge, based around the SPARKLE permutation.<br></div><div><br></div><div>TinyJAMBU-256, 256-bit key, 96-bit nonce, and 64-bit tag.  TinyJAMBU is based around a non-linear feedback shift register (NFSR) and has a ... well ... tiny code size.  The description in the paper sounds insane: 1280 rounds and a sponge absorption rate of 32 bits per block!  But it gives Gimli a run for its money in the performance stakes.  I like it a lot and I hope it survives to the next round.  Shame about the tag size though.<br></div><div><br></div><div>SATURNIN-CTR-Cascade, 256-bit key, 128-bit nonce, and 256-bit tag.  Saturnin is a 256-bit block size version of AES with a bit-sliced implementation.  Operated in CTR-Cascade AEAD mode.  Middling performance.<br></div><div><br></div><div>DryGASCON-256, 256-bit key, 128-bit nonce, 256-bit tag.  Sponge based around a generalised version of ASCON.  The interesting feature of this one is that it has built-in protection against power analysis side channels which is a must have in some embedded applications.  Performance is similar to Saturnin - the side channel protection requires a lot of extra work per bit to hide the state.<br></div><div><br></div><div>KNOT-AEAD-256-512, 256-bit key, 256-bit nonce, 256-bit tag.  Sponge based around the KNOT permutation.  Performance of the 256-bit version of KNOT is ok-ish.<br></div><div><br></div><div>With the exception of TinyJAMBU, all of the above have digest hashing modes as well.</div><div><br></div><div>As mentioned before, there are plenty of 128-bit ciphers.  While most of the above are sponges, block ciphers show up a lot in the NIST submissions, usually based around GIFT-128 and SKINNY-128 which are power efficient in hardware but middling to implement in software.</div><div><br></div><div>Right now for Noise I would probably pick Gimli for regular work and DryGASCON for hardening against side channels.  But things may change as the competition advances.<br></div><div><br></div><div>Performance figures [3] and full algorithm summary [4] are on my github page.</div><div><br></div><div>Cheers,</div><div><br></div><div>Rhys.</div><div><br></div><div>[1] <a href="https://github.com/rweather/lightweight-crypto">https://github.com/rweather/lightweight-crypto</a></div><div>[2] <a href="https://csrc.nist.gov/projects/lightweight-cryptography/round-2-candidates">https://csrc.nist.gov/projects/lightweight-cryptography/round-2-candidates</a></div><div>[3] <a href="https://rweather.github.io/lightweight-crypto/performance.html">https://rweather.github.io/lightweight-crypto/performance.html</a></div><div>[4] <a href="https://rweather.github.io/lightweight-crypto/algorithms.html">https://rweather.github.io/lightweight-crypto/algorithms.html</a></div><div><br></div></div>