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 BF2E0131FBF for ; Thu, 27 Jul 2017 01:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 pEC9TJPQ4orx for ; Thu, 27 Jul 2017 01:51:51 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (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 09A03127136 for ; Thu, 27 Jul 2017 01:51:51 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id g25so73737045lfh.1 for ; Thu, 27 Jul 2017 01:51:50 -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=qwOrxtq/CICr1raa85Ces1FmQWjyllGldEGZGtHNTCw=; b=Yd9v6Xv7BFzBSyxUJ48uDBVA/GkK+UA4HeAdoUFY5Hb6mPUtwN7jHQJz3aZ7Pm+0WO j9+3FZKQMmosh+b3xplG5YtPmUWo7IKOzosBq4GwPn/9UAdICe9cVRQ4tY0Y7RqwBiB3 4BhXJCQuLzQK1kEgXCevI8X6Dxa4FiOqRTvCE1x8HFe+F+lneIH8It+Lt/tJA5H4Fq2P tGzvLw7rAsgnX08kbUAVdceSu1Z2VOAvyzUgjbKf2pO8BMiNqGmS9Ebdd3Yu7d1TDzYF k7y0aH9PO8oyFqT+JILqpMWhymPYtBVLiiVVU9QbltnmUd5jwIdc4xngWIOc0Bn6DC0u WcLQ== 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=qwOrxtq/CICr1raa85Ces1FmQWjyllGldEGZGtHNTCw=; b=Xu+uYCzwbjEuCnqAUWdCChx2BPfL8W9OxdeVpDk6mafyBB84prX/r/AVoKNr7LJJPI j0uSUbn/mYx00pZd6XnZOFU+Gyg0FoIxLdd+fXb/UYTRFi5MRMT1+JzhD25byT36Hyn9 pmoYx03VXN8U3VUVE9jEP14MNE+hQaGPQqekgKXS51Wf4uMepdu0uw92pmnwb6BTRqyA Hq/pOpOZnDkBv5SX/oeUqfte8SA3+1f0OR1X2lGkbyfQinwsfDtKfqBZpeaVxTUyfo/Z AQtdHEizCEaBceTc6i5XKFz7w5GKt9bW4+PqNcqdOSp74L/a/SbUck7lvzUPn9it+pFJ WqAw== X-Gm-Message-State: AIVw113MeSkHzRKdrI0OEhsWzHBM2C2yGvJqItiGB9XwiZVI0PqZLwVv rSieLtna1JEcH8QqnY6tHkqKXydhLg== X-Received: by 10.46.84.83 with SMTP id y19mr1588622ljd.186.1501145509149; Thu, 27 Jul 2017 01:51:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.22.40 with HTTP; Thu, 27 Jul 2017 01:51:48 -0700 (PDT) In-Reply-To: References: <810C31990B57ED40B2062BA10D43FBF501B63B22@XMB116CNC.rim.net> <20170721163204.8573013.1016.15939@blackberry.com> From: Thomas Garcia Date: Thu, 27 Jul 2017 09:51:48 +0100 Message-ID: To: Sharon Goldberg Cc: Dan Brown , "jan@ns1.com" , "cfrg@irtf.org" , Dimitrios Papadopoulos , Leonid Reyzin Content-Type: multipart/alternative; boundary="f403045fc2f2d43ee0055548acd5" 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: Thu, 27 Jul 2017 08:51:55 -0000 --f403045fc2f2d43ee0055548acd5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for helping me clear those things up! Thomas G. On Wed, Jul 26, 2017 at 12:42 PM, Sharon Goldberg wrote: > 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 >> 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 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 th= e >>> crypto literature, and changing it will cause more confusion than keepi= ng >>> it. >>> >>> In terms of the VRF's security properties, there are three: uniqueness= , >>> collision resistance, and pseudorandomness. These are defined in our dr= aft ( >>> 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 = the >>> 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 >>> the output of a hash to be random". But actually, the output of a hash = is >>> NOT random if the input and the hash function are known. This is becaus= e >>> 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 knowle= dge >>> of the input. Only once the VRF proof is given, does the VRF output sto= p >>> looking random. Note that random oracles are not essential for VRFs, an= d >>> non-random-oracles constructions exist (but are less efficient than wha= t 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, when= ever >>> signed hash values are disclosed, your sensitive data is subject to >>> dictionary attacks. VRFs solve that problem, and sensitive names don't = have >>> 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 int= o a >>> Merkle-like authenticated data structure. If you just use standard hash= ing, >>> whenever hash values are disclosed, sensitive data is subject to dictio= nary >>> 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 implementatio= ns >>> we have 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 i= n >>> 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 s= o >>>> new. =E2=80=8EStill don't like the name, and still have trouble seein= g 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 = is >>>> 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, be= fore >>>> 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 p= roof >>>> saying if the hash has (well-studied) properties XYZ, then your >>>> construction are VRFs. (Maybe you have this already? If so, then tel= l 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 dictio= nary >>>> models? I suppose all the details are there in I-D and papers, but fo= r >>>> now, I am confused about the threat model (which parties have keys, et= c., >>>> 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. Now this? >>>> >>>> >>>> >>>> Finally, on a bikeshed-coloring note, I object to the name =E2=80=9Cve= rifiable >>>> 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 f= rom >>>> 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 nam= e: encryption, MAC, >>>> signatures, key exchange, =E2=80=A6, they also don=E2=80=99t verifi= able or random in their >>>> names either.) >>>> 5. The similar phrase =E2=80=9Cverifiably random=E2=80=9D, albeit a= s 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 = can >>>> improve on Brainpool, etc. >>>> 6. =E2=80=9CRandom function=E2=80=9D should be reserved for the ide= al random >>>> mapping concept, for example, as studied by Flajolet-Odlyzko (ok th= ey only >>>> studied the case of equal size domain and range). The random oracl= e model, >>>> is the idea of approximating this ideal, etc. An actual approximat= ion >>>> should not be name as the ideal (sorry, I=E2=80=99m kind of repeati= ng my point 4). >>>> >>>> >>>> >>>> Please forgive the fact that my comments above are not very >>>> constructive (or if the tone is wrong). This is a new topic for me, s= o I >>>> am reluctant too many suggestions. Nonetheless, I suggest (0) waiting= a >>>> little, (1) a non-random-oracle security proof (if you don=E2=80=99t h= ave 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, et= c.). >>>> >>>> >>>> >>>> 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 ho= lder >>>> 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 >>> >>> >> > > > -- > --- > Sharon Goldberg > Computer Science, Boston University > http://www.cs.bu.edu/~goldbe > --f403045fc2f2d43ee0055548acd5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks for helping me clear those thin= gs up!

Thomas G.

On Wed, Jul 26, 2017 at 12:42 PM, Sharo= n Goldberg <sharon.goldbe@gmail.com> wrote:
Hi Thomas,

1. It seems that= one of the properties that you are interested that the VRF will have is de= terminism. On the other hand, the EC-VRF value is dependent on the choice o= f some random number k. How are these two facts compatible? Am I missing so= mething?

We require dete= rminism from the VRF hash output, which is obtained from the VRF proof via = the "proof2hash" function.

The EC-VRF pr= oof has 3 values: gamma, c, s
Values c and s depends on the choic= e of random number k
But value gamma does not depend on k.
<= div>
We get determinism because the VRF hash output (derived = using "proof2hash") depends only on gamma, but not on c and s.
=C2=A0
Slide 28 from my CFRG presentations gives a pictor= ial 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 outp= ut. Doesn't this expose the signature to collision attacks?
<= br>
No. We worked this out in our proof= s of security.=C2=A0 Section B.2.1 of this paper explains why this works.


Thanks,
Sharon
<= br>
=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 standard in the crypto literature, and changing it will cause more con= fusion than keeping it.

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

How VRFs pr= event dictionary attacks: a public hash is subject to a dictionary attack b= ecause, given the output, an adversary can evaluate the hash on different i= nputs and see what hits the outputs. In a VRF, the adversary can't eval= uate the hash on different inputs.=C2=A0

You say it's not surprisin= g 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 inpu= t 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 wha= t enables dictionary attacks. This is in contrast to a VRF, where the outpu= t is (pseudo)random even given knowledge of the input. Only once the VRF pr= oof is given, does the VRF output stop looking random. Note that random ora= cles are not essential for VRFs, and non-random-oracles constructions exist= (but are less efficient than what we propose to standardize).

As far a= s use cases, here are a few:=C2=A0
In the NSEC5 use case for DNSSEC, yo= u have sensitive data (domain names) and you sign consecutive pairs of hash= es of domain names in order to be able to prove absence of a name. If you j= ust use standard hashing, whenever signed hash values are disclosed, your s= ensitive data is subject to dictionary attacks. VRFs solve that problem, an= d sensitive names don't have to be disclosed at all. More details are i= n=C2=A0h= ttps://eprint.iacr.org/2017/099.pdf

In CONIKS (also Google Key= Transparency, Signal secure messaging, Yahoo! Coname) you also have some s= ensitive data (user names) that are put into a Merkle-like authenticated da= ta structure. If you just use standard hashing, whenever hash values are di= sclosed, sensitive data is subject to dictionary attacks. If you use VRFs, = sensitive data again can be disclosed only on an as-needed basis. More deta= ils are in =C2=A0https://eprint.iacr.org/2014/1004.pdf.

In a crypto= currency use case, you wish perform a coin flip that is deterministic and p= rovably correct, but cannot be done by just anyone.=C2=A0 More details are = in=C2=A0https://people.csail.mit.edu/nickola= i/papers/gilad-algorand-eprint.pdf=C2=A0and possibly other cryptoc= urrency papers.

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

Many of these us= e case are already putting VRFs into production use (esp. the CONIKS one).= =C2=A0 You can see a list of the various implementations we have found in t= he "implementation status" section of our draft.=C2=A0 One of the= reasons we think this spec is so important is that we found flaws in sever= al of the implementations that can be used to trivially break uniqueness. = =C2=A0(See eg:=C2=A0https://github.com/google/keytransparency/= issues/567)

Thanks,
Sharon=C2=A0

On Fri, Jul 21, 2017 at 7:32 PM, Dan Brown= <danibrown@blackberry.com> 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, keyg= en, 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 verifiabl= e.=C2=A0
  3. Verification requires the intermediate proof, which= is certainly not even pseudorandom (it is easy to distinguish valid signat= ures 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=9Cveri= fiably random=E2=80=9D, albeit as a misnomer, has past precedents, see NIST= P-256 and Brainpool, 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 for the ideal random mapping concept, for example, as st= udied by Flajolet-Odlyzko (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 University
http://www.cs.bu.edu/~gold= be

--f403045fc2f2d43ee0055548acd5--