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

Jeff Burdges <> Wed, 26 February 2020 13:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7CD593A07B3 for <>; Wed, 26 Feb 2020 05:54:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.61
X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id m7Cm0JQG-oxc for <>; Wed, 26 Feb 2020 05:54:18 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 412A03A0433 for <>; Wed, 26 Feb 2020 05:54:17 -0800 (PST)
Received: from [] ( [IPv6:2001:4ca0:2001:42:225:90ff:fe6b:d60]) by (Postfix) with ESMTP id D17C71C00D2 for <>; Wed, 26 Feb 2020 14:58:02 +0100 (CET)
From: Jeff Burdges <>
Content-Type: multipart/signed; boundary="Apple-Mail=_6BB7BDCD-AD17-4C5C-AD86-6A8C0B1FBCC4"; 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 14:54:03 +0100
References: <>
In-Reply-To: <>
Message-Id: <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-vrf-06.txt
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: Wed, 26 Feb 2020 13:54:26 -0000

We’ve had an internal discussion about whether VRF proving should be called VRF signing.  I think existing literature is rather evenly divided on this point, well depending upon how far back you go.  ;)

I think “prove” gets used when authors from the theory side want to stress the similarity with hash functions.  Implementors write “sign” to stress that their VRF either works like a signature scheme, or even was made miss-use resistant similarly to signature schemes, ala

I personally use dleq_prove for Schnorr DLEQ proofs because the absence of a key pair makes them tricky to use correctly, but use vrf_sign for Schnorr VRFs because done well they wind up as missuse resistant as a Schnorr signature.  I write VRF signature and VRF output in protocol descriptions.

There is another question about the relationship between the various VRF properties and the signature scheme security assumptions, although not sure if this draft is the place to make the distinctions and prove any equivalences.  Intuitively, you do want a scheme that is both a VRF and a signature more often than this draft lets on.

Also, VRFs based on Schnorr DLEQ proofs should include an extra message field because applications need to authenticate the message that carries the VRF output, like a block in Ouroboros Praos.  We needed this extra message field in the ring VRF in our new Sassafras SSLE protocol, either that or make annoying usage of FO.  You can do this with delinearization, but that’s less efficient.


> On 11 Feb 2020, at 18:13, wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Crypto Forum RG of the IRTF.
>        Title           : Verifiable Random Functions (VRFs)
>        Authors         : Sharon Goldberg
>                          Leonid Reyzin
>                          Dimitrios Papadopoulos
>                          Jan Vcelak
> 	Filename        : draft-irtf-cfrg-vrf-06.txt
> 	Pages           : 43
> 	Date            : 2020-02-11
> Abstract:
>   A Verifiable Random Function (VRF) is the public-key version of a
>   keyed cryptographic hash.  Only the holder of the private key can
>   compute the hash, but anyone with public key can verify the
>   correctness of the hash.  VRFs are useful for preventing enumeration
>   of hash-based data structures.  This document specifies several VRF
>   constructions that are secure in the cryptographic random oracle
>   model.  One VRF uses RSA and the other VRF uses Eliptic Curves (EC).
> The IETF datatracker status page for this draft is:
> There are also htmlized versions available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> Cfrg mailing list