Re: [Cfrg] I-D Action: draft-irtf-cfrg-vrf-06.txt

Jeff Burdges <burdges@gnunet.org> Wed, 26 February 2020 11:31 UTC

Return-Path: <burdges@gnunet.org>
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 19C483A0832 for <cfrg@ietfa.amsl.com>; Wed, 26 Feb 2020 03:31:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.954
X-Spam-Level:
X-Spam-Status: No, score=-0.954 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FILL_THIS_FORM_SHORT=0.001, KHOP_HELO_FCRDNS=0.276, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, 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 S8yAqmyCLhUb for <cfrg@ietfa.amsl.com>; Wed, 26 Feb 2020 03:31:43 -0800 (PST)
Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.in.tum.de [131.159.0.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DBFB3A082C for <cfrg@irtf.org>; Wed, 26 Feb 2020 03:31:42 -0800 (PST)
Received: from [127.0.0.1] (sam.net.in.tum.de [IPv6:2001:4ca0:2001:42:225:90ff:fe6b:d60]) by sam.net.in.tum.de (Postfix) with ESMTP id AA67C1C00D2; Wed, 26 Feb 2020 12:35:31 +0100 (CET)
From: Jeff Burdges <burdges@gnunet.org>
Message-Id: <ED16451C-1EF7-4C82-BABC-013D8A5A173A@gnunet.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_707BB47E-53CD-437C-BEA2-A276F184DAC3"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Wed, 26 Feb 2020 12:31:32 +0100
In-Reply-To: <8e5daf3c-ec41-5f08-da28-0a6f9a4827cc@digitalbazaar.com>
Cc: cfrg@irtf.org
To: Manu Sporny <msporny@digitalbazaar.com>
References: <158144123837.20027.8192705210389452666@ietfa.amsl.com> <CAHZ6D0tcdwvT5QwbjBDGXqud5yMitp8CB-oTQuqZoLuCQAC=Rw@mail.gmail.com> <8e5daf3c-ec41-5f08-da28-0a6f9a4827cc@digitalbazaar.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/Dz3ug2aHyWb7bDg_t_xGNdcmswk>
Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-vrf-06.txt
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, 26 Feb 2020 11:31:46 -0000

Almost all proof-of-staake blockchain protocols require VRFs for various purposes, including driving random beacons, leading block production or BFT agreement processes, or selecting validation assignments in sharding situations.

Identity schemes come in many flavours, but they should be built on ring or group VRFs, or maybe similar constructions like linkable ring signatures, whenever they must (1) prevent Sibel attacks, and (2) be useable for a wide variety of purposes, and (3) do not trust some issuer with user privacy.

In essence, Sibel protections require some uniqueness per key holder, but being general purpose means that uniqueness must differ across domains to whom the key holder identifies themselves, so that unique amounts to a VRF output, and you need ring or group to hide what key generates it.

There are SNARK constructions that drop (3) and maybe avoid key pairs, making them not "VRF signatures” like described in this draft, but they still possess roughly the same sort of uniqueness, etc. definitions from section 3 of this craft.

Jeff





> On 11 Feb 2020, at 22:50, Manu Sporny <msporny@digitalbazaar.com> wrote:
> 
> On 2/11/20 12:31 PM, Leonid Reyzin wrote:
>> This most recent update to the VRF draft consists of minor clarifications.
> 
> Hi Leo, Sharon, Jan, and Dimitris,
> 
> I've been following this work for years now and I still don't know why
> VRFs are useful. Every time you publish a new draft, I got out and scour
> the Web for an easily readable description of a use case that is solved
> by the use of a VRF and end up reading things like:
> 
> "It is a pseudo-random function that provides publicly verifiable proofs
> of its outputs' correctness."
> 
> "VRFs are useful for preventing enumeration of hash-based data structures."
> 
> "VRFs ... useful for providing a 1:1 mapping of low entropy inputs (e.g.
> names, email addresses, phone numbers) to some random values which can
> be committed to in advance, e.g. through a timestamping service such as
> a transparency log."
> 
> I say this as someone that spends quite a bit of time reading IETF
> cryptography specs and writing specifications that directly utilize
> IETF/CFRG cryptography specs (at IETF and W3C).
> 
> Can you please add a few real world use cases where one would use a VRF?
> Are they useful for committing values on a public blockchain in a
> privacy preserving manner? If so, what sorts of values? Are they useful
> when voting? Are they useful for distributed gaming scenarios? Some
> concrete uses would be more helpful than the overly general text in the
> current spec.
> 
> -- manu