[noise] Extension spec: Signatures

Trevor Perrin trevp at trevp.net
Mon Dec 17 22:45:51 PST 2018


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


More information about the Noise mailing list