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 F10CE131FFB for ; Wed, 26 Jul 2017 04:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 VYshFKKrnkPa for ; Wed, 26 Jul 2017 04:42:53 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 454BC132006 for ; Wed, 26 Jul 2017 04:42:53 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id m88so57929194iod.2 for ; Wed, 26 Jul 2017 04:42:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wKuos3xs8sP15YWadbD1gSVAX6cwcMDB6a99GeWlMfA=; b=J5hXqGNTSjDzkUY7ZwCUByAHZKHhqvkXeBSWN2fN3jEUe/NnuPzH6AWrQFhWNQCBRn XfRcx+vBG6lsRtEWXHxTJtbMFoor3giiOZc2ScTuGDbwlGUumg/uSk1KRjI2Ljhkw4bt TdLW4MsI90E2QAF1E/hJ85dcXQpUhLxYnCdTMafI9fX1yaCAHZBoaPbIaDROhRiRbk1I WdS+q2U1kZEhEz2b+tO/QhQTTXIxlnVBPkFcOibY1wZgHK4RPdeNxbOeQQPOac8BQ6U2 bd+9Dt1/JDiBh7OnM9ME7finzH8liWdNfk6i3Mp12gq/16YK/t0HZOIiC+H/CltPOrph HqeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wKuos3xs8sP15YWadbD1gSVAX6cwcMDB6a99GeWlMfA=; b=tJ3g6+ubPznAtWI0gPZ6FTwPMWAKbGYL+twXIFSXVTdQvvCnXvKg4qfWEv2WXrdo8V /ML3xpegsW8bvmW3uwfwbKdS2Tz+mD68RgdzmWndVy7lm9oBQ2nCgOjNLZEp/RTAPwQO 8ILiqKny9Sa+JenMNYfultq/P4HnL8GS7drhJFHhFvFdvENGeA3BHHS6hSAWDZHgzmv2 SBqZ+DzLDiMAjDFGduzo+Z7A0BQQXNBNMRaQkoHNUnW1BjO1gyAh0aJJKXQrqk4mfB9M 0Zhcv7gtGSmQl/5KrPXtYvhloQA7qzAtdhqK7k5wBdu9QZ9yAe8kEaHrXDCwTfp6RBAz 3/bQ== X-Gm-Message-State: AIVw110krVIq23jBGmGCORlCHXv83plkmEaLIhR3c+Yi067anJ7DFFv+ 4ARNN0T5gp2T/LPB3yrMQBIVbCOhZA== X-Received: by 10.107.131.81 with SMTP id f78mr622260iod.141.1501069372517; Wed, 26 Jul 2017 04:42:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.39.83 with HTTP; Wed, 26 Jul 2017 04:42:11 -0700 (PDT) In-Reply-To: References: <810C31990B57ED40B2062BA10D43FBF501B63B22@XMB116CNC.rim.net> <20170721163204.8573013.1016.15939@blackberry.com> From: Sharon Goldberg Date: Wed, 26 Jul 2017 14:42:11 +0300 Message-ID: To: Thomas Garcia Cc: Dan Brown , "jan@ns1.com" , "cfrg@irtf.org" , Dimitrios Papadopoulos , Leonid Reyzin Content-Type: multipart/alternative; boundary="001a113ecb70bb7422055536f20c" Archived-At: Subject: Re: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 11:42:57 -0000 --001a113ecb70bb7422055536f20c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Thomas, 1. It seems that one of the properties that you are interested that the VRF > will have is determinism. On the other hand, the EC-VRF value is dependen= t > on the choice of some random number k. How are these two facts compatible= ? > Am I missing something? > We require determinism from the VRF hash output, which is obtained from the VRF proof via the "proof2hash" function. The EC-VRF proof has 3 values: gamma, c, s Values c and s depends on the choice of random number k But value gamma does not depend on k. We get determinism because the VRF hash output (derived using "proof2hash") depends only on gamma, but not on c and s. Slide 28 from my CFRG presentations gives a pictorial explanation of this: http://www.cs.bu.edu/~goldbe/papers/VRF_ietf99_print.pdf 2. The value c calculated in EC-VRF is only 128 bits long for Ed25519. In > normal usage of Ed25519 the signature uses the full length of the hash > output. Doesn't this expose the signature to collision attacks? > > No. We worked this out in our proofs of security. Section B.2.1 of this paper explains why this works. https://eprint.iacr.org/2017/099.pdf Thanks, Sharon > Thank you for your comments. Indeed, VRFs have been around since 1999. >> They are really "verifiable PRFs" but the name is by now standard in the >> crypto literature, and changing it will cause more confusion than keepin= g >> it. >> >> In terms of the VRF's security properties, there are three: uniqueness, >> collision resistance, and pseudorandomness. These are defined in our dra= ft ( >> https://tools.ietf.org/html/draft-goldbe-vrf-01#section-3). >> >> How VRFs prevent dictionary attacks: a public hash is subject to a >> dictionary attack because, given the output, an adversary can evaluate t= he >> hash on different inputs and see what hits the outputs. In a VRF, the >> adversary can't evaluate the hash on different inputs. >> >> You say it's not surprising that "random oracle model proof can prove th= e >> output of a hash to be random". But actually, the output of a hash is NO= T >> random if the input and the hash function are known. This is because the >> output of a hash is deterministic (every input maps to a unique output). >> That's exactly what enables dictionary attacks. This is in contrast to a >> VRF, where the output is (pseudo)random even given knowledge of the inpu= t. >> Only once the VRF proof is given, does the VRF output stop looking rando= m. >> Note that random oracles are not essential for VRFs, and non-random-orac= les >> constructions exist (but are less efficient than what we propose to >> standardize). >> >> As far as use cases, here are a few: >> >> In the NSEC5 use case for DNSSEC, you have sensitive data (domain names) >> and you sign consecutive pairs of hashes of domain names in order to be >> able to prove absence of a name. If you just use standard hashing, whene= ver >> signed hash values are disclosed, your sensitive data is subject to >> dictionary attacks. VRFs solve that problem, and sensitive names don't h= ave >> to be disclosed at all. More details are in https://eprint.iacr.org/201 >> 7/099.pdf >> >> In CONIKS (also Google Key Transparency, Signal secure messaging, Yahoo! >> Coname) you also have some sensitive data (user names) that are put into= a >> Merkle-like authenticated data structure. If you just use standard hashi= ng, >> whenever hash values are disclosed, sensitive data is subject to diction= ary >> attacks. If you use VRFs, sensitive data again can be disclosed only on = an >> as-needed basis. More details are in https://eprint.iacr.org/2014/ >> 1004.pdf. >> >> In a cryptocurrency use case, you wish perform a coin flip that is >> deterministic and provably correct, but cannot be done by just anyone. >> More details are in https://people.csail.mit.ed >> u/nickolai/papers/gilad-algorand-eprint.pdf and possibly other >> cryptocurrency papers. >> >> Bryan Ford mentioned an additional usecase at the mic on Tuesday: >> distributed password protection protocols >> >> Many of these use case are already putting VRFs into production use (esp= . >> the CONIKS one). You can see a list of the various implementations we h= ave >> found in the "implementation status" section of our draft. One of the >> reasons we think this spec is so important is that we found flaws in >> several of the implementations that can be used to trivially break >> uniqueness. (See eg: https://github.com/google/ >> keytransparency/issues/567) >> >> Thanks, >> Sharon >> >> On Fri, Jul 21, 2017 at 7:32 PM, Dan Brown >> wrote: >> >>> Answering myself below: VRFs have been around since 1999, so are not so >>> new. =E2=80=8EStill don't like the name, and still have trouble seeing= the value. >>> >>> *From: *Dan Brown >>> *Sent: *Tuesday, July 18, 2017 2:29 PM >>> *To: *Sharon Goldberg; cfrg@irtf.org >>> *Cc: *jan@ns1.com; Leonid Reyzin; Dimitrios Papadopoulos >>> *Subject: *Re: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions >>> >>> Hi Sharon and CFRG, >>> >>> >>> >>> On VRFs, my uncertain comments to consider at your leisure: >>> >>> >>> >>> Is it fair to say VRFs are relatively new? If so, then maybe a little >>> more caution is needed about their use. It seems a tad hasty that it i= s >>> being used already. >>> >>> >>> >>> To me, it seems that VRFs are basically signatures, with an extra >>> feature. My concern is that this extra feature might get overused, bef= ore >>> it is thoroughly reviewed. >>> >>> >>> >>> It is unsurprising to me that random oracle model proof can prove the >>> output of a hash to be random. My intuitive concern is that at least >>> informally, this is kind of circular. Hashes often have some >>> non-random-ish properties that might affect the extra security (over >>> signatures) that VRFs are aiming for. I guess I would much prefer a pr= oof >>> saying if the hash has (well-studied) properties XYZ, then your >>> construction are VRFs. (Maybe you have this already? If so, then tell= me >>> so.) >>> >>> >>> >>> Since, VRFs require sending the =E2=80=9Cproofs=E2=80=9D on the wire, I= find it hard to >>> see how it could be used to prevent dictionary attacks. I assume that = you >>> are saying the proofs must be encrypted when one needs to avoid diction= ary >>> models? I suppose all the details are there in I-D and papers, but for >>> now, I am confused about the threat model (which parties have keys, etc= ., >>> if they require a secure channel and mutual trust, why just use plain o= ld >>> hash,=E2=80=A6). To resist dictionary attacks, were already have PAKEs = and >>> PBHashing. Now this? >>> >>> >>> >>> Finally, on a bikeshed-coloring note, I object to the name =E2=80=9Cver= ifiable >>> random function=E2=80=9D, on several grounds. >>> >>> >>> >>> 1. It is not a function. It is at least four functions, keygen, >>> sign, verify, and hashify. >>> 2. If you make it into a keyed function F_sk(m), as in >>> prooftohash(sign_sk(m)), it is not verifiable. >>> 3. Verification requires the intermediate proof, which is certainly >>> not even pseudorandom (it is easy to distinguish valid signatures fr= om >>> random). >>> 4. It is pseudorandom, not random. (The keys are random, but many >>> crypto has keys, without having =E2=80=9Crandom=E2=80=9D in its name= : encryption, MAC, >>> signatures, key exchange, =E2=80=A6, they also don=E2=80=99t verifia= ble or random in their >>> names either.) >>> 5. The similar phrase =E2=80=9Cverifiably random=E2=80=9D, albeit as= a misnomer, has >>> past precedents, see NIST P-256 and Brainpool, etc. When I see VRF,= I >>> think a function, that aims to VR in that sense, and great, now we c= an >>> improve on Brainpool, etc. >>> 6. =E2=80=9CRandom function=E2=80=9D should be reserved for the idea= l random mapping >>> concept, for example, as studied by Flajolet-Odlyzko (ok they only s= tudied >>> the case of equal size domain and range). The random oracle model, = is the >>> idea of approximating this ideal, etc. An actual approximation shou= ld not >>> be name as the ideal (sorry, I=E2=80=99m kind of repeating my point = 4). >>> >>> >>> >>> Please forgive the fact that my comments above are not very constructiv= e >>> (or if the tone is wrong). This is a new topic for me, so I am relucta= nt >>> too many suggestions. Nonetheless, I suggest (0) waiting a little, (1)= a >>> non-random-oracle security proof (if you don=E2=80=99t have it yet), (2= ) re-naming >>> the scheme to something like re-hashable (or digestible) signatures (an= d >>> re-name the various parts, i.e. proof -> signature, etc.). >>> >>> >>> >>> Best regards, >>> >>> >>> >>> Dan >>> >>> >>> >>> >>> >>> *From:* Cfrg [mailto:cfrg-bounces@irtf.org] *On Behalf Of *Sharon >>> Goldberg >>> *Sent:* Wednesday, July 12, 2017 5:42 AM >>> *To:* cfrg@irtf.org >>> *Cc:* jan@ns1.com; Dimitrios Papadopoulos ; Leonid >>> Reyzin >>> *Subject:* [Cfrg] draft-goldbe-vrf: Verifiable Random Functions >>> >>> >>> >>> Dear CFRG, >>> >>> I'm presenting at next week's meeting on Verifiable Random Functions. A >>> VRF is the public-key version of keyed cryptographic hash. Only the hol= der >>> of the VRF secret key can compute the hash, but anyone with the public = key >>> can verify it. VRFs can be used to prevent dictionary attacks on >>> hash-based data structures, and have applications to key transparency >>> (CONIKS), DNSSEC (NSEC5), and cryptocurrencies (Algorand). >>> >>> In advance of the meeting, please see: >>> >>> 1) Our substantially updated -01 draft: >>> https://datatracker.ietf.org/doc/draft-goldbe-vrf/ >>> >>> 2) Our project page, with links to various VRF implementations: >>> https://www.cs.bu.edu/~goldbe/projects/vrf >>> >>> Comments welcome. Thanks, >>> >>> Sharon >>> >>> -- >>> Sharon Goldberg >>> Computer Science, Boston University >>> http://www.cs.bu.edu/~goldbe >>> >> >> >> >> -- >> --- >> Sharon Goldberg >> Computer Science, Boston University >> http://www.cs.bu.edu/~goldbe >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg >> >> > --=20 --- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe --001a113ecb70bb7422055536f20c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Thomas,

