[noise] Extension spec: Signatures

Justin Cormack justin at specialbusservice.com
Mon Dec 17 05:24:37 PST 2018


Hi, I was writing up the version I discussed before which is designed
to support pattern composition (that I also need to finish writing
up). The differences are as follows.

There are 11 basic signature patterns (all the basic patterns except
NN). As the deferral is implicit, I named them without the numbers,
although that is a matter of taste. These correspond to your patterns
with both es and se replaced:

NK1:
  <- s
  ...
  -> e
  <- e, ee, es

NKsig:
  <- s1
  ...
  -> e
  <- e, ee, sig1

NX:
  -> e
  <- e, ee, s, es

NXsig:
  -> e
  <- e, ee, s1, sig1

XN:
  -> e
  <- e, ee
  -> s, se

XNsig:
  -> e
  <- e, ee
  -> s1, sig1

K1N:
  -> s
  ...
  -> e
  <- e, ee
  -> se

KNsig:
  -> s1
  ...
  -> e
  <- e, ee
  -> sig1

XK1:
  <- s
  ...
  -> e
  <- e, ee, es
  -> s, se

XKsig:
  <- s1
  ...
  -> e
  <- e, ee, sig1
  -> s1, sig1

XX:
  -> e
  <- e, ee, s, es
  -> s, se

XXsig:
  -> e
  <- e, ee, s1, sig1
  -> s1, sig1

K1K1:
  -> s
  <- s
  ...
  -> e
  <- e, ee, es
  -> se

KKsig:
  -> s1
  <- s1
  ...
  -> e
  <- e, ee, sig1
  -> sig1

K1X:
  -> s
  ...
  -> e
  <- e, ee, s, es
  -> se

KXsig:
  -> s1
  ...
  -> e
  <- e, ee, s1, sig1
  -> sig1

I1N:
  -> e, s
  <- e, ee
  -> se

INsig:
  -> e, s1
  <- e, ee
  -> sig1

I1K1:
  <- s
  ...
  -> e, s
  <- e, ee, es
  -> se

IKsig:
  <- s1
  ...
  -> e, s1
  <- e, ee, sig1
  -> sig1

I1X:
  -> e, s
  <- e, ee, s, es
  -> se

IXsig:
  -> e, s1
  <- e, ee, s1, sig1
  -> sig1

I also used "+" in the pattern naming ie
Noise_IKsig_25519+Ed25519_AESGCM_SHA256 to make it clearer how to
parse the names, and I think this works best with the composition
rules although these need finalising. Using underscore the parsing is
more implicit. The

Your additional patterns are then combinations. The combination rules
are quite simple, for "i" patterns you use N.+.Nsig ie the sig
modifier is applied to something that only has initiator keys, and the
opposites.

XKsigi is
NK+XNsig:
  <- s
  ...
  -> e, es
  <- e, ee
  -> s1, sig1

X1K1sigr the obvious construction would be different though:
X1K1sigr:
  <- s1
  ...
  -> e
  <- e, ee, sig1
  -> s
  <- se

XN+NKsig:
  <- s1
  ...
  -> e
  <- e, ee, sig1
  -> s, se

This is XK1sigr in your notation, which you did not include although
it is valid, and which in composition terms is

X1N+NKsig:
  <- s1
  ...
  -> e
  <- e, ee, sig1
  -> s
  <- se

XXsigr is also valid, which is XN+NXsig, and XXsigi which is NX+XNsig
- you didn't need to use the deferred patterns for the XX ones as
XXsig is valid. K1K1sigi and K1K1sigr are also valid, and K1Xsigi and
K1Xsigr, and I1K1sigi and I1K1sigr. So overall there are I think 8
patterns that you miss that are valid, giving 31 patterns overall.
This is significantly more complex as a spec than my version with just
11 patterns plus composition rules to make up the other versions, so
long as you agree the composition rules are simple (and I think they
are otherwise useful). I will do a writeup of the composition rules
this week.

On Mon, 17 Dec 2018 at 10:17, Trevor Perrin <trevp at trevp.net> wrote:
>
> I started an extension spec for basic signatures:
>  * sig, sigi, and sigr modifiers
>  * s1, sig1 tokens (or other numbers, if used in combination with hfs
> or something else)
>
> https://github.com/noiseprotocol/noise_sig_spec/
> https://github.com/noiseprotocol/noise_sig_spec/blob/master/output/noise_sig.pdf
>
> This follows the hfs spec in using numbered suffixes to refer to
> different types of public-key algorithms that are introduced by the
> pattern modifiers:
>
> XXhfs+sig_25519+NewHope+Ed25519_AESGCM_SHA256:
>  -> e, e1
>  <- e, ekem1, s2, sig2
>  -> s2, sig2
>
>
> This spec lists 23 new patterns applying the sig modifiers to the
> fundamental+defered patterns.  These signatures modifiers don't
> coexist with any ss/noss modifiers, but should combine easily with the
> hfs modifier (as above).
>
>
> Anyways, this gives us 3 extension specs related to patterns:
>  * ss (adding and removing ss token)
>  * hfs (adding post-quantum KEMs for more forward-secrecy)
>  * sig (adding signatures for authentication)
>
> I think that's a good amount of handshake-pattern stuff to discuss at
> RWC and try to finalize in the next few months.
>
> (Aside from the pattern work, I'd like to make progress on the SHO
> idea, and after that on NoiseSocket/NoiseLingo/NLS).
>
> Trevor
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise


More information about the Noise mailing list