[noise] Extension spec: Signatures

[Trevor Perrin]

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.

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.


> 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?


> 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.

 * 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.

> 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