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

From: isis agora lovecruft <[email-masked]>
Date: Mon, 2 Nov 2020 22:17:57 +0000

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?

Best regards,
-- 
 ♥Ⓐ isis agora lovecruft
_________________________________________________________
OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35
Current Keys: https://fyb.patternsinthevoid.net/isis.txt

---

From: Richard Barnes <[email-masked]>
Date: Mon, 2 Nov 2020 17:49:35 -0500

> producing RFC8032 backwards compatible EdDSA signatures using the ed25519

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.

--Richard

> _______________________________________________
> CFRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: "Christopher Wood" <[email-masked]>
Date: Mon, 02 Nov 2020 15:46:49 -0800

On Mon, Nov 2, 2020, at 2:49 PM, Richard Barnes wrote:
> On Mon, Nov 2, 2020 at 5:20 PM isis agora lovecruft 
> <[email-masked]> wrote:
> 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.

+1 -- thanks!

Best,
Chris

---

From: isis agora lovecruft <[email-masked]>
Date: Mon, 2 Nov 2020 23:51:19 +0000

> > with Chris that it would be good to have such a specialization.

Thanks for clarifying!

Would this necessitate a dependency on the current ristretto255/decaf448
draft, due to the requirement that FROST signatures use a prime-order group?

Best,

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 4 Nov 2020 12:28:46 -0500

> 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.