[noise] Susurrus: Noise implementation in Rust

[Tiffany Bennett]

On Wed, Jul 8, 2015 at 10:33 PM, Trevor Perrin <trevp at trevp.net> wrote:
> I think you're using SHA2-512, instead of SHA2-256?

I think it was used in an old version of the spec and I forgot to
change it, I'll definitely do that.

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

I hadn't though about versioning, which is important to
consider. Perhaps noise should tend towards being
application-agnostic, to allow the use of generic debugging tools
(similar to `openssl s_client`)?

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

Ah. I wasn't sure about how the endianness worked out, and I suppose I
assumed that the zero bits were the high bits rather than the low
bits, but the spec is clear enough.

> 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?

I see.