1. It seems that one of the properties that you are inter= ested that the VRF will have is determinism. On the other hand, the EC-VRF = value is dependent on the choice of some random number k. How are these two= facts compatible? Am I missing something?
We require determinism from the VRF hash output, which is obtai= ned from the VRF proof via the "proof2hash" function.
<= br>
The EC-VRF proof has 3 values: gamma, c, s
Values c= and s depends on the choice of random number k
But value gamma d= oes not depend on k.

We get determinism because th= e VRF hash output (derived using "proof2hash") depends only on ga= mma, but not on c and s.
=C2=A0
Slide 28 from my CFRG p= resentations gives a pictorial explanation of this:

2. The value= c calculated in EC-VRF is only 128 bits long for Ed25519. In normal usage = of Ed25519 the signature uses the full length of the hash output. Doesn'= ;t this expose the signature to collision attacks?

No. We worked this out in our proofs of security.=C2=A0= Section B.2.1 of this paper explains why this works.

<= div>https://eprint.iacr.or= g/2017/099.pdf

Thanks,
Sharon

=C2=A0
Thank you for your comments. Indeed, VRFs have been around since 1999= . They are really "verifiable PRFs" but the name is by now standa= rd in the crypto literature, and changing it will cause more confusion than= keeping it.

In terms of the VRF's security properties, there are t= hree: =C2=A0uniqueness, collision resistance, and pseudorandomness. These a= re defined in our draft (http= s://tools.ietf.org/html/draft-goldbe-vrf-01#section-3).=C2=A0

