<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Aug 28, 2016 at 9:58 AM, Brian Smith <span dir="ltr"><<a href="mailto:brian@briansmith.org" target="_blank">brian@briansmith.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Rhys Weatherley <<a href="mailto:rhys.weatherley@gmail.com">rhys.weatherley@gmail.com</a>> wrote:<br>
> Additional forward secrecy:<br>
><br>
> <a href="https://github.com/rweather/noise_spec/blob/forward_secrecy/extensions/ext_forward_secrecy.md" rel="noreferrer" target="_blank">https://github.com/rweather/<wbr>noise_spec/blob/forward_<wbr>secrecy/extensions/ext_<wbr>forward_secrecy.md</a><br>
<br>
</span>Currently protocol names are valid Rust (and other language)<br>
identifiers, which may be useful for some implementation(s). Adding<br>
"+" to the naming would mean that we can't use protocol names as<br>
identifier names in programs. It would be nice to find another scheme<br>
that avoids this issue. Perhaps instead of "25519+448" one could do<br>
something like "25519_fs448".<br></blockquote><div><br></div><div>I was following Trevor's suggestion with "A+B", but anything is possible ...<br><br>The issue with "_" is that other implementations may wish to call String.split("_") to break the protocol name up into components.  Previously an implementation could assume that the order was prefix, pattern, key exchange, cipher, hash.  Key exchange could then be further split with "+".  Adding a "_" shifts everything after along one, making the parsing more complex.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Another problem with the suggested naming scheme is that it might get<br>
confusing if/when signature-based schemes are added. 25519+25519 Could<br>
be X25519+Ed25519 or X25519+X25519, I guess.<br></blockquote><div><br></div><div>Yes.  The extension document suggests "A*B" for situations where B also has static keys but is otherwise a regular DH key exchange mechanism.  For signature schemes like Ed25519 I think they warrant their own section in the protocol name because they don't work like key exchange.<br><br>Extra fields at the end for extension features?  Super paranoiacs use "Noise_XX_448_ChaChaPoly_BLAKE2b_fsNewHope_kexSIDHp751_signEd25519" .  Although that may be overkill. :-)<br><br></div><div>Cheers,<br><br></div><div>Rhys.<br><br></div></div></div></div>