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

[Trevor Perrin]

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