Re: [CFRG] [Cfrg] Call for adoption: Threshold Signatures

Phillip Hallam-Baker <phill@hallambaker.com> Wed, 04 November 2020 17:28 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 2484F3A13A5 for <cfrg@ietfa.amsl.com>; Wed, 4 Nov 2020 09:28:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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 H_RydmsGsESd for <cfrg@ietfa.amsl.com>; Wed, 4 Nov 2020 09:28:57 -0800 (PST)
Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com [209.85.219.170]) (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 668093A0F0C for <cfrg@irtf.org>; Wed, 4 Nov 2020 09:28:57 -0800 (PST)
Received: by mail-yb1-f170.google.com with SMTP id f140so18712082ybg.3 for <cfrg@irtf.org>; Wed, 04 Nov 2020 09:28:57 -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=wbEGKSW91TnwjPZxAkTD3yJv5Qq4zMweYfrCLLeCek8=; b=MEAi8g8g+KmT7LxgRUvoEUrDJ8G93rd4hbwOwaaKDm5uP0L3S5m+tNdLnSkojO6HPp /LpHFAE7MIbiztJDLQgeOhC/JhBsHJOFe05h2GdkhBDmjj5Ipm2fp/lrTgQzLf/Gaj92 CwhHq7YLyzuNCk+NiPfmPn9G6whoGC50lDGFrF872Nuc321tczf8gGLInnRWCvq+afSE KVek4DjHTuUqS52l0OJDV07JoOIkIrQ9BsC7ao0Z7631uagaiedUU933g9ia7N0c/yoT jZk6H4T3zpxvCbWEvzIaHyyW8AHlS77GaCLo6ULAA2BeCHoC6FFpWgd1yZrt+CZ2wDDC 2ZyA==
X-Gm-Message-State: AOAM531T7TiHXjuevAdHUYUSEGLuIRyuYjWg9kglq/wa9vXzZDFJyc1K AayclH/w9pmAUV7OfmkWXEQP5VhW7h1oW380b+3YWj0X7bj5JQ==
X-Google-Smtp-Source: ABdhPJx5RkpQmFGnVbl69wHmR1b9dvBdw6t1R/+4EQaKPontNwNTjs3LKaUP1Zk/zwhq2GcllBvcxaDmoyjbhxwY8A8=
X-Received: by 2002:a25:e54:: with SMTP id 81mr34252040ybo.56.1604510936297; Wed, 04 Nov 2020 09:28:56 -0800 (PST)
MIME-Version: 1.0
References: <CAFDDyk_U_HPS+Mmn4jnBqMUkAzpsB9r1VS4iWeVJYwKRUsUV0g@mail.gmail.com> <6f7d6904-77dc-4485-9328-00343c209921@www.fastmail.com> <20201102221757.GA2981@patternsinthevoid.net> <CAL02cgSJkptvdzT51ZXC+7CuKWC8J50dMVAJekYOx9VSYjBjUA@mail.gmail.com>
In-Reply-To: <CAL02cgSJkptvdzT51ZXC+7CuKWC8J50dMVAJekYOx9VSYjBjUA@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Wed, 4 Nov 2020 12:28:46 -0500
Message-ID: <CAMm+LwhHYgOj_1pazSkYHnYuW4FKoXEH0ZH233GYLqKbpv=zGw@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
Cc: isis@patternsinthevoid.net, CFRG <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="0000000000006576d205b34b506e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/U720IX9c-AjZJnplNdEs9mgaztA>
Subject: Re: [CFRG] [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: Wed, 04 Nov 2020 17:28:59 -0000

On Mon, Nov 2, 2020 at 5:50 PM Richard Barnes <rlb@ipv.sx> wrote:

> On Mon, Nov 2, 2020 at 5:20 PM isis agora lovecruft <
> isis@patternsinthevoid.net> wrote:
>
>> Christopher Wood transcribed 1.1K bytes:
>> > On Thu, Oct 8, 2020, at 9:33 AM, Nick Sullivan wrote:
>> >
>>
>> > Probably only one. The structure of draft-hallambaker-threshold-sigs as
>> an
>> > extension to RFC8032 is attractive, though I think draft-komlo-frost
>> (and
>> > the related paper) is generally a better starting point, especially
>> given
>> > its assessment of attacks on related schemes such as 2020/945. It also
>> > seems to have plenty of backing implementations and reviews. If we can
>> > specialize it to RFC8032, perhaps with Richard's work as the basis for
>> > that change, then I prefer FROST.
>>
>> Hi Chris,
>>
>> What do you mean by specialising it to RHC8032?  Do you mean literally
>> producing RFC8032 backwards compatible EdDSA signatures using the ed25519
>> and ed448 groups?
>>
>
> I'm not Chris, but that's what I understood him to mean, and I agree with
> Chris that it would be good to have such a specialization.
>

A few points here:

1) My draft is intended as a CONTRIBUTION. People are free to use whatever
parts of it are useful.

2) The FROST draft and my draft have rather different scopes. I am only
specifying a threshold version of RFC8032. The FROST draft is providing a
general tool that can also be applied to secure other Schnorr signatures.
And those parts are also very useful because 99% of the ECDH signatures in
use today are for the NIST curves.

3) Watching the NIST workshop, it is clear to me that if CFRG decides to do
threshold EC signatures, there are going to be more options and more
constraints we need to consider besides those already submitted.

It might well be that we want multiple separate signature documents, one
describing the Meta, one describing that applies to RFC8032 and possibly a
third one applying it to the NIST curves.

4) Signature is the hardest of the ECDH threshold applications. It is also
the one that provides least additional functionality because aggregate
signatures can be used in place of threshold for most applications. It is
however a necessary function for some applications (HSM, fault tolerant
notary services, etc).

5) FROST specifies a DKG that is potentially applicable to Key
Agreement/Encryption. I would like that broken out as a separate module so
we can use it for encryption.

6) The only technical steps required to turn RFC7748 into a threshold
scheme are (1) Specify how to recover the parity of the result from the
Montgomery Ladder and (2) Specify how to encode the parity in the private
key representation for X25519, X2448.

Earlier in this threat, Iain  expressed a concern that we don't slow things
down by considering a broad scope. I don't see that as a risk. Threshold
signatures are going to take exactly as long as they take no matter what
other work is considered. It is the area where the cryptographic
construction involves most risk (getting it wrong can mean disclosure of
the private key, ability to forge signatures) and where there are the most
options.