How VRFs prevent dictio= nary attacks: a public hash is subject to a dictionary attack because, give= n the output, an adversary can evaluate the hash on different inputs and se= e what hits the outputs. In a VRF, the adversary can't evaluate the has= h on different inputs.=C2=A0

You say it's not surprising that "= ;random oracle model proof can prove the output of a hash to be random"= ;. But actually, the output of a hash is NOT random if the input and the ha= sh function are known. This is because the output of a hash is deterministi= c (every input maps to a unique output). That's exactly what enables di= ctionary attacks. This is in contrast to a VRF, where the output is (pseudo= )random even given knowledge of the input. Only once the VRF proof is given= , does the VRF output stop looking random. Note that random oracles are not= essential for VRFs, and non-random-oracles constructions exist (but are le= ss efficient than what we propose to standardize).

As far as use cases,= here are a few:=C2=A0

In the NSEC5 use case for DNSSEC, you have sensi= tive data (domain names) and you sign consecutive pairs of hashes of domain= names in order to be able to prove absence of a name. If you just use stan= dard hashing, whenever signed hash values are disclosed, your sensitive dat= a is subject to dictionary attacks. VRFs solve that problem, and sensitive = names don't have to be disclosed at all. More details are in=C2=A0https://eprin= t.iacr.org/2017/099.pdf

