[noise] "sig" modifier (was: Extension spec: Static-Static Pattern Modifiers)

[Justin Cormack]

Yes that makes sense. I am also interested in the use case of DH and signatures,
but I think the rules for composition of doing two patterns together
are the same as we
discussed for the post quantum ones; with some complexities eg around
your recent
suggestion of moving some tokens to encrypt ephemerals. But it
definitely makes sense
to do this incrementally as there are lots of options.

On Thu, 22 Nov 2018 at 18:46, Trevor Perrin <trevp at trevp.net> wrote:
>
> On Tue, Nov 20, 2018 at 10:02 AM Justin Cormack
> <justin at specialbusservice.com> wrote:
> >
> > Planning to spend some time writing up signatures in a few weeks when
> > I have some time.
>
> Yeah, I'd like to knock out a "sig" spec soon, so we could end the
> year with a good set of modifiers/extension specs: ss, noss, hfs, sig.
>
> The challenge for a "sig" modifier is to identify the simple/useful
> case we can address now, in a way that's consistent with / doesn't
> preclude more complex signature uses in future:
>
> Here's what I mean:
>
> Simple case
> ------------
>  * User specifies a single signature algorithm, and all static public
> keys and authentication DHs are replaced with this.  This addresses
> people who want to use Noise with signing keys but also use the static
> keys to sign other things.  E.g.
>
> Noise_XXsig_25519+Ed25519_AESGCM_SHA256:
>  -> e
>  <- e, ee, s1, sig1
>  -> s1, sig1
>
>
> Complex cases
> --------------
>  * Different authentication types for initiator or responder: e.g.
> different signature algorithms, or one party uses signatures, the
> other uses DH.
>
>  * Wildcard authentication types:  We add transmitted type fields so
> that the signature type is transmitted dynamically, instead of encoded
> in the Noise protocol name.
>
>  * Signatures for 0-RTT auth: Parties could send signatures even
> before they've received an ephemeral, accomplishing something similar
> to "ss": an authentication which can be used in your first flow, but
> which is replayable, thus weaker than a later auth.
>
>  * Key reuse: A single key used for both DH and signatures.
>
>
> Tentatively I think just replacing authentication keys and DH with
> (s1, sig1) would be pretty useful and doesn't preclude the more
> complex cases in future, along these lines:
>
> https://moderncrypto.org/mail-archive/noise/2018/001793.html
>
> But needs more thought.
>
> I also think this would compose well with "hfs", the idea being that
> we're numbering the tokens to match the order of algorithms specified
> in the protocol name:
>
> Noise_XXhfs+sig_25519+NewHope+Ed25519_AESGCM_SHA256:
>  -> e, e1
>  <- e, ee, ekem1, s2, sig2
>  -> s2, sig2
>
>
> But again, we'd want to make sure this is something that will
> generalize well in the future.
>
> Trevor