Re: [Cfrg] Recommendations Regarding Deterministic Signatures

["Scott Fluhrer (sfluhrer)" <[e-mail]>]

As far as an RFC8032-compatible threshold signature scheme, it would appear to be fairly easy to do, as long as:


  *   You don’t mind not following the precise algorithm in RFC8032, but want something that generates signatres that is computationally indisguishable from RFC8032 signatures.
  *   You don’t mind it if the algorithm is nondetermanistic (that is, signing the same message twice, with different subsets of signers, yields different signatures).

The public keys and the verification process are completely RFC8032.

To be frank, this is simple enough that I would be rather surprised if it wasn’t already published.  However, if people are interested, I will write it up…

From: Cfrg <[e-mail]> On Behalf Of Phillip Hallam-Baker
Sent: Friday, December 20, 2019 1:09 PM
To: John Mattsson <john.mattsson=[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [Cfrg] Recommendations Regarding Deterministic Signatures

The objections to the deterministic signature approach raised in that NIST paper could be avoided by applying the Kocher blinding approach whose patent has recently expired as I point out in another message.

However, there is also NIST interest in threshold cryptography and while {Ed/X}{25519/448} support threshold key generation and threshold decryption and threshold key agreement, RFC8032 does not appear to be viable as a good threshold signature scheme. (It is possible to do multi-signatures of course and I have a defective threshold scheme that might make sense in a TPM environment)

I will be submitting an Internet Draft describing threshold key generation and threshold decryption by the end of the year (the code runs) and I should have a threshold key agreement draft shortly after. It would be really nice if we had a threshold signature scheme to complete the set (get that 20% matched set armor rating).

In particular, I believe that we need a threshold signature scheme that is non-interactive. This is because I need to be able to explain the scheme to a layperson who does not understand the signature scheme. For example: The Alice+Bob aggregate signature is secure because it is constructed a signature contribution from Alice and a signature contribution from Bob, both of which are secure signatures in their own right and both of which have the same exact construction with respect to Alice and Bob's public key as the aggregate signature does to the aggregate key.