Re: [Cfrg] Adoption of threshold drafts by RG

Ian Goldberg <> Wed, 30 September 2020 17:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 502FF3A0BC0 for <>; Wed, 30 Sep 2020 10:20:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, 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 VVd5_HI-6Kl2 for <>; Wed, 30 Sep 2020 10:20:08 -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 85FE03A0B64 for <>; Wed, 30 Sep 2020 10:20:08 -0700 (PDT)
Received: from ( []) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id 08UHK4qM006772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 30 Sep 2020 13:20:06 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 08UHK4qM006772
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1601486407; bh=qpmmki7Lp1UCoFYCa8R2ZYQL8ps3lzn/vd9pUibBuao=; h=Date:From:To:Subject:References:In-Reply-To:From; b=WMuP5AY/xXxIZ+zS/DaMYrFSY8e6bmJknFX0O4GrdrdJrnXWUufhHaplWOpYUb/We B0rSGXV/vgxJdAtt8oPHRbVLgOIVNjIYBPoZaKEXAR5e7DcS0jLD135Zae2ag5HsXS Dj4xFUIWBCt+orDxb/WNyQ4xISKNHQGzWZRg4T9c=
Received: from yoink ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 3221F5FC0047; Wed, 30 Sep 2020 13:20:04 -0400 (EDT)
Received: from iang by yoink with local (Exim 4.90_1) (envelope-from <>) id 1kNflr-0003JN-KE; Wed, 30 Sep 2020 13:20:03 -0400
Date: Wed, 30 Sep 2020 13:20:03 -0400
From: Ian Goldberg <>
Message-ID: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-UUID: 8c02b8f3-5eb4-4934-a878-ce985e2fee1b
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: Wed, 30 Sep 2020 17:20:11 -0000

On Wed, Sep 30, 2020 at 12:50:22PM -0400, Phillip Hallam-Baker wrote:
> As far as the use cases go, I am starting to see the basis for the Drijvers
> attack. Your use of the term 'concurrency' is a little confusing to me. I
> am a protocol guy, not a cryptographer. What is the information that you
> are assuming is shared between a set of 'concurrent' signatures?

Just to clear up the terminology here: 'concurrency' is used in its
protocol sense: two executions of a protocol are concurrent if, roughly,
a party can see some initial messages from runs of multiple instances of
the protocol before deciding what messages to send to continue/complete
all of the instances.

For example, participant P1 initiates say 7 signing requests with
participant P2.  P2 sends their R contributions for each of those
requests, and only after seeing all 7 of P2's contributions does P1
choose its 7 R contributions to continue the 7 concurrent protocols.

> However I am not convinced that an HSM can perform the attack from the
> information made available to it. When implemented as a CPU co-processor,
> the HSM will only ever see the R contribution value from the other party
> and the message. The HSM never sees the final signature or the other
> contributions, nor does it get to choose the message. This is not the case
> for a threshold signature service however. That will see the final
> signature.

The attack does not require choosing the messages (just seeing the
messages).  It does require seeing the final signatures, but signatures
aren't typically considered private, so who knows where they'll end up.
Ian Goldberg
Canada Research Chair in Privacy Enhancing Technologies
Professor, Cheriton School of Computer Science
University of Waterloo