Re: [Cfrg] Call for adoption: Threshold Signatures

[Nick Mathewson <[e-mail]>]

On Thu, Oct 8, 2020 at 12:34 PM Nick Sullivan
<nick=[e-mail]> wrote:
>
> 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

Hello!

Briefly:
  a) yes.
  b) slight preference for FROST, with a proviso that I'm more of a
cryptography consumer than a standards producer.
  c) I can comment on drafts from time to time from the perspective of
a downstream user of cryptography, but I am not a cryptographer and am
not competent to review cryptographic security.

In more detail:

Speaking as a Tor developer: we have a few use cases that would
benefit from a standardized threshold signature system, especially if
one were to be standardized some time in 2021.  For us the biggest
benefit to such a system would be in our network's directory authority
system, which currently authenticates large directory objects using
one signature from each authority.  Our plan is to move to a different
design [1] [2], however, in which many smaller objects need to be
authenticated individually.  A multisignature design would be a bit
too expensive for this use, so threshold signatures seem like a clear
win.

General preferences for any eventual standard:

  1)  We'd prefer a system that tolerates concurrent use.  For
distributed systems like ours, it's much more comfortable to have a
system that tolerates concurrent runs than it is to try to prove that
a concurrent run could never happen.

       IIUC, the mechanism that FROST uses to make concurrent use safe
(safer?) seems like it would be portable to other signature systems of
this kind, so I hope it will be included in whatever design is
produced.

  2) Compatibility with existing standardized signature formats
(ideally ed25519 or ed448) is indeed a big plus for us.

  3) Being able to operate without a trusted or centralized
coordinator is important for our application, so we'd want any
standard to at least include a way to work without one.

[1] https://gitlab.torproject.org/tpo/core/torspec/-/blob/master/proposals/323-walking-onions-full.md
[2] https://www.usenix.org/conference/usenixsecurity20/presentation/komlo

yrs,
-- 
Nick Mathewson