Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CF3120124 for ; Thu, 2 Jan 2020 11:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ASjuu6Ow1OE for ; Thu, 2 Jan 2020 11:57:54 -0800 (PST) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DBDB120026 for ; Thu, 2 Jan 2020 11:57:54 -0800 (PST) Received: by mail-oi1-x22c.google.com with SMTP id p125so11242327oif.10 for ; Thu, 02 Jan 2020 11:57:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aDVNkv8VePI9P3LW1CwnUgLuzBIJCHNqKy1EZTPzYGM=; b=Iae211SREX2+l8CZJ90byhWSUouIb4emci05BeO4i32V4W1FyA4BSRVR+USIL5psae UpJSHM20TN9fG3KBh5AoQpEJIsPOih/A3aWS+TfPIRJd0qEIljLdEaiswLGoX1ZmyUe3 w1bbytC5WXG5yySsjZEBSnOoLv6M6i4ylNaxl7/n9Bs4R2tVOVO7ONpdiUb6xC9wqQ6a H62CEeHec86j8H4KZhsjYl3ndCJPKsbfWBGZkneLpd4WawYyy3BVgqO7RV5YLMf2dX4c iTVxIlVuTj2pBeMv8Ql2hvB1a80xUc6z3Z2gs3410ESSQG28P1bGi0AdcCS5ADDS9EBU Qdqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aDVNkv8VePI9P3LW1CwnUgLuzBIJCHNqKy1EZTPzYGM=; b=TaKqUt4Kx5mCkndjsg7d2qHVwC8dFIM5CQOPXsM1sBAskxyiFAsE6Lnv35nIDTw7wR fU9/6MpnCfNsLgPZnmiWu8tlqaX8WkdiXsuAcDLRhX0NgMpVIzgmIPMMtRJmEKrI96Ln CG7HE3pW3NQLTTjWOT1eSUkHEbYrEs0thN3NfqjS0fU4oJ5u3LtSTL6NQ/q6416jm0Tp 2SdzdlPcD7ARnApzmwJxTzMrob0qMiGm71wGpxjIsM0NHeiZMJ8QWKlPj1W28YBsTK+S Bc7AhKW5H9Ce74Xelhp4uDuk36XcuLMMRzEZEmJh0l0AqhSbwVo4J7q6oVEvf2WU3iLn 8oag== X-Gm-Message-State: APjAAAXWebwG33KxFqK7ds0qHZtKQ0e/jemc+8s2m8w90CReFFJ2gICp FUivVcfXNwuCAYTCDAUsu8pzjkchGJd8i2/JWIM= X-Google-Smtp-Source: APXvYqzXi9kkkXQnguExHhZBj/CMBBxR76/NHXLIySazPESHkDHzj5HWZ5jYcx/34S2K15RYptK/e7ce3Zx+5JpmvGU= X-Received: by 2002:aca:5083:: with SMTP id e125mr2862548oib.96.1577995073616; Thu, 02 Jan 2020 11:57:53 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tony Arcieri Date: Thu, 2 Jan 2020 14:57:42 -0500 Message-ID: To: Phillip Hallam-Baker Cc: IRTF CFRG Content-Type: multipart/alternative; boundary="000000000000d20283059b2d9b61" Archived-At: Subject: Re: [Cfrg] Threshold signatures X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2020 19:57:56 -0000 --000000000000d20283059b2d9b61 Content-Type: text/plain; charset="UTF-8" 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 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 --000000000000d20283059b2d9b61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd be interested in comparing / contrasting=C2=A0your= scheme to prior art with running code, notably:

- KZen&= #39;s Multiparty EdDSA, a straightforward application of distributed thresh= old Schnorr to Ed25519:=C2=A0https://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:=C2=A0https://tool= s.ietf.org/id/draft-ford-cfrg-cosi-00.html

On Thu, Jan 2, 2020 at = 2:28 PM Phillip Hallam-Baker <p= hill@hallambaker.com> wrote:
OK so with quite a bit of help, have got a prototype of th= reshold signatures going. There is a bit more to the draft than just the al= gorithm though as the way the scheme is presented and packaged has conseque= nces.

From the presentati= on side, I want to be able to argue that the threshold sig scheme has (almo= st) precisely the same security properties as the RFC8032 scheme. Which mea= ns that the core of the presentation must align as closely as possible with= the RFC8032 scheme.

Ther= e are some subtle design choices that don't impact security but may wel= l have=C2=A0impact on specific use cases. The use cases I am currently cons= idering are
1) HSM module= : One or both parts of the signature key shares are located in a HSM provid= ing resistance against extraction of the public key. This is an important u= se case as we want the operation of the HSM to be stateless. The signing al= gorithm requires multiple rounds, in the first round, the signer commits to= a value R_i =3D 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 restor= e it from one round to the next even though it may have performed other ope= rations 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.=C2=A0

2) Code signing: The code signing= role is split across two or more signers and MAY permit a signature=C2=A0t= o be created by a quorum smaller than the total number of authorized signer= s (n, t). Signing quorums may prove particularly attractive for open source= projects.

=
I have introdu= ced a new role, of coordinator for the party that manages the process.

Are there additional use case= s that should be considered. That is use cases that raise additional requir= ements. The need to sign blockchains is often raised but that doesn't s= eem to raise additional requirements over code signing.=C2=A0

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg


--
Tony Arcieri
--000000000000d20283059b2d9b61--