[noise] Protocol Names

[Rhys Weatherley]

On Sat, May 27, 2017 at 4:06 AM, Trevor Perrin <trevp at trevp.net> wrote:

> Anyways, a few ideas:
>
> (A) Require (or recommend) that commutative modifiers appear in
> alphabetical order.
>
> (B) Normalize the pattern name into alphabetical modifiers prior to
> hashing, so that differently-named patterns are still compatible.
>
> (C) Don't do anything - differently named patterns are simply
> incompatible, even if the patterns are identical.
>
>
> I think (B) is the least attractive, since it complicates things to
> have libraries applying a normalization algorithm, and the library
> would have to know which modifiers commute.
>
> I guess I'd lean towards (A) as a recommendation, or (C)?
>

(A) gets my vote.  It is the simplest to explain.  With the recommendation
that extensions that define a modifier explicitly call out where
non-commutative / non-alphabetic behaviour is expected.

I believe Alex has touched on this, but with the proliferation of
modifiers, it is becoming difficult to name all variations;
XXfallback+hfs+noidh+psk1 anyone?

Noise-C used numeric identifiers for algorithms and patterns, with a
handshake created by either an id set or a protocol name.  The full set of
pattern variations was hard-wired into the library.  But that isn't going
to work with arbitrary modifier lists.  I think I'll have to remove the
id-based API's and go completely string-based for pattern names.

What this means is that it is very important that modifiers be defined in a
manner that is algorithmic; that is, a library can take a base pattern like
XX and apply transformations at runtime in a deterministic fashion.  Some
previous modifiers like noidh were a little iffy as to how the
transformation was applied token by token and message by message.

The Python script library that I contributed a while ago might help here:
modifier definitions can be tested with the "Can I write a script for
that?" test.



> (1) It's unclear how all this interacts with "hfs" naming, where we
> were thinking of using a plus to separate pairs of algorithms, but
> these aren't really modifiers, e.g.
>
> Noise_XXhfs_25519+448_AESGCM_SHA256
>
> https://github.com/noiseprotocol/noise_spec/blob/
> master/extensions/ext_hybrid_forward_secrecy.md
>
> (2) It's not clear that it makes sense to apply modifiers to DH,
> ciphers, and hash functions.  Though as a though experiment, we could
> imagine things like:
>  * 25519strict, 25519decaf (stricter parsing; different encoding)
>  * SHA512nohkdf (but note that not all cipher/hash names end in uppercase)
>

Continuing the thought experiment, I see 25519strict, etc as algorithm
names rather than algorithm modifiers because they entail modifications to
how the underlying operation works and are generally specific to that
operation.

The "nohkdf" modifier doesn't seem right - wouldn't "BLAKE2bkeyed" be a
better name for using keyed-BLAKE2 than saying "anything but HKDF"?  Since
SHA256/SHA512 don't have "keyed" variants (other than HKDF itself), it
isn't a modifier that applies equally to any hash.  Even for algorithms
that do have "keyed" variants for KDF's/XOF's, the structure is different
for each hash; e.g. BLAKE2X and SHAKE256.  A completely new algorithm name
fits better.

Another DH modifier example might be "25519x509" where the public key value
for "s" tokens is encoded in a full X.509 certificate instead of being sent
as a bare public key.  Such a modifier applies equally to all algorithms,
without changing how the algorithms themselves operate.

The question would be - is x509 really an algorithm modifier or a pattern
modifier?  Does XXpsk0_25519x509 make more sense than XXpsk0+x509_25519?  I
would argue that x509 is modifying how the "s" token works ("replace s with
sx509") without affecting "e", so it is a pattern modifier.

Long story short, I can't think of an algorithm modifier that isn't itself
a completely new algorithm deserving of a new base name.

Cheers,

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