Re: [Cfrg] Schnorr multisignatures on Ed448 and Ed25519

Taylor R Campbell <campbell+cfrg@mumble.net> Tue, 07 May 2019 22:03 UTC

Return-Path: <campbell@mumble.net>
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 A4396120236 for <cfrg@ietfa.amsl.com>; Tue, 7 May 2019 15:03:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 Uya7zVLRbpWh for <cfrg@ietfa.amsl.com>; Tue, 7 May 2019 15:03:33 -0700 (PDT)
Received: from jupiter.mumble.net (jupiter.mumble.net [74.50.56.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1E14120086 for <cfrg@irtf.org>; Tue, 7 May 2019 15:03:32 -0700 (PDT)
Received: by jupiter.mumble.net (Postfix, from userid 1014) id F422A60322; Tue, 7 May 2019 22:03:30 +0000 (UTC)
From: Taylor R Campbell <campbell+cfrg@mumble.net>
To: Phillip Hallam-Baker <phill@hallambaker.com>
CC: cfrg@irtf.org
In-reply-to: <CAMm+LwgA6Z4R+SpFhxWrgfh8LYP7GarCqAASj+j+BMCG+CEt3g@mail.gmail.com> (phill@hallambaker.com)
Date: Tue, 07 May 2019 22:03:29 +0000
Sender: Taylor R Campbell <campbell@mumble.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <20190507220330.F422A60322@jupiter.mumble.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/-D75VkoPI9mOAQX3E26P14g7VnQ>
Subject: Re: [Cfrg] Schnorr multisignatures on Ed448 and Ed25519
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: Tue, 07 May 2019 22:03:36 -0000

> Date: Tue, 7 May 2019 17:45:59 -0400
> From: Phillip Hallam-Baker <phill@hallambaker.com>
> 
> Are there any academics who are interested in doing this analysis and
> producing a draft that either explains a safe means of creating an Ed448
> signature using private keys a, b such that they can be verified with key
> A+B or tells us why this is a bad idea?

In the usual naive way to do this, if Alice publishes A = a*G as her
public key, Bob can publish B - A for B = b*G as his public key and
thereby unilaterally sign messages that pass verification under the
public key A + (B - A) = B.

There's been a spate of papers in the past couple of years on
threshold signature schemes, some (all?) of which avoid this at some
cost, including CoSi, MuSig, and mBCJ.  There was an internet-draft,
draft-ford-cosi-cfrg, but it didn't seem to go anywhere.

The problem seems to be complicated, but it would be nice for the
internet to have a good standard threshold signature scheme -- ideally
without changes to verifiers -- and to get away from foolhardy
applications of secret-sharing that inherently leave some party with
unilateral signing power at some stage.