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 53AF512008F for ; Fri, 3 Jan 2020 09:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.397 X-Spam-Level: X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 mL8sDze-SY2A for ; Fri, 3 Jan 2020 09:08:49 -0800 (PST) Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com [209.85.210.47]) (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 35E071200DE for ; Fri, 3 Jan 2020 09:08:49 -0800 (PST) Received: by mail-ot1-f47.google.com with SMTP id p8so25468332oth.10 for ; Fri, 03 Jan 2020 09:08:49 -0800 (PST) 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=to+dPIPf/f95JpnXTX75AOXRiBASE6umhGfuAjEaeBw=; b=GnP9iB3wFFUrtY18oiXCzmlC7qmxhWXZssDmUCS9uXLPRV27uK68hTrE501AJ3mulV 5ehS2PdEOjIj4HkzP9IXoQmKPV0i8IBbuHtqKXrMn5hZ2ZZZFc6KfLo+F4kyuznkwzxm dhOuqkexaWma2X+gib230iO8qHpclhKxJMO/gvzQ5vySq3St4tIC0sZwUKhOmSilEG7A qJMSuGWpiw7Q5z25dpq3q5XsNK1F4EW3g3WuI9gPG7sDFY/KxdOPC5NrHG11yW5jh+IE 9BDMlxiIIu3MjswpeLQnWDQFWcQUW/YUidML4e3CzgAP1F5FntNX9s/HuWk8xzStt8iK 4aDw== X-Gm-Message-State: APjAAAWMa+hAZmzv0k1xELlgFZerYKR4llTWgq6lk20oiYVblhJagRQU cHJcIRtqaG6zd9l3KrJY7/XtZrg+sowx07vODUU= X-Google-Smtp-Source: APXvYqwvLN1uad19N09WnexOZrqt92qaV7giDHTUxuBSyRh0eNkSMS2pkXnlxUBG26VqE45uLn/X7QR4fZPufk27BX8= X-Received: by 2002:a05:6830:1481:: with SMTP id s1mr82697328otq.66.1578071328448; Fri, 03 Jan 2020 09:08:48 -0800 (PST) MIME-Version: 1.0 References: <902BF3DD-4515-4A23-B7B7-0C9D8726E56F@gnunet.org> In-Reply-To: From: Phillip Hallam-Baker Date: Fri, 3 Jan 2020 12:08:39 -0500 Message-ID: To: Tony Arcieri Cc: Bill Cox , IRTF CFRG Content-Type: multipart/alternative; boundary="000000000000f66693059b3f5c94" 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: Fri, 03 Jan 2020 17:08:50 -0000 --000000000000f66693059b3f5c94 Content-Type: text/plain; charset="UTF-8" On Fri, Jan 3, 2020 at 11:42 AM Tony Arcieri wrote: > On Fri, Jan 3, 2020 at 10:04 AM Phillip Hallam-Baker < > phill@hallambaker.com> wrote: > >> At this point, I think we need to focus on making X25519/448 and >> Ed25519/448 the basis for the next gen of security products. It took about >> five years from AES being announced as a winner for it to become the new >> normal. >> > > Given your stated goals of a multisignature which can work for both > developers and things like HSMs and cloud KMS services, and code signing > systems only supporting a single signature as opposed to threshold > signature sets, I think it's worth questioning whether Ed25519 signatures > are the right tool for the job. > > I think draft-boneh-bls-signature might be a better fit as it supports > offline aggregation. This means HSMs/KMS systems do not need to participate > in an interactive protocol to produce a signature. It also facilitates > offline/"airgapped" codesigning (using e.g. hardware tokens). > They may well be more convenient if the number of signers is greater than two. For the case where n=2 and the coordinator is one of the parties, Ed25519 is fine. BLS requires protocol designers like myself to get comfortable with an entirely new mathematical construct. That is a much bigger ask than you seem to think. Rather than seeing threshold variants of Ed25519 as competing with BLS, you should consider the possibility that acceptance and use of Threshold Ed25519 is likely to be a necessary pre-condition to considering BLS type signatures at all. > An interactive signing protocol where all of the participants must be able > to reach a central online "broker" in order to produce a multisignature > (and also all be online at the same time) is an onerous requirement, as > opposed to one where each system can produce a signature and they can be > retroactively aggregated. > If a device isn't online, it is not communicating. If it is not communicating it is hardly going to need a threshold signature scheme capable of supporting a huge value of n. People are always positing central control as a potential source of unreliability which is rather odd as in my experience, peer-peer systems are vastly more fragile in practice. --000000000000f66693059b3f5c94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jan 3, 2020 at 11:42 AM Tony Arcieri <bascule@gmail.com> wrote:
=
On Fri, Jan 3, 2020 at 10:04 AM Phillip H= allam-Baker <= phill@hallambaker.com> wrote:
At this point, I think we need to f= ocus=C2=A0on making X25519/448 and Ed25519/448 the basis for the next gen o= f security products. It took about five years from AES being announced as a= winner for it to become the new normal.=C2=A0

Given your stated goals of a multisignature which can= work for both developers and things like HSMs and cloud KMS services, and = code signing systems only supporting a single signature as opposed to thres= hold signature sets, I think it's worth questioning whether Ed25519 sig= natures are the right tool for the job.

I think draft-boneh-bls-signatu= re might be a better fit as it supports offline aggregation. This means HSM= s/KMS systems do not need to participate in an interactive protocol to prod= uce a signature. It also facilitates offline/"airgapped" codesign= ing (using e.g. hardware tokens).

They may well be more c= onvenient if the number of signers is greater than two. For the case where = n=3D2 and the coordinator is one of the parties, Ed25519 is fine.

BLS requires protocol designers li= ke myself to get comfortable with an entirely new mathematical construct. T= hat is a much bigger ask than you seem to think.

Rather than seeing thresho= ld variants of Ed25519 as competing with BLS, you should consider the possi= bility that acceptance and use of=20 Threshold=20 Ed25519 is likely to be a necessary pre-condition to considering BLS type s= ignatures at all.=C2=A0

=C2=A0
An interactive signi= ng protocol where all of the participants must be able to reach a central o= nline "broker" in order to produce a multisignature (and also all= be online at the same time) is an onerous requirement, as opposed to one w= here each system can produce a signature and they can be retroactively aggr= egated.

If a device isn't online, it is not com= municating. If it is not communicating it is hardly going to need a thresho= ld signature scheme capable of supporting a huge value of n.

People are always positing centra= l control as a potential source of unreliability which is rather odd as in = my experience, peer-peer systems are vastly more fragile in practice.=C2=A0=
--000000000000f66693059b3f5c94--