[noise] Extension spec: Signatures

[Justin Cormack]

On Tue, 18 Dec 2018 at 06:46, Trevor Perrin <trevp at trevp.net> wrote:
>
> On Mon, Dec 17, 2018 at 1:24 PM Justin Cormack
> <justin at specialbusservice.com> wrote:
> >
> > 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:
>
> OK cool, I made a revision 2 where "sigi" and "sigr" modifiers are
> removed, so my spec only contains these 11 patterns where all
> authentication DHs can be replaced with signatures.
>
> https://github.com/noiseprotocol/noise_sig_spec/blob/master/output/noise_sig.pdf
>
> I think that's simple and useful functionality we could hopefully
> agree on while we continue to work out more complicated cases.

Definitely.

> I did name these with the deferred "1" numbers, so that the "sig"
> modifier has to do less work.  I think you have a more "generative"
> viewpoint, but I like to be able to read simple "transformations" from
> one pattern to another.

Yes I wasn't sure about the simplification, no harm in being more explicit.

>
> > 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
>
> I didn't understand this paragraph, it got cut off?

Lets leave this now, I think it makes sense with the other combination rules
but lets review these first. It just groups the DH and DH like algorithms; in
some future case where there is a pair of hash functions say it may be clearer.

>
> > 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
>
> For the cases with mixed DH and signature authentication, I would
> definitely like to see your "pattern composition" approach fleshed
> out.  Some questions I have about it:
>
>  * It's not obviously more readable, i.e. looking at above example:
> XKsigi can be read and applied quite easily:  just take XK and replace
> the initiator auth with a signature.  Viewing this as NK+XNsig takes
> more thinking to "merge" 2 different patterns.

Not obviously more readable, but I think the benefits of being more general
and working for other combinations but lets see. I am interested in patterns
like KK+XXsig for example.

>  * If "pattern composition" automatically merges ephemeral, how would
> we handle cases where we want to add or replace ephemerals, e.g.
> hybrid forward secrecy?  If we're tackling a general composition
> mechanism it probably needs to be able to combine DH, signatures, and
> ephemeral or static KEMs, arbitrarily.

Yes, I will need to make these cases clear.

> > 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.
>
> I only included sigi/sigr if sig wasn't possible, but that was kind of
> an arbitrary choice.  Also including sigi+sigr patterns would make
> sense, to allow for different types of signature algorithms.
>
> > 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.
>
> I'm not sure the composition rules are simple yet, but they're
> definitely intriguing, particularly if they extend to handling other
> cases.
>
> Trevor