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 E697D1200FB for ; Fri, 3 Jan 2020 15:01:22 -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 F03r9fTr66Ep for ; Fri, 3 Jan 2020 15:01:21 -0800 (PST) Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) (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 60C501200F8 for ; Fri, 3 Jan 2020 15:01:21 -0800 (PST) Received: by mail-ot1-f53.google.com with SMTP id k8so45853400otl.13 for ; Fri, 03 Jan 2020 15:01:21 -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=kTSt2X44kwCBVV1NpaBFyyj+2a05QxZrE94TaEO5LG4=; b=CAo1OwOkg0NqCqjf7gCdkwbpJKKsWiakXZClMM2aoiS6vxObE49QqpeKdKcLE7pd9E uTzGqYHjDMpogpmktXghn0CSdefVtSum3f2Io3X9L9Oly4a03a1etH8VfwqJnJQm0ZfI WTCoQ3AjLtZWAtrM5Cacvpqy6TZ8dAQ1gTV7N9T/6IBINDeB1YpeuuDIwyychk0oqwKN OedLbWB4Y7knfljp3LWVeTlCvsK1019O1l8ZqJvH/bTDYtY4CrCGzCf1Hetq0hF4zgrS EK3tRcAxPc3DSCdDJ+2XQrCrucUCX2bjTtnHu+It9T+CXq7quHcMWHS8TWXFTCskFS7I pqaA== X-Gm-Message-State: APjAAAVoxdBj16Vuo55gixmJWSKSkI2eNOLb89t/NihvNrRXzz/NmFzs afszXjJro3CVJusmzzG3kr/Krvut0WzjECYvvA2IjVfvuUM= X-Google-Smtp-Source: APXvYqwOng7VhOuYNloEkQ+zrq1d0P0HYeOWjnRK8sb26LHZUXJduMhUlO8ml2cukaiXrpr1teh7FZtc2sRyEsR9sh4= X-Received: by 2002:a05:6830:147:: with SMTP id j7mr102791681otp.44.1578092480596; Fri, 03 Jan 2020 15:01:20 -0800 (PST) MIME-Version: 1.0 References: <902BF3DD-4515-4A23-B7B7-0C9D8726E56F@gnunet.org> <0D2BAF97-6A23-4F74-9E20-F56E34ECDF10@gmail.com> <5aaadff7-3752-e49c-a386-194da312e3cd@nthpermutation.com> In-Reply-To: From: Phillip Hallam-Baker Date: Fri, 3 Jan 2020 18:01:11 -0500 Message-ID: To: Michael StJohns Cc: IRTF CFRG Content-Type: multipart/alternative; boundary="000000000000ba8eb3059b44498e" 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 23:01:23 -0000 --000000000000ba8eb3059b44498e Content-Type: text/plain; charset="UTF-8" OK so current state of play: Multi-signatures are simple to create. But think about what it really takes to verify them. We are going to have to specify a signature validation policy which is of course a subset of the security policy problem. I and many others are more than willing to do security policy. But there are folk who reach for a hammer and some oak stakes. The difference between the use cases I am considering and those that result from the Bitcoin use cases is that they are operating under a particular set of constraints and I am not. Specifically, their concern is that they would like Alice Bob and Carol with public keys A, B, C to be able to create ad-hoc compound signatures that can be validated in a single operation under a public key f(A, B, C) where f is a function that can be calculated by any observer. My concern is that Alice Bob and Carol each have the ability to control the creation of a signature under an aggregate signature key Z but do not have the ability to create a signature without the necessary quorum of signers. I do not require that the key Z bear any correspondence to A, B or C at all. Boneh and co are calling the f(A, B, C) signature an aggregate signature and consider it as being distinct from threshold signatures. I believe that is the correct approach and that we should adopt that nomenclature. https://crypto.stanford.edu/~dabo/pubs/papers/aggreg.pdf I am not surprised aggregate signatures require pairing for security. Is it really likely that f(A, B, C) = A + B + C is going to give us the type of security guarantee we are looking for? --000000000000ba8eb3059b44498e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK = so current state of play:

Multi-signatures are simple to create. But think about what it really take= s to verify them. We are going to have to specify a signature validation po= licy which is of course a subset of the security policy problem.

I and many others are more than wil= ling to do security policy. But there are folk who reach for a hammer and s= ome oak stakes.


The difference betw= een the use cases I am considering and those that result from the Bitcoin u= se cases is that they are operating under a particular set of constraints a= nd I am not.=C2=A0

Specif= ically, their concern is that they would like Alice Bob and Carol with publ= ic keys A, B, C to be able to create ad-hoc compound signatures that can be= validated in a single operation under a public key f(A, B, C) where f is a= function that can be calculated by any observer.

My concern is that Alice Bob and Carol each have t= he ability to control the creation of a signature under an aggregate signat= ure key Z but do not have the ability to create a signature without the nec= essary quorum of signers. I do not require that the key Z bear any correspo= ndence to A, B or C at all.


Boneh a= nd co are calling the=C2=A0 f(A, B, C) signature an aggregate signature and consider it as being distin= ct from threshold signatures. I believe that is the correct approach and th= at we should adopt that nomenclature.

https://crypto.stanford.edu/~dabo/pubs/papers/aggreg.pdf=C2=A0= =C2=A0

=
I am not surpr= ised aggregate signatures require pairing for security. Is it really likely= that f(A, B, C) =3D A=C2=A0+ B=C2=A0+ C is going to give us the type of se= curity guarantee we are looking for?=C2=A0
--000000000000ba8eb3059b44498e--