[noise] Revision 33 draft

[David Wong]

> if you implement these functions (with Strobe or anything else) then you will fully support all Noise features.

I don't think most ad-hoc implementations will fully support all Noise
features, for my own library I only support a subset of Noise (which I
believe was the point of Noise, spend most of the time designing,
spend minimal time implementing and get rid of most
configuration/options/agility).

When implementing my own, I ended up implementing that `MixKeyAndHash`
function and realized later on that it was just dead code, whereas the
rest of the code is for most of it relevant to the subset
implementation. I don't feel strongly about it though, it's not that
bad if people end up implementing one or two short dead functions (in
exchange to making the spec less complicated).

> I argued for that, but we should keep that discussion going if you're not convinced:
> https://moderncrypto.org/mail-archive/noise/2017/001252.html

Woops, for some reason I did not see that you'd replied there, will
try to answer shortly there :)

> #2) Noise_XX_25519_STROBEvX/Keccak1660

This makes less sense to me, Keccak1600 is to Strobe what SHA256 is to
AESGCM (in some way) so I think it should respect the same convention.

> In your proposal (#1) it's not possible to generically parse the symmetric name, you'd have to recognize that "STROBEvX" is not a cipher and trigger different parsing for following components

Do you ever need to parse this anyway? This gets hashed and is
verified in the subsequent authenticated message to make sure the two
peers speak the same protocol. Is there more to protocol naming?

> Added a sentence, does this cover it?

Looks good to me!

> If no-one objects I'll merge this into rev33 branch in a couple days

I haven't verified that it makes sense throughout the whole spec, but
I agree with the intention!

David