<= /div>
In CONIKS (also Google Key Transparenc= y, Signal secure messaging, Yahoo! Coname) you also have some sensitive dat= a (user names) that are put into a Merkle-like authenticated data structure= . If you just use standard hashing, whenever hash values are disclosed, sen= sitive data is subject to dictionary attacks. If you use VRFs, sensitive da= ta again can be disclosed only on an as-needed basis. More details are in = =C2=A0h= ttps://eprint.iacr.org/2014/1004.pdf.

In a cryptocurrency use = case, you wish perform a coin flip that is deterministic and provably corre= ct, but cannot be done by just anyone.=C2=A0 More details are in=C2=A0https://people.csail.mit.edu/nickolai/papers/gila= d-algorand-eprint.pdf=C2=A0and possibly other cryptocurrency paper= s.

Bryan Ford mentioned an additional usecase at the mic on Tuesday: di= stributed password protection protocols

Many of these use case are alre= ady putting VRFs into production use (esp. the CONIKS one).=C2=A0 You can s= ee a list of the various implementations we have found in the "impleme= ntation status" section of our draft.=C2=A0 One of the reasons we thin= k this spec is so important is that we found flaws in several of the implem= entations that can be used to trivially break uniqueness. =C2=A0(See eg:=C2= =A0https://github.com/google/keytransparency/issues/567)<= /div>

Thanks,
Sharon=C2=A0

On Fri= , Jul 21, 2017 at 7:32 PM, Dan Brown <danibrown@blackberry.com&= gt; wrote:
Answering myself below: VRFs have been around since 1999, so are not so new= . =C2=A0=E2=80=8EStill don't like the name, and still have trouble seei= ng the value.

From: Dan Brown
Sent: Tuesday, July 18, 2017 2:29 PM
To: Sharon Goldberg; cfrg@irtf.org
Cc: jan@ns1.co= m; Leonid Reyzin; Dimitrios Papadopoulos
Subject: Re: [Cfrg] draft-goldbe-vrf: Verifiable Random Functio= ns

Hi Sharon and CFRG,

=C2=A0

On VRFs, my uncertain comments to consider at your leisure:

=C2=A0

Is it fair to say VRFs are relatively new?=C2=A0 If so, then mayb= e a little more caution is needed about their use.=C2=A0 It seems a tad has= ty that it is being used already.

=C2=A0

To me, it seems that VRFs are basically signatures, with an extra= feature.=C2=A0 My concern is that this extra feature might get overused, b= efore it is thoroughly reviewed.=C2=A0

=C2=A0

It is unsurprising to me that random oracle model proof can prove= the output of a hash to be random.=C2=A0 My intuitive concern is that at l= east informally, this is kind of circular.=C2=A0 Hashes often have some non-random-ish properties that might affect the ext= ra security (over signatures) that VRFs are aiming for.=C2=A0 I guess I wou= ld much prefer a proof saying if the hash has (well-studied) properties XYZ= , then your construction are VRFs.=C2=A0 (Maybe you have this already?=C2=A0 If so, then tell me so.)

=C2=A0

Since, VRFs require sending the =E2=80=9Cproofs=E2=80=9D on the w= ire, I find it hard to see how it could be used to prevent dictionary attac= ks.=C2=A0 I assume that you are saying the proofs must be encrypted when one needs to avoid dictionary models?=C2=A0 I suppose al= l the details are there in I-D and papers, but for now, I am confused about= the threat model (which parties have keys, etc., if they require a secure = channel and mutual trust, why just use plain old hash,=E2=80=A6). To resist dictionary attacks, were already have= PAKEs and PBHashing.=C2=A0 Now this?

=C2=A0

Finally, on a bikeshed-coloring note, I object to the name =E2=80= =9Cverifiable random function=E2=80=9D, on several grounds.

=C2=A0

  1. It is not= a function.=C2=A0 It is at least four functions, keygen, sign, verify, and= hashify.
  2. If you make it into a keyed function F_sk(m), as in prooftohash= (sign_sk(m)), it is not verifiable.=C2=A0
  3. Verification requires the intermediate proof, which is certainly not eve= n pseudorandom (it is easy to distinguish valid signatures from random).
  4. = It is pseudorandom, not random.=C2=A0 (The keys are random, but many crypto= has keys, without having =E2=80=9Crandom=E2=80=9D in its name: encryption,= MAC, signatures, key exchange, =E2=80=A6, they also don=E2=80=99t verifiable or random in t= heir names either.)
  5. The similar phrase =E2=80=9Cverifiably random=E2=80= =9D, albeit as a misnomer, has past precedents, see NIST P-256 and Brainpoo= l, etc.=C2=A0 When I see VRF, I think a function, that aims to VR in that sense, and great, now we can improve o= n Brainpool, etc.
  6. =E2=80=9CRandom function=E2=80=9D should be reserved fo= r the ideal random mapping concept, for example, as studied by Flajolet-Odl= yzko (ok they only studied the case of equal size domain and range).=C2=A0 The random oracle model, i= s the idea of approximating this ideal, etc.=C2=A0 An actual approximation = should not be name as the ideal (sorry, I=E2=80=99m kind of repeating my po= int 4).

=C2=A0

Please forgive the fact that my comments above are not very const= ructive (or if the tone is wrong).=C2=A0 This is a new topic for me, so I a= m reluctant too many suggestions.=C2=A0 Nonetheless, I suggest (0) waiting a little, (1) a non-random-oracle security proof (if= you don=E2=80=99t have it yet), (2) re-naming the scheme to something like= re-hashable (or digestible) signatures (and re-name the various parts, i.e= . proof -> signature, etc.).

=C2=A0

Best regards,

=C2=A0

Dan

=C2=A0

=C2=A0

From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Sharon Goldberg
Sent: Wednesday, July 12, 2017 5:42 AM
To: cfrg@irtf.org=
Cc: jan@ns1.com= ; Dimitrios Papadopoulos <dipapado@umd.edu>; Leonid Reyzin <reyzin@cs.bu.edu>
Subject: [Cfrg] draft-goldbe-vrf: Verifiable Random Functions=

=C2=A0

Dear CFRG,

I'm presenting at next week's meeting on Verifiable Random Function= s. A VRF is the public-key version of keyed cryptographic hash. Only the ho= lder of the VRF secret key can compute the hash, but anyone with the public= key can verify it.=C2=A0 VRFs can be used to prevent dictionary attacks on hash-based data structures, and have applica= tions to key transparency (CONIKS), DNSSEC (NSEC5), and cryptocurrencies (A= lgorand).

In advance of the meeting, please see:

1) Our substantially updated -01 draft:
https://datatracker.ietf.org/doc/draft-goldbe-vrf/

2) Our project page, with links to various VRF implementations:
ht= tps://www.cs.bu.edu/~goldbe/projects/vrf

Comments welcome.=C2=A0 Thanks,

Sharon

--
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu= .edu/~goldbe




--
=
---
Sharon Goldberg
Computer Science,= Boston University
http://www.cs.bu.edu/~goldbe

_______________________________= ________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg





--
---
Sharon Goldberg
Computer Science, Boston Uni= versity
http:= //www.cs.bu.edu/~goldbe
--001a113ecb70bb7422055536f20c--