[noise] signature questions

[Trevor Perrin]

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