Re: [CFRG] [Cfrg] Call for adoption: Threshold Signatures

[Phillip Hallam-Baker <[e-mail]>]

On Mon, Nov 2, 2020 at 5:50 PM Richard Barnes <[e-mail]> wrote:

> On Mon, Nov 2, 2020 at 5:20 PM isis agora lovecruft <
> [e-mail]> wrote:
>
>> Christopher Wood transcribed 1.1K bytes:
>> > On Thu, Oct 8, 2020, at 9:33 AM, Nick Sullivan wrote:
>> >
>>
>> > Probably only one. The structure of draft-hallambaker-threshold-sigs as
>> an
>> > extension to RFC8032 is attractive, though I think draft-komlo-frost
>> (and
>> > the related paper) is generally a better starting point, especially
>> given
>> > its assessment of attacks on related schemes such as 2020/945. It also
>> > seems to have plenty of backing implementations and reviews. If we can
>> > specialize it to RFC8032, perhaps with Richard's work as the basis for
>> > that change, then I prefer FROST.
>>
>> Hi Chris,
>>
>> What do you mean by specialising it to RHC8032?  Do you mean literally
>> producing RFC8032 backwards compatible EdDSA signatures using the ed25519
>> and ed448 groups?
>>
>
> I'm not Chris, but that's what I understood him to mean, and I agree with
> Chris that it would be good to have such a specialization.
>

A few points here:

1) My draft is intended as a CONTRIBUTION. People are free to use whatever
parts of it are useful.

2) The FROST draft and my draft have rather different scopes. I am only
specifying a threshold version of RFC8032. The FROST draft is providing a
general tool that can also be applied to secure other Schnorr signatures.
And those parts are also very useful because 99% of the ECDH signatures in
use today are for the NIST curves.

3) Watching the NIST workshop, it is clear to me that if CFRG decides to do
threshold EC signatures, there are going to be more options and more
constraints we need to consider besides those already submitted.

It might well be that we want multiple separate signature documents, one
describing the Meta, one describing that applies to RFC8032 and possibly a
third one applying it to the NIST curves.

4) Signature is the hardest of the ECDH threshold applications. It is also
the one that provides least additional functionality because aggregate
signatures can be used in place of threshold for most applications. It is
however a necessary function for some applications (HSM, fault tolerant
notary services, etc).

5) FROST specifies a DKG that is potentially applicable to Key
Agreement/Encryption. I would like that broken out as a separate module so
we can use it for encryption.

6) The only technical steps required to turn RFC7748 into a threshold
scheme are (1) Specify how to recover the parity of the result from the
Montgomery Ladder and (2) Specify how to encode the parity in the private
key representation for X25519, X2448.

Earlier in this threat, Iain  expressed a concern that we don't slow things
down by considering a broad scope. I don't see that as a risk. Threshold
signatures are going to take exactly as long as they take no matter what
other work is considered. It is the area where the cryptographic
construction involves most risk (getting it wrong can mean disclosure of
the private key, ability to forge signatures) and where there are the most
options.