[noise] Revision 33 draft

[Piotr Lizończyk]

I have no deep knowledge of Strobe, but what if we replaced the initial
“Noise_” with any other arbitrary string (may it be StrobevX or whichever)?
This would be a clear sign that the following protocol name might need to
be parsed following different rules than classic Noise Protocol.
Example:
STROBEvX_XX_25519_Keccak1660

Kind regards,
Piotr
W dniu niedz., 24.09.2017 o 22:11 Trevor Perrin <trevp at trevp.net>
napisał(a):

> 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
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20170924/aee74478/attachment.html>