[noise] Revision 33 draft

[Trevor Perrin]

On Sun, Sep 24, 2017 at 10:34 AM, David Wong <davidwong.crypto at gmail.com> wrote:
>> 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

I added a sentence to the MixKeyAndHash description to clarify that:

"This function is used for handling pre-shared symmetric keys, as
described in Section 9."
https://github.com/noiseprotocol/noise_spec/blob/rev33test/output/noise.pdf

Is that better?

I still think SymmetricState and CipherState descriptions should also
serve the audience of crypto algorithm designers, so it's useful to
completely describe the symmetric-crypto API that Noise relies on.


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

Not sure I follow the analogy, I think all those things are quite different.


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

Names might be used in other contexts, e.g.
 * Human communication and documentation
 * Some library APIs are configured by specifying a name string (e.g. Snow)
 * Some protocols might pass strings as part of negotiation
 * The test vectors use name strings to specify protocols

If you don't understand "STROBEvX" you're not going to get much value
out of the name in any case, but recognizing whether whether
"STROBEvX" is a cipher (or XOF or something else) would give a reader
or debugger at little more information.

Maybe it's not a big deal, but I'd prefer to keep the names parseable,
if all else was equal.

Trevor