[noise] Noise-C request for volunteers

[Trevor Perrin]

On Thu, Nov 16, 2017 at 12:06 AM, Rhys Weatherley
<rhys.weatherley at gmail.com> wrote:
> Hi all,
>
> Some of you may have noticed that I've been very quiet of late on Noise-C.
> This is due to my personal life, day job, and other open source projects
> intruding on my Noise hacking time.  This is likely to continue for a while.

No worries, thanks for head's up!


> When I was last working on it, I was in the middle of the changes for rev32
> with PSK and fallback support the main outstanding issues in the core
> library, followed by changing all the tests and examples to match the new
> API.

I hope someone can lend a hand:  It's probably not much work to update
Noise-C (and probably the same work for Noise-Java?):

Noise-C already has XXfallback, so I think it just needs rekey, and
the PSK patterns, to match the spec and other implementations.

---

Changing topics: I'll try to create a spec for "hybrid forward
secrecy" soon, and will ping you to see how much involvement you want.

There's an unsolved question how to provide a hash / XOF if the
public-key/KEM algorithm needs one.  But I think we'd reached a good
understanding of how to handle the pattern side of things, and I'd
like to get that documented.


> Sort of related, I've been doing some research and implementation testing on
> light-weight ciphers for IoT environments as part of my Arduino crypto
> library with an eventual goal of supporting Noise on extremely CPU and
> memory-constrained devices.  In particular I've been looking into the Speck
> and SKINNY block ciphers.  I will post my findings in a few days after
> collecting some statistics.

Interesting,  I think these are mostly designed for low security and
small data volumes, but looks like they do have 256-bit key and
128-bit block variants.

Once you've chosen these variants to be comparable to our existing
symmetric crypto - and added authentication/MAC to create an "AEAD" -
I wonder how performance compares to our existing crypto?

Also - if code size / area is a concern, does something like STROBE /
Disco start to become the better strategy, to eliminate the separate
hash function?

(These are also young algorithms, which is a reason to be cautious).


Trevor