Re: [Cfrg] Adoption of threshold drafts by RG

[Ian Goldberg <[e-mail]>]

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