[noise] Susurrus: Noise implementation in Rust

[Tiffany Bennett]

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.

Thoughts so far:

+ 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, and if one
  actually does need a variable-length prologue then the length field
  can just be added back in.

+ 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.

+ There appear to be certain messages where the prologue is
  unauthenticated, at least until later in the handshake. In
  particular, the first message of the following handshakes appears to
  not be authenticated until the second message from the client (via
  updating h): NN, NX, KN, KX, XN, XX, IN, and IX. This seems like it
  limits the utility of the prologue as a way of negotiating protocol
  details. If an implementation assumes the prologue will be
  authenticated within each message, they could end up creating
  protocols vulnerable to downgrade attacks, or other similar attacks
  on the handshake.

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

I do like the protocol as it is now, I am planning on using it
unmodified for my projects. In order to handle UDP I believe I will
have to put a message type and nonce in the prologue, because of the
unreliable out of order delivery.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: susurrus-anouncement.md.sig
Type: application/pgp-signature
Size: 543 bytes
Desc: not available
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20150708/09465595/attachment.sig>