Re: [Cfrg] Call for adoption: Threshold Signatures

Phillip Hallam-Baker <> Fri, 23 October 2020 18:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C0943A1091 for <>; Fri, 23 Oct 2020 11:11:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, 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 HOMfaNlCzDCW for <>; Fri, 23 Oct 2020 11:11:49 -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 7FDE03A108E for <>; Fri, 23 Oct 2020 11:11:49 -0700 (PDT)
Received: by with SMTP id l15so1942808ybp.2 for <>; Fri, 23 Oct 2020 11:11:49 -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; bh=4ZcJZHvr+clXXzHeoqKs6dYcgH/8V9YoV1j+sJiJCZs=; b=tEdANKtfcWzXuiZ4qKir5TFUy+AU1se4Cm15h0vQJzPnIubC5GV1/o9swi62LQXND9 keTdku2DnmSMmDPyOXGlXaAgVLk1ONIrQiMaUx5OdVqxrNmbHy0qGDYZai/h4y8V3X7N MnUojkW3ri295UkNe/JSE5+b1vts4CXPS2ZxNN7Prnm6WqnkhShPNxApcgMiwkSh0Q9V OtGDP/EBQEolfbBt9S9xwcIWWN54SIsn7esyGT6m8SuCNI49bUASVkrwp8dpXBIR1ISV p8u3GD4JKkQQpp5pjZu4P8N+Sn0W5+vKmt9kBQhZtPJ+7fBJaMf7ovqzk0cGj/xvT/xF tJpQ==
X-Gm-Message-State: AOAM532AGY1N5oxvXdzErZg/UmrVAFRnG7ODaZE20P9fO+etdwv2+NsR rjrTEHckJtes+uaafQoMKoCs7IPMp4Bhl5psUM4=
X-Google-Smtp-Source: ABdhPJxY5rx1vwQMvApM5p/IS22DDBkISfNmwLdRqnZwok1hu1nuf4Gd0CegvFdkUkK0/bCSHUK35d+FMVa0RD3EUjs=
X-Received: by 2002:a25:af41:: with SMTP id c1mr5652605ybj.213.1603476708649; Fri, 23 Oct 2020 11:11:48 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Phillip Hallam-Baker <>
Date: Fri, 23 Oct 2020 14:11:37 -0400
Message-ID: <>
To: Jeff Burdges <>
Cc: Chelsea Komlo <>, IRTF CFRG <>
Content-Type: multipart/alternative; boundary="0000000000009fefc805b25a83f4"
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, 23 Oct 2020 18:11:51 -0000

On Wed, Oct 21, 2020 at 9:37 AM Jeff Burdges <> wrote:

> I’d meant to send a follow up email, but I already moderated my position
> on both those points.  :)
> > On 20 Oct 2020, at 16:25, Chelsea Komlo <> wrote:
> > Optimization to a single-round signing scheme. The ability to perform
> single-round (or async) signing is desirable for many implementers (and
> publishing public ephemeral values is a common technique in other
> cryptographic protocols). While misuse is possible, rollback issues are
> also possible in a two-round scheme as checkpoints can occur between rounds.
> We need “hardware” security for the two pre-witnesses between the rounds,
> which software artifacts should enforce.  It’s easy if the hardware is
> simply RAM and if libraries enforce this by not providing callers with
> access to pre-witnesses in an easy to serialize form.  It’s also perfectly
> valid for a signer that runs inside a TEE to export pre-witnesses encrypted
> to its TEE.  It’s realistic for hardware signers for crypto-currencies to
> enforce this of course.

What are we defining as a 'round' here? Calling something a pre-witness
does not mean it disappears.

At the protocol engineering level we are always looking for ways to
piggyback one message on another. But if I need to generate and register
anything that looks like a commitment whether it is called a round or a
pre-witness is looking like a round to me.

> Yet, if you merely expose pre-witnesses directly in pure software, or
> write the draft s if that’s okay, then developers will reuse them.  This is
> a certainty, and will happen repeatedly, not some abstract risk.

It is not clear to me where the controls to prevent this should go. At the
application protocol level, there are precautions that can be taken. But
they tend to get very context specific. I can't see a good generic
construct at this point. But that doesn't mean one can't exist.

Also, this is getting into design, not discussing whether we should be
doing the work.

> I’d love some guidance from the rest of the group about to what extent
> provable security issues should even appear inside the draft.

That is a good question as the answer might well be changing. We have not
provided proofs in the past. Analysis has been left to separate papers. And
one reason for that is the document format was not up to the task of
describing a proof. We now have a document format that makes providing a
proof more practical but it is still less than satisfactory in that respect.

The point of this process is to provide cryptographic capabilities in a
form that can be employed as modules in a network protocol. And that raises
a rather different set of concerns to those considered in academic papers.
We expect modules to be re-usable. There is an active academic interest in
threshold signature schemes because those are genuinely difficult, the ECDH
type signature schemes having the property that if you mess up, you leak
the private key, oops. As a protocol designer, threshold encryption is far
more interesting but as far as I can tell, the issues were addressed over
20 years ago. Nobody is going to be getting tenure out of a Threshold key
agreement algorithm. But Data At Rest breaches are costing billions of
dollars and threshold is almost certainly part of the answer.

So ultimately, it is up for the RG chairs to decide what they want to do.