[noise] Protocol Names

[Trevor Perrin]

On Mon, May 29, 2017 at 4:14 PM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:>
> I'd recommend always sorting the modifiers alphabetically, and
> considering it to be an error / spec-violation to send no-alphabetized
> modifiers. The sole exception would be for non-commutative modifiers,
> which then go in their right place. The algorithm for doing this is
> pretty simple.


Cool, seems people like the convention of alphabetizing modifiers when
order doesn't matter (Jake, Rhys, Jason), and are OK with formalizing
an UPPERlower+lower+lower format for pattern names with modifiers.

Note that a pair of modifiers are "commutative" or not, this isn't a
property of individual modifiers.  So it may not be easy to document
and automatically enforce this.  But I think that's OK for a
convention.

So I would consider that the tentative plan, though we should flesh
out more modifiers (hybrid forward secrecy, more resumption,
formalizing "fallback", etc) and see how this works in practice.


> In the case of primitive modifiers, these aren't really parsable,
> anyway, since they correspond to exact implementations. At this point,
> I think it makes sense to consider modifiers of primitives to be
> particular for each primitive, rather than generic.

Syntax for DH/cipher/hash primitives is a stickier question.  I've
suggested "+" to separate different primitive names, in cases where
the pattern modifier requires multiple primitives ("hybrid forward
secrecy" being the primary use case).  As Jake points out, this means
"+" has a different meaning here than with patterns, and there's not
an obvious way to add primitive modifiers.

Rhys and Jason argued that primitive names are likely to be
unparseable at the Noise level, even where they follow a
modifier-based naming convention.

I think I agree that modifier-type names are common for crypto, but
are likely to be defined outside of Noise.  For example, all of these
names arguably use modifiers (mostly as suffixes, but sometimes
prefixes):

AES-256
AES-256-GCM
AES-GCM-SIV

Ed25519
Ed25519ctx
Ed25519ph

XEd25519
VXEd25519

BLAKE2b
BLAKE2bp
BLAKE2Xb132

SHA-512
SHA-512/256

Salsa20
Salsa20/12
XSalsa20

ChaCha20-Poly1305


It's probably true that Noise shouldn't be interpreting these names.  However:
 (1) We might come up with other reasons to add primitive modifiers in
the future, so our format should probably be extensible in case we
need that.
 (2) We should probably decide the allowable characters in a primitive
name, leaving us some reserved characters for future extension.

Tentatively, I'll propose requiring primitive names to use
alphanumeric characters (not special characters).  I think this makes
names more readable, but it might have some awkwardness, e.g. NIST's
"SHA3-256" would appear be kind of a jumble of numbers:

Noise_XX_25519_AESGCM_SHA3256

The alternative would be to restrict Noise's use of special characters
so the primitive names could use them, like:

Noise_XX_25519_AESGCM_SHA3-256

But I think that makes the top-level divisions harder to read.  Thoughts?

Trevor