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 <div class="gmail_quote"><div dir="ltr">W dniu niedz., 24.09.2017 o 22:11 Trevor Perrin <<a href="mailto:trevp@trevp.net">trevp@trevp.net</a>> napisał(a): </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, Sep 24, 2017 at 10:34 AM, David Wong <<a href="mailto:davidwong.crypto@gmail.com" target="_blank">davidwong.crypto@gmail.com</a>> 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." <a href="https://github.com/noiseprotocol/noise_spec/blob/rev33test/output/noise.pdf" rel="noreferrer" target="_blank">https://github.com/noiseprotocol/noise_spec/blob/rev33test/output/noise.pdf</a> 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 <a href="mailto:Noise@moderncrypto.org" target="_blank">Noise@moderncrypto.org</a> <a href="https://moderncrypto.org/mailman/listinfo/noise" rel="noreferrer" target="_blank">https://moderncrypto.org/mailman/listinfo/noise</a> </blockquote></div>