Re: [Cfrg] Call for adoption: Threshold Signatures

Nick Mathewson <> Mon, 12 October 2020 16:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F3FB3A0E96 for <>; Mon, 12 Oct 2020 09:22:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7-Aica0PJRrK for <>; Mon, 12 Oct 2020 09:22:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B3F803A0E95 for <>; Mon, 12 Oct 2020 09:22:36 -0700 (PDT)
Received: by with SMTP id h20so17492329lji.9 for <>; Mon, 12 Oct 2020 09:22:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=5JdL+yw7HgIJVcX8a6PthEzA5FgnRoOgqe6sVLuiITc=; b=GKjoAQVvFHZ5Vw8px1d2rNXE49JLyQVtqD5CCMrfUkURv1yDkwrHmZWIUX8QbkoZDW CKcH0fCjpBoNLaPvauAjTOOQbkZ8ZMa90zehx9CqiVBVoYrFC8REGRcyqo1xT3rmJa4q 9tuQ8AWY6cPfx6jz1gKL+tyUp8pgbi2dobSCRmw4byNV7kF0SW52W9BlMTCyjic4Ga6W 2u9PQCG9q4gHhd8C780PRfoCV39DokL7SMJGJOUHnKTmIlpRbsjViFe3knohMeaQzbiM Rl47ZAstV5qVzMYbhnXDr4vVpr0XLknxpq2xbwOf1go64Dr9qwnedJz+e0o2465rrsDp auzg==
X-Gm-Message-State: AOAM532tIgoGx8abGUl/zWWw66bnhGmom4H0yQ69/f8T16JpmYN4V/gQ 7XGty/ZB1u1a7rxhTFaGRAW1zBApjBZ8DY1x108=
X-Google-Smtp-Source: ABdhPJyYrreSIzZkaluo5rQTVp9hVd0IQcgUxpPFkcEPQAS68fFA+GrJRWuvPiuOarY82pBOFB6lmVTZaqsLRIq7msQ=
X-Received: by 2002:a2e:7811:: with SMTP id t17mr7078197ljc.308.1602519754632; Mon, 12 Oct 2020 09:22:34 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Nick Mathewson <>
Date: Mon, 12 Oct 2020 12:22:23 -0400
Message-ID: <>
To: Nick Sullivan <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Mon, 12 Oct 2020 16:22:39 -0000

On Thu, Oct 8, 2020 at 12:34 PM Nick Sullivan
<> 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:
> 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


  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

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

  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.


Nick Mathewson