[noise] Susurrus: Noise implementation in Rust

[Trevor Perrin]

On Wed, Jul 8, 2015 at 7:33 AM, Tiffany Bennett <tiffany at stormbit.net> wrote:
> I've been developing a noise implementation in Rust called Susurrus,
> which I've now put on Github at https://github.com/tiffany352/susurrus
>
> I've tried to stick to the spec, but it's kind of hard without test
> vectors. Currently, I only support boxes, because I haven't written
> the code to deal with stateful sessions. The code models descriptors
> explicitly, instead of hard-coding them, so all the handshakes should
> be eventually expressible.
>
> There is currently 429 lines of code, not counting dependencies. It
> depends on libsodium for cryptographic primitives.

Nice!  I'll look at this more later, I'm glad you could do such a
compact implementation.

Quick thoughts:

I think you're using SHA2-512, instead of SHA2-256?


> + The prologue is interesting because of being so generic, but at the
>   same time the length field is a little bit redundant for specific
>   protocols. Are you trying to create a protocol like TLS which is
>   inter-operable between implementations, or are you trying to create
>   a protocol which is adapted to the needs of the user? It feels like
>   noise is somewhere in between right now. Omitting the length from
>   the prologue and just letting the application sort it out would be a
>   good solution for application-specific adaptation,

Maybe.  What I liked about the prologue is you could use a vanilla
Noise implementation without thinking about versioning or
extensibility.  Then if you discover you need it later you just
increase the length of prologue data and old implementations will
acknowledge that they've seen the fields so you can distinguish newer
implementations from rollback attacks.

But I agree the line between application and Noise responsibilities
here is fuzzy, we may need better guidance on the prologue or a
rethinking of it.


> + The use of the RFC variant of ChaCha is a bit annoying right now,
>   because I am currently using bindings of libsodium, which do not
>   support this. I'm sure the situation will improve eventually. Right
>   now, I'm just using the original ChaCha.

I think Noise's use of ChaCha20 should map nicely into the older or
newer version.  The older version initializes the last 128 bits of
state as (64-bit little-endian block count, 64-bit nonce).  The newer
as (32-bit little-endian block count, 96-bit nonce).

http://lists.lysator.liu.se/pipermail/nettle-bugs/2014/003031.html

Noise specifies the first 32 bits of the nonce as zero, so for the old
version, you should just set the 64 bits of the nonce, and as long as
you encrypt < 2^32 blocks the block counter will never spill into the
next 32 bits.


> + Allowing clear-text payloads is similarly strange. I'm not sure
>   what kind of use-case there is for them.

The thought was that you could add a payload in cases where k wasn't
initialized yet, e.g. in the first message of:

HandshakeXX:
  -> e
  <- e, dhee, s, dhse
  -> s, dhse

The payload might have some negotiation data or something.  I suppose
you could disallow that and just require such data in the prologue,
but it seemed easy and not harming anything to allow clear payloads?


Trevor