Re: [Cfrg] Adoption of threshold drafts by RG

Chelsea Komlo <> Tue, 22 September 2020 04:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EB5743A12EB for <>; Mon, 21 Sep 2020 21:39:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.818
X-Spam-Status: No, score=-2.818 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_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 ObONWEWGuccg for <>; Mon, 21 Sep 2020 21:39:43 -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 DD5BF3A11E0 for <>; Mon, 21 Sep 2020 21:39:42 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id 08M4c28c011002; Tue, 22 Sep 2020 00:39:38 -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=6t0wmDnjJHzkxyseV3cM8S5y0AaEtl63kBhWRZfIqMI=; b=GiS1+LMlY0RHySUfhgM0GvuQyoIaYEvdoriqMgaPzj+SDCMcuC7h/OXHxObdDtSda07x dmpnVGmRhD0Rzf+eUdsZiaaTqg52EpT4Jyx209Ucg6YYxRaQ2UMTm5YLbsEU0+RT1h7a Ewr+ZSf3XbGo5JjZZ04RgMTiJy0BfO7Xxo8=
Received: from ( []) by with ESMTP id 33neygskkr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Tue, 22 Sep 2020 00:39:38 -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; Tue, 22 Sep 2020 00:39:37 -0400
Received: from ([fe80::c509:52cf:5893:c3fa]) by ([fe80::c509:52cf:5893:c3fa%18]) with mapi id 15.01.2044.004; Tue, 22 Sep 2020 00:39:37 -0400
From: Chelsea Komlo <>
To: Phillip Hallam-Baker <>, Watson Ladd <>
Thread-Topic: [Cfrg] Adoption of threshold drafts by RG
Thread-Index: AQHWkDO8jAIE8QI0b0+nx8IzpD1x2alz+L8AgABPpYD//8gftw==
Date: Tue, 22 Sep 2020 04:39:37 +0000
Message-ID: <>
References: <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_a7ff6f80e5c54ac6960d2b6fc383086cuwaterlooca_"
MIME-Version: 1.0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1011 impostorscore=0 phishscore=0 priorityscore=1501 mlxscore=0 malwarescore=0 mlxlogscore=999 bulkscore=0 lowpriorityscore=0 suspectscore=0 spamscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009220038
Archived-At: <>
Subject: Re: [Cfrg] Adoption of threshold drafts by RG
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: Tue, 22 Sep 2020 04:39:45 -0000

Hi Phillip,

We spoke before the last draft of FROST was published in July [1]. Since then, our work has undergone peer review and has been accepted.

While we will be making minor changes to [1] based on comments from reviewers and implementors that are interested in using FROST, the core contributions of the scheme are stable.



From: Cfrg <> on behalf of Phillip Hallam-Baker <>
Sent: Monday, September 21, 2020 3:45:53 PM
To: Watson Ladd
Subject: Re: [Cfrg] Adoption of threshold drafts by RG

On Mon, Sep 21, 2020 at 7:01 PM Watson Ladd <<>> wrote:
On Mon, Sep 21, 2020 at 12:25 PM Phillip Hallam-Baker
<<>> wrote:
> Could the chairs please start the discussion of adoption of my threshold crypto drafts as was promised six months ago and on numerous occasions since?

My understanding is NIST is carrying out a standardization activity . While that's
by no means a barrier to our adoption, I think alignment with the
results of that activity are valuable.

I am aware of that work and provided feedback on their draft report.

I would note the schemes described are insecure in the presence of
concurrency, as well. explains
some of the issues well, and it's really quite subtle and difficult.
The design of FROST solves these
issues, and I don't see any discussion in the draft of them.

Where do you see concurrency in the nested signature approach? The issue is elided by enforcing a sequential order on the operations.

I have reviewed FROST. However the authors keep telling me they are not yet ready to have it considered so I am not.

>From a practical point of view, the most common use I have found for threshold signatures has t=2 with an application level share holder calling an HSM (which may be local or remote) to perform a part of the signature and then completing the process.