Re: [Cfrg] Threshold signatures

Well I will be looking for co-authors :-)

The big difference is that I want the threshold sigs to be plug compatible
with regular RFC8032. One of my big motivations for this work is to have a
clear 'want list' to give to the likes of Intel, AMD, Cypress etc for
onboard crypto co-processors to support Curve {X/ED}{25519/448} so that
they can support application level crypto operations providing a host bound
mix in to the application keys without exposing the on-chip keys to
external parties.

The point here is that with the interest from NIST and my needs for the
Mesh, I would like to move forward on choice of one scheme we can start
using.

The killer app for threshold sigs could be code signing. Shamir (n,k)
schemes would be particularly good for open source projects.

One thing I would like to understand what the security rationale for tying
the signature hash value k to the value R is. Because that is what creates
the need for a two round protocol.

On Thu, Jan 2, 2020 at 2:57 PM Tony Arcieri <bascule@gmail.com> wrote:

> 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 <phill@hallambaker.com>
> 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
>> Cfrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/cfrg
>>
>
>
> --
> Tony Arcieri
>