Re: [Cfrg] Adoption of threshold drafts by RG

[Chelsea Komlo <[e-mail]>]

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.

Chelsea

[1] https://eprint.iacr.org/2020/852


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



On Mon, Sep 21, 2020 at 7:01 PM Watson Ladd <[e-mail]<mailto:[e-mail]>> wrote:
On Mon, Sep 21, 2020 at 12:25 PM Phillip Hallam-Baker
<[e-mail]<mailto:[e-mail]>> 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?
>
> https://tools.ietf.org/id/draft-hallambaker-threshold-sigs-04.html#draft-hallambaker-threshold
> https://tools.ietf.org/id/draft-hallambaker-threshold-sigs-04.html

My understanding is NIST is carrying out a standardization activity
https://csrc.nist.gov/projects/threshold-cryptography . 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. https://eprint.iacr.org/2018/417.pdf explains
some of the issues well, and it's really quite subtle and difficult.
The design of FROST https://eprint.iacr.org/2020/852.pdf 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.