Re: [Cfrg] Call for adoption: Threshold Signatures

Chelsea Komlo <> Fri, 09 October 2020 22:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8F9E13A0EF0 for <>; Fri, 9 Oct 2020 15:25:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CUiifgcMKhfU for <>; Fri, 9 Oct 2020 15:25:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2764D3A0EDB for <>; Fri, 9 Oct 2020 15:25:47 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id 099MN3BS032155; Fri, 9 Oct 2020 18:25:44 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=default; bh=wRzorLFGO3S32jkxwDXO1y+AVmPm1mPRw3XZ/i48YrU=; b=Uz6tmbCy0KSRg4k19sjaLDnKhioAAr03nyldsw9qWfAUI+9M9rz5q0nTTxSjK6wYi7sD 5cRvONY7UXrIeZ1wJkrPainHfOtPSxM24ijMe/WTvqHvxZiAWSA0cO2Jy6qFzcMB+Z35 VmbXCM8FCfH3OPjLJPRnO0VbwBxOXIPxUU0=
Received: from ( []) by with ESMTP id 3429sx851c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Fri, 09 Oct 2020 18:25:44 -0400
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2044.4; Fri, 9 Oct 2020 18:25:44 -0400
Received: from ([fe80::28cc:77d3:dedf:a4e9]) by ([fe80::28cc:77d3:dedf:a4e9%18]) with mapi id 15.01.2044.004; Fri, 9 Oct 2020 18:25:44 -0400
From: Chelsea Komlo <>
To: Phillip Hallam-Baker <>
CC: Ian Goldberg <>, "" <>
Thread-Topic: [Cfrg] Call for adoption: Threshold Signatures
Thread-Index: AQHWnZDi+VMQ29Y2Mkaes3ik/2ZS3qmOdzwAgAACPwCAAB3w3oABEJgAgAArU+g=
Date: Fri, 9 Oct 2020 22:25:44 +0000
Message-ID: <>
References: <> <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_5cbbaddb27d342aba7330223b0f7b801uwaterlooca_"
MIME-Version: 1.0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 impostorscore=0 mlxlogscore=999 mlxscore=0 adultscore=0 spamscore=0 priorityscore=1501 clxscore=1015 suspectscore=0 bulkscore=0 phishscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010090167
Archived-At: <>
Subject: Re: [Cfrg] Call for adoption: Threshold Signatures
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 09 Oct 2020 22:25:51 -0000

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 <>
Sent: Friday, October 9, 2020 3:22:48 AM
To: Chelsea Komlo
Cc: Ian Goldberg;
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 <<>> 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.

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.


From: Cfrg <<>> on behalf of Ian Goldberg <<>>
Sent: Thursday, October 8, 2020 9:20 AM
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:
> >
> >
> >
> > 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<>).
> >
> > Thank you,
> > Nick (for the chairs)
> > _______________________________________________
> > Cfrg mailing list
> ><>
> >
> 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:
> (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 mailing list<>