<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, May 27, 2017 at 4:06 AM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Anyways, a few ideas:<br>
<br>
(A) Require (or recommend) that commutative modifiers appear in<br>
alphabetical order.<br>
<br>
(B) Normalize the pattern name into alphabetical modifiers prior to<br>
hashing, so that differently-named patterns are still compatible.<br>
<br>
(C) Don't do anything - differently named patterns are simply<br>
incompatible, even if the patterns are identical.<br>
<br>
<br>
I think (B) is the least attractive, since it complicates things to<br>
have libraries applying a normalization algorithm, and the library<br>
would have to know which modifiers commute.<br>
<br>
I guess I'd lean towards (A) as a recommendation, or (C)?<br></blockquote><div><br></div><div>(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.<br><br></div><div>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?<br><br>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.<br><br></div><div>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.<br><br></div><div>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.<br></div><div><br></div><div></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(1) It's unclear how all this interacts with "hfs" naming, where we<br>
were thinking of using a plus to separate pairs of algorithms, but<br>
these aren't really modifiers, e.g.<br>
<br>
Noise_XXhfs_25519+448_AESGCM_<wbr>SHA256<br>
<br>
<a href="https://github.com/noiseprotocol/noise_spec/blob/master/extensions/ext_hybrid_forward_secrecy.md" rel="noreferrer" target="_blank">https://github.com/<wbr>noiseprotocol/noise_spec/blob/<wbr>master/extensions/ext_hybrid_<wbr>forward_secrecy.md</a><br>
<br>
(2) It's not clear that it makes sense to apply modifiers to DH,<br>
ciphers, and hash functions.  Though as a though experiment, we could<br>
imagine things like:<br>
 * 25519strict, 25519decaf (stricter parsing; different encoding)<br>
 * SHA512nohkdf (but note that not all cipher/hash names end in uppercase)<br></blockquote><div><br></div><div>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.<br><br>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.<br><br>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.<br><br></div><div>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.<br><br></div><div>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.<br><br></div><div>Cheers,<br><br></div><div>Rhys.<br><br></div></div></div></div>