Re: [Cfrg] Threshold signatures

[Tony Arcieri <[e-mail]>]

I'd be interested in comparing / contrasting your scheme to prior art with
running code, notably:

- KZen's Multiparty EdDSA, a straightforward application of distributed
threshold Schnorr to Ed25519:
https://github.com/KZen-networks/multi-party-eddsa
- CoSi, a Merkle-tree based approach for collective Ed25519 signing
targeting something more along the lines of a consensus protocol:
https://tools.ietf.org/id/draft-ford-cfrg-cosi-00.html

On Thu, Jan 2, 2020 at 2:28 PM Phillip Hallam-Baker <[e-mail]>
wrote:

> OK so with quite a bit of help, have got a prototype of threshold
> signatures going. There is a bit more to the draft than just the algorithm
> though as the way the scheme is presented and packaged has consequences.
>
> From the presentation side, I want to be able to argue that the threshold
> sig scheme has (almost) precisely the same security properties as the
> RFC8032 scheme. Which means that the core of the presentation must align as
> closely as possible with the RFC8032 scheme.
>
> There are some subtle design choices that don't impact security but may
> well have impact on specific use cases. The use cases I am currently
> considering are
>
> 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.
>
> Another issue that comes up with HSMs is auditability. The construction of
> r_i must be auditalble which means it must be deterministic.
>
> 2) Code signing: The code signing role is split across two or more signers
> and MAY permit a signature to be created by a quorum smaller than the total
> number of authorized signers (n, t). Signing quorums may prove particularly
> attractive for open source projects.
>
> I have introduced a new role, of coordinator for the party that manages
> the process.
>
> Are there additional use cases that should be considered. That is use
> cases that raise additional requirements. The need to sign blockchains is
> often raised but that doesn't seem to raise additional requirements over
> code signing.
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>


-- 
Tony Arcieri