Re: [Cfrg] Adoption of threshold drafts by RG

Phillip Hallam-Baker <phill@hallambaker.com> Wed, 30 September 2020 16:08 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 194D33A0B77 for <cfrg@ietfa.amsl.com>; Wed, 30 Sep 2020 09:08:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.645
X-Spam-Level:
X-Spam-Status: No, score=-1.645 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_H3=0.001, RCVD_IN_MSPIKE_WL=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 oMlEFP0b70oG for <cfrg@ietfa.amsl.com>; Wed, 30 Sep 2020 09:08:22 -0700 (PDT)
Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) (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 3369F3A0B5A for <cfrg@irtf.org>; Wed, 30 Sep 2020 09:06:01 -0700 (PDT)
Received: by mail-ot1-f41.google.com with SMTP id m12so2365522otr.0 for <cfrg@irtf.org>; Wed, 30 Sep 2020 09:06:01 -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=XYhloMHVSlt7VJ3j3aEhwZsf8z4vRL9B6LYQfQzuzI4=; b=YrklApwyLts0Cr16Y58PZq0jB2O3WxKHtomIphBYBU73BHFuZLr4KLDkXSOoGW1WTO pPYvMHiCeF48uTvXozsQoe4P+qZY8oSmlXxiLMFcoZ2d59G3JsrzjbW366yd8uVtkTmG FjOfgR95jtdRCgDZUhsoVCxJNvT5eRClsC64DIacZi5JDD3Vvr0Ps5ZxmZNirVlHcFQK Kiaj63fQBISUo3sJ//f/qYxcxZqhdoIFJGJNLNVBaVNyOG5m+/DeNOKZy77S4M8MHpJD zl4Bk/Wq6diAOTu8iWchLoOhTJzUiSJ+xu5ka7spFbZXMNqoAK8W4e/Z4MgAkB4YAvlL 7eGw==
X-Gm-Message-State: AOAM533lnWei2DBItrshYnL8eEXMvCo5dWWr+NQR2s55mrRgBxWinIfv irgwE/iTxx2kU/bbR3EvA3sDCuealRL0PYv+LAg=
X-Google-Smtp-Source: ABdhPJwRhVxh6cuZPaPXN8sUBC736Z6ZX8OPx+8pM4uUSJYTtayG+CFM5bRbfvM7DjKtVODJReezlSiiJh5+0eHztgU=
X-Received: by 2002:a05:6830:168f:: with SMTP id k15mr1925596otr.64.1601481960471; Wed, 30 Sep 2020 09:06:00 -0700 (PDT)
MIME-Version: 1.0
References: <CAMm+Lwj8z0i56G7iTh-z7fZM5z5=B7-x63rVJjuWT7mC1x6x3w@mail.gmail.com> <CACsn0c=9SwWsJ=D_gAStP+gnbfmZkTEokESa0wunpBxaJPvn3g@mail.gmail.com> <CAMm+LwgZ_o28FaUHJ2JdivarT7a3vUdBTRDKa4YLajF93Gn3ag@mail.gmail.com> <76cfa2f5d3c04193aa28d153ce7d4958@uwaterloo.ca> <20200929203843.GY3842@yoink.cs.uwaterloo.ca> <1A7BE772-12CD-4D84-9C24-0A337398FA58@gnunet.org>
In-Reply-To: <1A7BE772-12CD-4D84-9C24-0A337398FA58@gnunet.org>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Wed, 30 Sep 2020 12:05:49 -0400
Message-ID: <CAMm+LwiPGRJiSJwwfLRgF68NcoWYNhFHiSrVJPxF6jS=OfBZ2g@mail.gmail.com>
To: Jeff Burdges <burdges@gnunet.org>
Cc: Ian Goldberg <iang@uwaterloo.ca>, IRTF CFRG <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="0000000000005e417005b08a13cf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/r5pCO0W5TpBPix7tOXoOl7j6XH4>
Subject: Re: [Cfrg] Adoption of threshold drafts by RG
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, 30 Sep 2020 16:08:24 -0000

On Wed, Sep 30, 2020 at 10:52 AM Jeff Burdges <burdges@gnunet.org> wrote:

>
> Phillip,
>
> It’s quite simple and basically free to delinearize the witnesses/nonces
> in a Schnorr multi-signature.
>
> I implemented witnesses delinearization in schnorrkel’s musig way back in
> early January https://github.com/w3f/schnorrkel/commit/fa6c35f832 after
> discussing it with numerous people in Fall 2019.  We’re not actually using
> witnesses delinearization in production right now, but only because our
> wallet folks move slowly.
>
> It works for threshold signatures too of course, so it appears FROST
> adopted roughly the same trick of delinearizing the witnesses in their
> recent version.  If threshold confuse matters then you should consider the
> simpler case of musig plus witnesses delinearization first.
>
> If you want a multi-signer Schnorr protocol then you'll need either some
> form of witnesses delinearization or else some fancy determinism solution
> like MuSig-DN.
>

I did initially consider multi-sig sufficient for pretty much every need.
There are however two requirements where I think threshold is pretty
compelling.

The first is the case where we want to divide private key operations
between an application layer key and a key embedded in an HSM built into a
CPU. Such an HSM cannot be fully trusted when it comes to considering
supply chain issues. I am aware of multiple instances of supply chain
hardware compromise (and no, I am not able to provide references).

The second comes up in fault tolerant systems. If I have a redundant 2-of-3
host configuration for my service, I want the crypto to match. The problem
with multi-sigs is that if one host is compromised, they end up signing an
incorrect sequence. And that is visible to outsiders. Use of threshold
signs allows us to align the crypto with the redundancy configuration.