Re: [Cfrg] Call for adoption: Threshold Signatures

We (the authors of FROST) are happy to make our draft compatible with some standard key representation. However, we prefer for our draft to be otherwise independent, as we don't want to be blocked on the completion of another draft.

Further, when operating in the distributed key generation setting, FROST has specific security requirements; namely that signers prove possession of their private key.

Here is what we propose. We can define at minimum a "plain" key-generation protocol in the FROST draft (such as a basic DKG and central dealer variant) so that we have some "shape" to work with and are not blocked/dependent on another draft. However, it should be easy for additional drafts to define alternative key generation protocols that will be compatible with FROST signing.

________________________________
From: Phillip Hallam-Baker <phill@hallambaker.com>
Sent: Friday, October 9, 2020 3:22:48 AM
To: Chelsea Komlo
Cc: Ian Goldberg; cfrg@irtf.org
Subject: Re: [Cfrg] Call for adoption: Threshold Signatures

Just to clarify here. The group should only be working on one threshold signatures draft for Ed25519 and Ed448. I think we need to decide whether we are working on threshold first, then decide which bits of threshold and only then go on to consider how the drafts are structured. We might have one or three.

There are three separate work pieces that the group may consider:

Threshold Key Generation
Threshold Key Agreement
Threshold Signatures.

Threshold Key Generation can be used for key agreement or signature. How you are going to use the shares doesn't change how you get them. The only real difficulty in Threshold Key Agreement is the need to explain how to obtain and represent the parity information in X25519 and X448.

The biggest leverage we can get from this work is if we can get CPU makers to put an ECDH core on their CPUs with a key bound during manufacture. And to do that we really need a story on all three. I strongly suspect that the origin point for the NIST work was some work that has been going on in the cyber supply chain area for a decade now.

Having a standard is more than just having a draft with the math. We also need to specify a new private key format for the key shares, create test vectors and the like.

On Thu, Oct 8, 2020 at 11:23 PM Chelsea Komlo <ckomlo@uwaterloo.ca<mailto:ckomlo@uwaterloo.ca>> wrote:

As another of the FROST authors, I am interested in the FROST draft moving forward and of course would be involved in working on it.

We have an implementation of FROST in Rust; note that this implementation will have minor changes as we receive feedback from our presentation at SAC [1] and elsewhere.

https://git.uwaterloo.ca/ckomlo/frost/

We have also been in discussion with those at NIST who are organizing the threshold signatures standardization effort, and will be participating in the upcoming workshop.

Note that FROST can also be used when keys are generated via a central dealer as well as via a DKG (Distributed Key Generation) protocol. We have both variants in our implementation, even though we specify only the DKG variant.

https://git.uwaterloo.ca/ckomlo/frost/-/blob/master/src/keygen.rs

<https://git.uwaterloo.ca/ckomlo/frost/-/blob/master/src/keygen.rs>[1] https://sac2020.ca/papers.html

________________________________
From: Cfrg <cfrg-bounces@irtf.org<mailto:cfrg-bounces@irtf.org>> on behalf of Ian Goldberg <iang@uwaterloo.ca<mailto:iang@uwaterloo.ca>>
Sent: Thursday, October 8, 2020 9:20 AM
To: cfrg@irtf.org<mailto:cfrg@irtf.org>
Subject: Re: [Cfrg] Call for adoption: Threshold Signatures

On Thu, Oct 08, 2020 at 09:11:58PM +0000, isis agora lovecruft wrote:
> Nick Sullivan transcribed 2.9K bytes:
> > Dear CFRG participants,
> >
> > After some active conversations on the mailing list, there seems to be
> > support for taking on work related to threshold signatures at the CFRG.
> > This email commences a 3-week call for adoption for the topic of "Threshold
> > Signatures" that will end on October 28th, 2020:
> >
> > There are two drafts that have been submitted for consideration on this
> > topic:
> > https://datatracker.ietf.org/doc/draft-komlo-frost/
> > https://datatracker.ietf.org/doc/draft-hallambaker-threshold-sigs/
> >
> > Please give your views on the following questions:
> > a) should this topic be adopted by the CFRG as a work item, and if so
> > b) should one or both of these documents should be considered as a starting
> > point for this work
> > c) are you willing to help work on this item and/or review it
> >
> > Please reply to this email (or in exceptional circumstances, you can email
> > CFRG chairs directly at cfrg-chairs@ietf.org<mailto:cfrg-chairs@ietf.org>).
> >
> > Thank you,
> > Nick (for the chairs)
>
> > _______________________________________________
> > Cfrg mailing list
> > Cfrg@irtf.org<mailto:Cfrg@irtf.org>
> > https://www.irtf.org/mailman/listinfo/cfrg
>
> Hi all,
>
> I would definitely like to see a standarisation of FROST move forward, since I
> already have two clients interested in using it, and I have a Rust
> implementation in progress here: https://github.com/isislovecruft/frost-dalek
> (If you grep for "[CFRG]" there's a few comments on things that I suspect might
> be useful to specify in a standard.)
>
> To that end, I'm happy to help the authors with both working on the draft and
> review.

Multiple implementations already!  That's great!

I suppose I should just say for the record that as one of the authors of
FROST, I of course am also interested in seeing it move forward, and
would be involved in working on it.
--
Ian Goldberg
Canada Research Chair in Privacy Enhancing Technologies
Professor, Cheriton School of Computer Science
University of Waterloo

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org<mailto:Cfrg@irtf.org>
https://www.irtf.org/mailman/listinfo/cfrg
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org<mailto:Cfrg@irtf.org>
https://www.irtf.org/mailman/listinfo/cfrg