[noise] Extensions for forward secrecy and New Hope

[Rhys Weatherley]

On Sun, Aug 28, 2016 at 9:58 AM, Brian Smith <brian at briansmith.org> wrote:

> Rhys Weatherley <rhys.weatherley at gmail.com> wrote:
> > Additional forward secrecy:
> >
> > https://github.com/rweather/noise_spec/blob/forward_
> secrecy/extensions/ext_forward_secrecy.md
>
> Currently protocol names are valid Rust (and other language)
> identifiers, which may be useful for some implementation(s). Adding
> "+" to the naming would mean that we can't use protocol names as
> identifier names in programs. It would be nice to find another scheme
> that avoids this issue. Perhaps instead of "25519+448" one could do
> something like "25519_fs448".
>

I was following Trevor's suggestion with "A+B", but anything is possible ...

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.


> Another problem with the suggested naming scheme is that it might get
> confusing if/when signature-based schemes are added. 25519+25519 Could
> be X25519+Ed25519 or X25519+X25519, I guess.
>

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.

Extra fields at the end for extension features?  Super paranoiacs use
"Noise_XX_448_ChaChaPoly_BLAKE2b_fsNewHope_kexSIDHp751_signEd25519" .
Although that may be overkill. :-)

Cheers,

Rhys.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20160828/88626849/attachment.html>