Re: [Cfrg] Call for adoption: Threshold Signatures

Phillip Hallam-Baker <phill@hallambaker.com> Fri, 09 October 2020 15:23 UTC

Return-Path: <hallam@gmail.com>
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 57ECD3A0995 for <cfrg@ietfa.amsl.com>; Fri, 9 Oct 2020 08:23:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 VUtEBSb9fsSe for <cfrg@ietfa.amsl.com>; Fri, 9 Oct 2020 08:23:02 -0700 (PDT)
Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com [209.85.219.179]) (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 323813A0994 for <cfrg@irtf.org>; Fri, 9 Oct 2020 08:23:02 -0700 (PDT)
Received: by mail-yb1-f179.google.com with SMTP id n142so7516093ybf.7 for <cfrg@irtf.org>; Fri, 09 Oct 2020 08:23:02 -0700 (PDT)
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=5j23kWcsJhLMS+73rDF4o+K2PncSSJlHhPC4WWgbFSs=; b=bCPUD4V1heNCdMeWQlxouI55P5g5PndEzYwHKk7kgEa1m5SQs/F4T+NOeiV2q4aeLP 57w8crOg5LIzwkx9esrVL9seYZ6uRCgRYHzUt0sLe/agIP8g2IJntt6Tx8q+NrAD2Z+3 Ch14PPbxRaJLL4TsgIC7Qg5Kqp+Ols/237cQmlZcR0tsKUn0160ItKPxYN6TTsbKH89v Vfzw9g/J4D739sHx0D/0SaYsRBKoeVAKHyJU02IMknsoxbtcMKkNWrHlL49J9/X+ZGCF xIW5NVGAyaTtArZkqpIb7c/aiFD6sdmCV3xqgjmQrTvLJndwbPRth3V6LIwqiI0raGDu d6KA==
X-Gm-Message-State: AOAM531vflnT9xOww2nisWymSVZMr813xxCEbl6NEGpUp9K2pDcioB6C ZZXzmZCpG7VzpCWc6IGpwXTYXpHOuMcotVpuYqU=
X-Google-Smtp-Source: ABdhPJwvPixvC8u8IMUAi1iphrDVE3paYqRM+ZaD7K8maLWuHbHnWHt7bxf/LNXbFvJ9ZZyItTqJpXPw4URczOUl19Q=
X-Received: by 2002:a05:6902:50e:: with SMTP id x14mr18362078ybs.273.1602256981242; Fri, 09 Oct 2020 08:23:01 -0700 (PDT)
MIME-Version: 1.0
References: <CAFDDyk_U_HPS+Mmn4jnBqMUkAzpsB9r1VS4iWeVJYwKRUsUV0g@mail.gmail.com> <20201008211158.GC2207@patternsinthevoid.net> <20201008212000.GI16060@yoink.cs.uwaterloo.ca> <5da6b572636a48f7b03a976af4a0634e@uwaterloo.ca>
In-Reply-To: <5da6b572636a48f7b03a976af4a0634e@uwaterloo.ca>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Fri, 9 Oct 2020 11:22:48 -0400
Message-ID: <CAMm+LwjkrLy8tsqKE3nNKhNkAsT5FyeEyHCc=0QASRokqAdtNQ@mail.gmail.com>
To: Chelsea Komlo <ckomlo@uwaterloo.ca>
Cc: Ian Goldberg <iang@uwaterloo.ca>, "cfrg@irtf.org" <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="00000000000034ba2405b13e86b7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/JHoltCqQKoDAu0_9yoQncXJRuM4>
Subject: Re: [Cfrg] Call for adoption: Threshold Signatures
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Oct 2020 15:23:04 -0000

Just to clarify here. The group should only be working on one threshold
signatures draft for Ed25519 and Ed448. I think we need to decide whether
we are working on threshold first, then decide which bits of threshold and
only then go on to consider how the drafts are structured. We might have
one or three.

There are three separate work pieces that the group may consider:

Threshold Key Generation
Threshold Key Agreement
Threshold Signatures.

Threshold Key Generation can be used for key agreement or signature. How
you are going to use the shares doesn't change how you get them. The only
real difficulty in Threshold Key Agreement is the need to explain how to
obtain and represent the parity information in X25519 and X448.

The biggest leverage we can get from this work is if we can get CPU makers
to put an ECDH core on their CPUs with a key bound during manufacture. And
to do that we really need a story on all three. I strongly suspect that the
origin point for the NIST work was some work that has been going on in the
cyber supply chain area for a decade now.

Having a standard is more than just having a draft with the math. We also
need to specify a new private key format for the key shares, create test
vectors and the like.


On Thu, Oct 8, 2020 at 11:23 PM Chelsea Komlo <ckomlo@uwaterloo.ca> wrote:

> As another of the FROST authors, I am interested in the FROST draft moving
> forward and of course would be involved in working on it.
>
>
> We have an implementation of FROST in Rust; note that this implementation
> will have minor changes as we receive feedback from our presentation at
> SAC [1] and elsewhere.
>
>
> https://git.uwaterloo.ca/ckomlo/frost/
>
> We have also been in discussion with those at NIST who are organizing the
> threshold signatures standardization effort, and will be participating in
> the upcoming workshop.
>
>
> Note that FROST can also be used when keys are generated via a central
> dealer as well as via a DKG (Distributed Key Generation) protocol. We have
> both variants in our implementation, even though we specify only the DKG
> variant.
>
>
> https://git.uwaterloo.ca/ckomlo/frost/-/blob/master/src/keygen.rs
>
>
> <https://git.uwaterloo.ca/ckomlo/frost/-/blob/master/src/keygen.rs>[1]
> https://sac2020.ca/papers.html
>
>
>
>
> ------------------------------
> *From:* Cfrg <cfrg-bounces@irtf.org> on behalf of Ian Goldberg <
> iang@uwaterloo.ca>
> *Sent:* Thursday, October 8, 2020 9:20 AM
> *To:* cfrg@irtf.org
> *Subject:* Re: [Cfrg] Call for adoption: Threshold Signatures
>
> On Thu, Oct 08, 2020 at 09:11:58PM +0000, isis agora lovecruft wrote:
> > Nick Sullivan transcribed 2.9K bytes:
> > > Dear CFRG participants,
> > >
> > > After some active conversations on the mailing list, there seems to be
> > > support for taking on work related to threshold signatures at the CFRG.
> > > This email commences a 3-week call for adoption for the topic of
> "Threshold
> > > Signatures" that will end on October 28th, 2020:
> > >
> > > There are two drafts that have been submitted for consideration on this
> > > topic:
> > > https://datatracker.ietf.org/doc/draft-komlo-frost/
> > > https://datatracker.ietf.org/doc/draft-hallambaker-threshold-sigs/
> > >
> > > Please give your views on the following questions:
> > > a) should this topic be adopted by the CFRG as a work item, and if so
> > > b) should one or both of these documents should be considered as a
> starting
> > > point for this work
> > > c) are you willing to help work on this item and/or review it
> > >
> > > Please reply to this email (or in exceptional circumstances, you can
> email
> > > CFRG chairs directly at cfrg-chairs@ietf.org).
> > >
> > > Thank you,
> > > Nick (for the chairs)
> >
> > > _______________________________________________
> > > Cfrg mailing list
> > > Cfrg@irtf.org
> > > https://www.irtf.org/mailman/listinfo/cfrg
> >
> > Hi all,
> >
> > I would definitely like to see a standarisation of FROST move forward,
> since I
> > already have two clients interested in using it, and I have a Rust
> > implementation in progress here:
> https://github.com/isislovecruft/frost-dalek
> > (If you grep for "[CFRG]" there's a few comments on things that I
> suspect might
> > be useful to specify in a standard.)
> >
> > To that end, I'm happy to help the authors with both working on the
> draft and
> > review.
>
> Multiple implementations already!  That's great!
>
> I suppose I should just say for the record that as one of the authors of
> FROST, I of course am also interested in seeing it move forward, and
> would be involved in working on it.
> --
> Ian Goldberg
> Canada Research Chair in Privacy Enhancing Technologies
> Professor, Cheriton School of Computer Science
> University of Waterloo
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>