[noise] signature questions

[Arvid Picciani]

maybe some feedback from practical use in devguard, since we're
already doing signatures on noise.

> 1. Which signature functions to support?

Ed25519 is fine. I really like that noise has strong opinions and very
few safe options.
We're actually building a HSM, because the existing ones dont support
ED, but thats fine.
I suspect if you want popularity, you go for TLS anyway.
(also the most popular hsm yubikey doesnt really have any useful
stuff, most people just use it for 2fa)

>  In terms of hash function choices

signing the handshake hash has been a can of worms, and i'm still
scared i did this wrong.
i'd really appreciate if the properties are defined more strict with
alot less flexibility that is discussed here.
Even if noise supports *any* signature algo, it should still define
very strictly on how its supposed to be applied.

I'm currently inserting the hash of the signature in-place back into
the padded encrypted message, so that the message remains
indistinguishable from randomness.
That's totally not defined in the noise spec, but i think it should be.


> You want to use signing keys for identity keys instead of DH keys

yeah thats me. Have to use ed keys because using x keys for signatures
isnt known to be safe.

> * You want to do authentication in an initial message, which you can
do (in replayable form) with signatures more easily than DH

The wireguard paper offers some insights on replay that i think should
make it back to noise.

On Sun, Sep 30, 2018 at 5:58 AM Trevor Perrin <trevp at trevp.net> wrote:
>
> On Thu, Sep 13, 2018 at 8:32 AM Justin Cormack
> <justin at specialbusservice.com> wrote:
> >
> > I have been thinking about writing up details of signatures in Noise,
> > and had a few questions for discussion.
> >
> > 1. Which signature functions to support? In terms of crypto choices,
> > Noise has been strict about supporting modern choices with good
> > properties. So supporting Ed25519 for example clearly makes sense.
> [...]
> >  - RSA PKCS#1v1.5 exponent 65537 usually with SHA256 (wide support)
> >  - RSA PSS exponent 65537, usually with SHA256 (TPM2, some yubikey
> > support, Android, requires a random source)
> >  - ECDSA p256 with SHA256 (Apple devices, TPM2, Android)
> >  - ECDSA other NIST curves eg p521 (Android)
> >
> > Does it seem reasonable to support the common subset of these as well?
> > For RSA, all devices support 2048 bit keys, and many support 4096 bit,
> > so it might be say six common functions plus ed25519 that would be
> > specified.
>
> We'll have to consider representative algorithms to check our designs,
> but the question of what to "officially support" seems premature, and
> I'm not sure it's something we should do.
>
> We put specific algorithms in the core spec, it's true, but people are
> using other algorithms (e.g. secp256k1).  We should probably focus on
> creating frameworks that could be used with any reasonable crypto,
> rather than anointing our favorite algorithms.
>
> All the things you mention seem like they should be supported.
>
>
> > 2. In terms of hash function choices, the message we are signing is
> > `h`, the state from GetHandshakeHash() at the point at which the
> > signature is in the protocol. Should we require that the protocol hash
> > function is at least the size of the hash function being used by the
> > signature? eg Ed25519 uses sha512, should we insist that the hash
> > function used is that size, or even the same hash function?
>
> Good question:  DH has a very simple interface with hashing (you just
> hash a "shared secret"), so we haven't had to deal with public-key
> crypto algorithms that are more tightly interwoven with a hash
> function.   But with both KEMs and signatures things will be more
> complicated.
>
> One approach is to imagine Noise providing "callbacks" to the crypto
> algorithm, that's how I was hoping the PQ KEMs would work.
>
> Another approach is to imagine the public-key algorithms tightly bound
> to a hash function internally, which is a detail disconnected from
> Noise hashing.
>
> Thinking out loud:  We might have to support both: provide a
> "callback" interface which public-key crypto can make use of, allowing
> more integrated use of a single hash algorithm / implementation.  But
> also support more traditional algorithms that have their own
> hash-function integrated, or make their choice based on the hash
> listed in the Noise protocol name.
>
> Not sure we need to insist on a size-match, but you're only going to
> get as much collision-resistance as your smallest hash.
>
>
> > 3. Should we support some sort of "wildcard" functionality initially?
> > I was kind of inclined to get the basic known algorithm version done
> > first, but obviously if you are talking to a variety of disparate
> > endpoints agility for signatures might be important.
>
> I'd view that as a separate piece of work, so we're not biting off too
> much at once.
>
>
> > 4. Should deferral and noss modifiers be implicit for signature
> > variations or explicit? There is no choice here, so it is just a
> > question of which is clearer or easier to read.
>
> I think we should look at this in context of the whole naming scheme.
>
>
> > 5. Wondering about listing some options for the naming of these.
> >
> > Trevor's example was
> > XKsig1i (e.g. XKsig1_25519+RSA2048) # rsa sig
> >
> > which I presume in full is
> >
> > Noise_XKsig1i_25519+RSA2048_AESGCM_SHA256
> >
> > Another option might be that rather than using numbers, any sig or
> > skem options refer in order to tokens at the end eg
> >
> > Noise_XKsigi_25519_AESGCM_SHA256_RSA2048 (or
> > Noise_XKsigi_25519+RSA2048_AESGCM_SHA256)
> > Noise_XKsigisigr_25519_AESGCM_SHA256_RSA2048_RSA2048
> >
> > the additional algorithms would be read on order for specified sig,
> > skem etc. It involves specifying duplicated options twice,
> > but on the other hand the use of small numbers is a bit overused...
>
> Hmm, I think that stacking more name sections on the end could
> complicate future parsing, and adds verbosity; not sure it gains
> enough readability to balance that out.
>
> We should definitely keep thinking on name conventions though, I think
> the proposal below is not bad, but could probably be improved on:
>
> https://moderncrypto.org/mail-archive/noise/2018/001793.html
>
> Trevor
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise