[noise] Pattern notation

Trevor Perrin trevp at trevp.net
Fri Sep 23 15:12:33 PDT 2016


We've been considering Rhys's proposal for hybrid forward secrecy:

https://github.com/rweather/noise_spec/blob/forward_secrecy/extensions/ext_hybrid_forward_secrecy.md

This would add tokens to the pattern language:
 * "f" - send a public key value
 * "dhff" - MixKey() on the secret key output

So we could transform a pattern like XX to add hybrid forward secrecy ("hfs"):

Noise_XX(s, rs):
  -> e
  <- e, dhee, s, dhse
  -> s, dhse

Noise_XXhfs(s, rs):
  -> e, f
  <- e, f, dhee, dhff, s, dhse
  -> s, dhse

Some downsides to this notation:
 - Unlike DH, schemes like NewHope, SIDH, or NTRU are not symmetric,
i.e. the the two uses of "f" above represent different types of
values, with different sizes.
 - Schemes like NewHope and NTRU are not really Diffie-Hellman, so
it's abusing terminology to use "dh" for them.

As an alternative, consider:
 * "f" - send the first public value
 * "g" - send the second public value
 * "fg" - MixKey() on the secret key output

That fixes above problems, but introduces new ones:
 * "fg" and "dhxx" no longer look the same, so it becomes harder to
read the pattern and immediately see which tokens send values, and
which are MixKey() steps.
 * "dhxy" means sender's x and recipient's y, so to be more consistent
we'd need to use "gf" in cases like XXfhs (above).

We could potentially fix these problems by changing the existing notation:
 * remove the "dh", and just use "ss", "se", "es", "ee" for the DH operations
 * change the convention so that the first character in "xy" refers to
the initiator, not the message sender.  This means the token's role in
the overall protocol is not context-dependent, which a number of
people have complained makes the patterns hard to read.  So we'd have:

Noise_XX(s, rs):
  -> e
  <- e, ee, s, es
  -> s, se

Noise_XXhfs(s, rs):
  -> e, f
  <- e, g, ee, fg, s, es
  -> s, se


So we'd have a clear distinction between single-char tokens (send a
value) and double-char tokens (mix two values into the KDF), and the
token names don't care whether the "mixing" is DH, or a KEM, or
One-Pass Key Exchange, or whatever.

Thoughts?


Trevor


More information about the Noise mailing list