[noise] Lightweight ciphers and Noise

[Rhys Weatherley]

On Wed, Nov 22, 2017 at 2:49 PM, Trevor Perrin <trevp at trevp.net> wrote:

> The Uno case seems like a slow Poly1305 implementation, though?  You
> have Poly1305 at ~175% of the speed of ChaCha20, but [1] shows it at
> ~75% of Salsa20 (similar to ChaCha20).  If your numbers were more like
> [1], I think ChaChaPoly would be neck-and neck with EAX<Speck> on the
> Uno.
>

I tend to stick to plain C implementations unless the performance is
completely atrocious - and only then do I do AVR assembly versions.  Plain
C is easier to audit and quicker to get going on a new platform.  But yes,
if I pulled out all the stops I'm sure I could make Poly1305 faster.  I'll
put it on the list.

> We may want to have a separate discussion as to when it is acceptable to
> use
> > 64-bit block ciphers with Noise.  A lot of the research in lightweight
> > crypto is focused on that size block.  Since data volumes on small
> devices
> > isn't high, maybe 64-bit would be OK?
>
> The Noise spec currently has a discussion about the (small) security
> concern with large data volumes and 128-bit block ciphers like AES.
> So I'd prefer if things went the other direction (towards PRFs like
> ChaCha with *less* risk than 128-bit PRPs; rather than towards more
> risk and tighter limits).
>

Fair enough.  Given that Speck is so fast, it should be possible for
someone to design a 256-bit or 512-bit block cipher using the same idea,
but I don't have the necessary math skills to try so I won't.  Speck got
some of its ideas from Threefish.  I vaguely recall someone on the
cryptography mailing list (Dan Bernstein maybe?) talking about Speck
variants with larger block sizes a year or so ago.  Maybe someone has a
link?  I haven't yet implemented Threefish-256 on Arduino but maybe I
should give it a try.

My takeaway is that ChaChaPoly/BLAKE2s looks pretty good on these
> devices.  The speedup from faster options seems like it comes mostly
> just from cutting down the security level, which is probably not
> advisable for a general-purpose crypto protocol like Noise.
>

That's my take at the moment too, but still looking around for other ideas.

Cheers,

Rhys.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20171122/5c985fe2/attachment.html>