Re: [Cfrg] BLS standard draft
Antonio Sanso <asanso@adobe.com> Thu, 21 March 2019 19:01 UTC
Return-Path: <asanso@adobe.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 12CC613159E for <cfrg@ietfa.amsl.com>; Thu, 21 Mar 2019 12:01:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adobe.com
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 NdIGUzkXoqZ7 for <cfrg@ietfa.amsl.com>; Thu, 21 Mar 2019 12:01:05 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770048.outbound.protection.outlook.com [40.107.77.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 742EA1315E4 for <cfrg@irtf.org>; Thu, 21 Mar 2019 12:01:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adobe.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VJe0gf5h5Chhp1gBHnJgcKSaIRlXtbK0ZCIqqGGhado=; b=VmRVntXZANKgd5J6GsBfjFVSwacolk1N67Yl/i/8nDeHfp8Ux09bE/WDuyr7gfSYS28Pjz91tZoPmaoLMW5SJgOWNafDiIo7qIKQnGJVXAilv7cPE1IyhLkU06pG5Y46/q4LGGFYbQG5MdVIzG1toDQPzG7cjAtIvRX0kfWxlaA=
Received: from SN6PR02MB5311.namprd02.prod.outlook.com (52.135.104.21) by SN6PR02MB3997.namprd02.prod.outlook.com (52.135.69.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.14; Thu, 21 Mar 2019 19:01:02 +0000
Received: from SN6PR02MB5311.namprd02.prod.outlook.com ([fe80::2874:55d2:9bd4:825e]) by SN6PR02MB5311.namprd02.prod.outlook.com ([fe80::2874:55d2:9bd4:825e%2]) with mapi id 15.20.1730.013; Thu, 21 Mar 2019 19:01:02 +0000
From: Antonio Sanso <asanso@adobe.com>
To: Sergey Gorbunov <sgorbunov@uwaterloo.ca>, "cfrg@irtf.org" <cfrg@irtf.org>, David Wong <davidwong.crypto@gmail.com>, "ylzhao@fudan.edu.cn" <ylzhao@fudan.edu.cn>, Eric Rescorla <ekr@rtfm.com>
Thread-Topic: [Cfrg] BLS standard draft
Thread-Index: AQHUy62XEGisxLPtX0C6PQYOohMi/qYWqj+A
Date: Thu, 21 Mar 2019 19:01:01 +0000
Message-ID: <9470C30B-93D9-4425-A411-031E0D440B81@adobe.com>
References: <CACnav0oDeJ14LphESnrsD8C1C+4iFByPqp4tfqxGT4hwbe1ucg@mail.gmail.com>
In-Reply-To: <CACnav0oDeJ14LphESnrsD8C1C+4iFByPqp4tfqxGT4hwbe1ucg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.16.0.190211
authentication-results: spf=none (sender IP is ) smtp.mailfrom=asanso@adobe.com;
x-originating-ip: [46.183.103.17]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 014eeaa6-2144-40ba-1103-08d6ae2f8ff3
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:SN6PR02MB3997;
x-ms-traffictypediagnostic: SN6PR02MB3997:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <SN6PR02MB399791FA549C12397BDEFF83D9420@SN6PR02MB3997.namprd02.prod.outlook.com>
x-forefront-prvs: 0983EAD6B2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(39860400002)(136003)(396003)(346002)(366004)(376002)(55674003)(199004)(189003)(8936002)(6506007)(54896002)(6306002)(26005)(606006)(966005)(7736002)(486006)(236005)(68736007)(446003)(786003)(6436002)(99286004)(58126008)(36756003)(229853002)(97736004)(2906002)(86362001)(82746002)(66066001)(66574012)(110136005)(11346002)(8676002)(256004)(6486002)(14454004)(105586002)(76176011)(106356001)(790700001)(71200400001)(478600001)(6512007)(3846002)(33656002)(10090500001)(25786009)(53936002)(6116002)(476003)(2616005)(83716004)(81156014)(316002)(6246003)(102836004)(14444005)(9326002)(2171002)(53546011)(5660300002)(81166006)(186003)(71190400001)(2501003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR02MB3997; H:SN6PR02MB5311.namprd02.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: adobe.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: jxG3LJPkmDRg2C9QBuJ7/YIfaUZl3bOssFOzIVlmWc318d+9gDkKurKGNSxVgNGDFj0QOcQospqywXDk2knn5/a2R1IKlhHbTzO5QCDPY0c/svWEyyWfyusZruFdbxaYQNXmJkPws1E+aiFziMCACthC3RRP6Taeb25F7iZ2brSjIFqi4ihHy+Hv6DQzYEl1W4CZ6VeYVzRRc2H6/+NkHlNR33Dyf3N3/kQlSAhja6EqEC07h8LqtGeEm74OARgNURNh7KwOT2JJeNGaSMPzMKaKBpt7xpV92RlFNA7cU/PcyeAqaHfYNxryXyIsGAIMqTG9uJcSmKfjMDQuHYjS5sWJMrOp5+sbH7wN+AjHGzQOE72fsFwRA2K6WKdaFuszMcqm6fGxYgo6kq5S1wZ9HymPZM6d9AuZ5w4YXvNtqYw=
Content-Type: multipart/alternative; boundary="_000_9470C30B93D94425A411031E0D440B81adobecom_"
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 014eeaa6-2144-40ba-1103-08d6ae2f8ff3
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2019 19:01:01.9970 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR02MB3997
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/SZHabBlxuVk5XnJQD5k-VOMUy_U>
X-Mailman-Approved-At: Fri, 22 Mar 2019 02:50:18 -0700
Subject: Re: [Cfrg] BLS standard draft
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: Thu, 21 Mar 2019 19:01:17 -0000
Hi Sergey, Great work so far. Not quite the same. Just wanted to point out that recently Luca De Feo, Simon Masson, Christophe Petit and myself published a paper that generalizes the BLS construction (employing isogenies). You can find the paper in https://eprint.iacr.org/2019/166.pdf Regards antonio From: Cfrg <cfrg-bounces@irtf.org> on behalf of Sergey Gorbunov <sgorbunov@uwaterloo.ca> Date: Saturday, February 23, 2019 at 8:25 PM To: "cfrg@irtf.org" <cfrg@irtf.org>, David Wong <davidwong.crypto@gmail.com>, "ylzhao@fudan.edu.cn" <ylzhao@fudan.edu.cn>, Eric Rescorla <ekr@rtfm.com> Subject: Re: [Cfrg] BLS standard draft Thanks, David and everyone else for the feedback! We will create a github repository where anyone will be able to view and comment on the latest draft and share the link. In the meantime, please continue sending us feedback by email. Regards, Sergey web<https://cs.uwaterloo.ca/~sgorbuno/> On Sun, Feb 17, 2019 at 3:00 PM <cfrg-request@irtf.org<mailto:cfrg-request@irtf.org>> wrote: Message: 1 Date: Sun, 17 Feb 2019 08:54:36 -0800 From: David Wong <davidwong.crypto@gmail.com<mailto:davidwong.crypto@gmail.com>> To: ??? <ylzhao@fudan.edu.cn<mailto:ylzhao@fudan.edu.cn>> Cc: Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>>, CFRG <cfrg@irtf.org<mailto:cfrg@irtf.org>>, Sergey Gorbunov <sgorbunov@uwaterloo.ca<mailto:sgorbunov@uwaterloo.ca>> Subject: Re: [Cfrg] BLS standard draft Message-ID: <CAK3aN2r9J9ToH6OZPNqUv4vNPx_DqJM+KQC=X=rfHFEkM5hkdg@mail.gmail.com<mailto:rfHFEkM5hkdg@mail.gmail.com>> Content-Type: text/plain; charset="UTF-8" Hi again, I am not sure what the process is. If you have a github repo where we can participate or if you want us to give you feedback here. So here is some feedback from a first read. Feel free to ignore the bits you don't agree with of course. Some common themes were: * Keep in mind that this is for implementations, so remove information that belongs in a whitepaper * Make the RFC timeless (we should be able to read it in 5 years and understand it) * Set things in stone so that the RFC is actionable, don't make it vague. If people want to add to it, extensions and updates are possible later. And here is the more detailed feedback: - abstract: re-write with "what is it?" in mind first, history bits can wait until the introduction. I suggest using developer-friendly terms like "compression" and define aggregation later if the term is needed. Example: BLS is a digital signature scheme with compression properties. With a given set of signatures (sig_1, ..., sig_n) anyone can produce a compressed signature sig_compressed. The same is true for a set of private keys or public keys, while keeping the connection between sets (a compressed public key is associated to its compressed public key). Furthermore, the BLS signature scheme is deterministic, non-malleable, and efficient. Its simplicity and cryptographic properties allows it to be useful in a variety of use-cases, specifically when minimal storage space or bandwidth are required. - intro: - "A signature scheme is a fundamental cryptographic primitive used on the Internet that is used to protect integrity of communication" -> not necessarily used on the internet, and not necessarily for integrity of communications. - "2. Verification requires 2 pairing operations." -> at this point pairing is not defined, and what does that mean for the developer? how does it compare to other signature schemes that do not use pairing? - "we believe the scheme will find very interesting applications" -> too temporal. At some point, it is possible that the scheme will be popular and this sentence will seem out of place. - "the BLS signature scheme is already integrated" -> maybe out of place (as too temporal as well). If not, sort the list by alphabetical order, I think no one will mind that. - "BLS signatures are used for authenticating transactions as well as votes during the consensus protocol" -> I suggest we itemize the different use-cases of BLS (from PKI to blockchain). - section "1.1. Terminology" - "msg" -> I suggest we change that to "message" - "sigma" -> "signature" - "signer/verifier/aggregator" do we need roles for these? Can't we do with just an API ("sign/verify/compress") - "P1" is defined but never seem to be used. Am I missing something? - I suggest we spell "e()" as "pairing()" in the algorithms, and define it here - section "1.2. Signature Scheme Algorithms and Properties" - "A signature scheme comes with" -> "Like most signature schemes, BLS comes with the following API", this way we can leverage the reader's knowledge of other signature scheme. - "The signing algorithm may be deterministic or randomized, depending on the scheme" -> as this is a spec, we need to make a decision here. I think it makes more sense to make it deterministic. - section "1..2.2. Security" -> do we need these security properties in the RFC? It sounds to me like they would belong in a whitepaper instead.. - section "2." - "BLS signatures require pairing-friendly curves" -> I suggest standardizing BLS with a set of curves. Extensions or updates can later add more curves if needed. - "There are two variants of the scheme" -> It'd be nice if the two variants were specified in this document, as they both have use-cases. - "Put ... in G1" -> not clear, rephrase - section "2.1. Preliminaries". I recommend renaming "suite_string" to "domain_separator" and having specific values for it instead of potential values.. (We're standardizing something after all, ideally it should be self-contained) - section "2.4. Verify: Signature Verification" - "4. If r*Gamma != 0, output "INVALID" and stop" -> I had heard a while ago that this membership check was patented for ECDH. Anyone remembers something like this? - section "2.5. Aggregate" - it should be "sigma = E1_to_string(string_to_E1(sigma_1) + ... + string_to_E1(sigma_n))" - you specify verifying aggregates of SAME msg and of DIFFERENT msgs, but only have the aggregate algorithm for SAME msg specified. - section "2.5.3. Implementation optimizations". Two things: - this should be towards the end of the documentation as these are optional recommendations. Perhaps after "security recommendations" or as an appendix - is it really wise to have the standard contain this? Available optimizations may change over time. I've also never seen an RFC talking about optimizations. - section "2.7. Security analysis" -> I don't think this is necessary to have that in the RFC. - section "3.1. Verifying public keys" - define "G2 membership test" - "to prevent rogue key attacks" -> needs a reference - section "3.4. Randomness considerations" needs a citation, for example on ECDSA issues when the nonce is repeated - section "4. Implementation Status". Standards usually don't refer to implementations AFAIK. I imagine this is because their state can change, and new good implementations can arise after the RFC is set in stone. I think this is good to have in the draft though, so perhaps add an indication somewhere that this will be deleted in the final document. - section "6. IANA Considerations". Do we need this? - section "2.6.1. Preliminaries", "In fact, we will pad each substring with 0s so that the length of each substring is a multiple of 8." specify that this is in bits. Cheers, David
- [Cfrg] BLS standard draft Sergey Gorbunov
- Re: [Cfrg] BLS standard draft William Whyte
- Re: [Cfrg] BLS standard draft Michael Scott
- Re: [Cfrg] BLS standard draft david wong
- Re: [Cfrg] BLS standard draft Tony Arcieri
- Re: [Cfrg] BLS standard draft Eric Rescorla
- Re: [Cfrg] BLS standard draft 赵运磊
- Re: [Cfrg] BLS standard draft David Wong
- Re: [Cfrg] BLS standard draft Sergey Gorbunov
- Re: [Cfrg] BLS standard draft John Mattsson
- Re: [Cfrg] BLS standard draft Michael Scott
- Re: [Cfrg] BLS standard draft Sergey Gorbunov
- Re: [Cfrg] BLS standard draft Antonio Sanso
- Re: [Cfrg] BLS standard draft Antonio Sanso
- Re: [Cfrg] BLS standard draft Marek Jankowski