Re: [Cfrg] Call for adoption: Threshold Signatures

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Oct 21, 2020 at 9:37 AM Jeff Burdges <[e-mail]> 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 <[e-mail]> 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.