Re: [Cfrg] Threshold signatures

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

On Thu, Jan 2, 2020 at 7:18 PM Jeff Burdges <[e-mail]> wrote:

>
> At first blush, I’d think code signing could be accomplished with a set of
> Ed25519 signatures, no?  How can 64 bytes per signer be any concern when
> signing code large code blobs?  Also, I’d expect code signing should
> require accountability, so no threshold signatures anyways, right?
>

I discuss multi-sigs in the paper but the short answer is that pretty much
every code signing system out there has a de facto assumption of one
signature. I want to be able to add robustness without impacting workflow.

But more specifically, what I want to do is to divide the ability to use a
code signing key between a cloud service and one (or more) engineers
holding code signing keys. Code signing keys have leaked from both places
but separation of duties means we are not vulnerable to a single point of
failure.


> 1) HSM module: One or both parts of the signature key shares are located
> in a HSM providing resistance against extraction of the public key. This is
> an important use case as we want the operation of the HSM to be stateless.
> The signing algorithm requires multiple rounds, in the first round, the
> signer commits to a value R_i = r_i..B. In the second round, the value r_i
> is used. So it is kinda important to construct r_i in such fashion that the
> HSM can restore it from one round to the next even though it may have
> performed other operations in the meantime.
>
> You need three round trips here because all published two round trip
> Schnorr multi-signatures are vulnerable to k-sum forgery attacks:
> https://eprint.iacr.org/2018/417.pdf  Admittedly these attacks have a
> high complexity, like 2^45 with open 128 parallel signing queries, so hard
> but still doable.
>

Yes, just seeing how those come into the picture now.