Thank you, Chris, Jiayu, Inigo, and Riad! I support making=
this small change.

On Fri, Oct 29, 2021 at 8:11 PM Christopher Peikert <=
christopher.peikert=3D40al=
gorand.com@dmarc.ietf.org> wrote:

_______________________________________________[trying again, since the fir= st attempt was apparently rejected...]Hello VRF mainta= iners and CFRG readers,

I'm writing to suggest a very small and = backwards-compatible change to ECVRF,

with the goal of making this const= ruction slightly more resistant to misuse, andconsistent with other EC= constructions.(See the following pull request for the full c= hange:

CFRG mailing list

CFRG@irtf.org

https://www.irtf.org/mailman/listinfo/cfrg

Leo, thank you for the support. I should also have mention=
ed=C2=A0that I support publication of the document as an RFC, especially wi=
th this small change (and even without it, if need be).

=
Chris

On Mon, Nov 1, 2021 at 4:56 PM Leonid Reyzin <reyzin@cs.bu.edu> wrote:

Thank you, Chris, Jia= yu, Inigo, and Riad! I support making this small change._______________________________________________On Fri, Oct 29, 202= 1 at 8:11 PM Christopher Peikert <christopher.peikert=3D40algorand.com@dmarc.iet= f.org> wrote:[trying again, since the first attempt was appar= ently rejected...]Hello VRF maintainers and CFRG reade= rs,

I'm writing to suggest a very small and backwards-compatible= change to ECVRF,

with the goal of making this construction slightly mor= e resistant to misuse, andconsistent with other EC constructions.=(See the following pull request for the full change:https://github.com/cfrg/draft-irtf-cfrg-vrf/pull/1=C2=A0)=

An = ECVRF proof comprises (Gamma, c, s), where s is a nonnegative integermodulo q. In the current version of ECVRF_decode_proof, the range of s=is not checked, meaning that (for most curves) one can maul a va= lid proof

(Gamma, c, s) to a "different" valid proof (Gamma, c= , s + q).

(Note that mauling a proof in this way does not violate an= y of the security

properties discussed in the draft. It is not an attack= on ECVRF, but it could

cause security problems in a system that uses EC= VRF in a way that incorrectly

assumes non-malleability. And experience s= hows that assumptions like this

are not nearly as uncommon as we might h= ope...)

Fortunately, there is a cheap and simple fix that is in line= with other=C2=A0ECconstructions: ECVRF_decode_proof should just= reject any proof where thedecoded s >=3D q.Using this change to enforce canonical representations of proofs, = Jiayu Xuand I have shown that ECVRF proofs are non-malleable (un= der the sameor weaker assumptions adopted for analyzing ECVRF= 9;s other properties):informally, it is infeasible for an attack= er to produce any valid proof that it didnot obtain from the leg= itimate prover.(The formal definition and proof o= f this NM property and others are containedin a paper that is st= ill under construction, but we have fully written and verycarefu= lly checked the proof of non-malleability, and have high confidence in it.<= /div><= /div> _______________________________________________It is a relatively standard analysis using the forking lemma, as = with Schnorr-stylesignatures.)I realiz= e it's late for spec changes, but please note that this change is=backwards compatible with every implementation having a conforming

= ECVRF_prove implementation (because ECVRF_prove reduces s mod q).Moreover, the effect on performance ought to be negligible.Thanks to Inigo Querejeta Azurmendi for bringing this issue to our= attention, andRiad Wahby for helpful discussions and prep= aring the PR.Sincerely yours in cryptography,Chris Peikert(for myself and Jiayu Xu)

CFRG mailing list

CFRG@irtf.org

https://www.irtf.org/mailman/listinfo/cfrg

CFRG mailing list

CFRG@irtf.org

https://www.irtf.org/mailman/listinfo/cfrg

My preferred choices here are:=C2=A0

- Specify both: POPRF ne=
eds to be specified for the cases that need a partial OPRF and 2HashDH need=
s to be specified for cases where 2HashDH is sufficient, even without consi=
dering the threshold=C2=A0extension. Indeed,=C2=A0 2HashDH has advantages i=
n terms of simplicity, 40 years of use (in the form of blinding and differe=
nt signature flavors), weaker cryptographic assumptions, and an analysis in=
the Universally Composable framework. The latter is used to prove the secu=
rity of OPAQUE (and other applications); namely, the analysis of OPAQUE for=
malizes Asymmetric PAKEs as UC objects and the OPAQUE proof assumes the OPR=
F to satisfy a defined UC functionality. POPRF does not currently have such=
formalization (I am not saying it is impossible to have it, but that's=
the=C2=A0current situation). More generally, I see no reason to use the mo=
re involved POPRF construction when metadata values are not needed.

Btw,=C2=A0 2HashDH can also a=
ccommodate metadata values=C2=A0 by setting the 2HashDH key to a regular PR=
F computed on the metadata value (e.g., we use that in OPAQUE to address en=
umeration attacks). But, in general,=C2=A0 POPRF is better as a partial OPR=
F, especially when verifiability=C2=A0 is needed.=C2=A0

- Specifying both with same or similar sy=
ntax would be my preferred way. I would have assumed that doing so would be=
simple and natural but I guess that I am missing something since otherwise=
the answer to this question would be obvious.

=

- Specify both in the same document=C2=A0 the thre=
shold variant as out of scope.

- The threshold variant can be defined in a separate=C2=A0document=
. Doing so will take many months (or more) of work and we want to have a sp=
ecification of 2HashDH for use with OPAQUE and other applications for=C2=A0=
which 2HashDH suffices (or where it is necessary, if you want to maintain t=
he validity of proofs).

Hugo

PS: I will be h=
appy to discuss threshold applications in a=C2=A0separate=C2=A0thread witho=
ut derailing the discussion on the above=C2=A0 important questions.

On Tue, Nov 2, 2021 at 8:32 AM Christopher Wood =
<caw@heapingbits.net> wrot=
e:

As proposed d= uring the CFRG meeting at IETF 111 [1], the latest version of draft-irtf-cf= rg-voprf adopted the POPRF protocol from [2], which has the following synta= x:

=C2=A0 =C2=A0y =3D F(k, x, t)

Where k is the server's private key, x is the client's private inpu= t, t is a public value agreed upon by client and server, and y is the PRF o= utput. The motivation for this change was to enable applications and protoc= ols that require "metadata" bound to the PRF output to scale beyo= nd the "unique PRF key per metadata value" approach [3,4]. Moreov= er, with a fixed public value t, a POPRF is functionally equivalent to a cl= assical OPRF.

One question that arose subsequently to the release of [2] is the extent to= which threshold secret sharing of a secret key k can be supported. The pri= or 2HashDH OPRF protocol can be easily deployed in a threshold manner, tran= sparently to the client. In contrast, the 3HashSDHI POPRF protocol cannot. = After discussion with others off-list, whether one can build a fast, pairin= g-free POPRF that supports thresholding seems an open research question.

The current situation begs the following questions: Is thresholding a featu= re that is important for known use cases? What are these use cases? And, im= portantly, do folks want to use threshold systems to meet these use cases?<= br>

[5] plainly laid out the case for thresholding, but whether the vision and = demand has materialized is unclear to me. Understanding whether there are m= otivating use cases right now will help shape the ongoing specification wor= k.

In particular, assuming we want to support thresholding, we have the follow= ing questions:

1) Should we specify only the 2HashDH OPRF, 3HashSDHI POPRF, or both?

2) If both, should the syntax for the OPRF be kept separate from that of th= e POPRF? That is, should the document treat them as two separate cryptograp= hic objects, each with their own API and ciphersuites?

3) If the 2HashDH OPRF is included, should we describe how to deploy the pr= otocol in a threshold system? And if so, what do we say about distributed k= ey generation?

I think a reasonable outcome for the specification that would be maximally = useful to implementers and protocol designers comes from the following answ= ers:

1) Both, either in draft-irtf-cfrg-voprf or in separate documents.

2) Separate syntaxes.

3) Include threshold details but punt on the DKG protocol, similar to FROST= [6].

What do others think?

Thanks,

Chris

[1] http= s://datatracker.ietf.org/meeting/111/materials/slides-111-cfrg-ietf111-cfrg= -voprf-00.pdf

[2] https://eprint.iacr.org/2021/864, but the order of x and t = in the API are flipped

[3] https://mailarchi= ve.ietf.org/arch/msg/privacy-pass/QWtRvUQ4d3wS96rPzUYfKSfKWps/

[4] https://mailarchi= ve.ietf.org/arch/msg/privacy-pass/9THC0-P__-e90KycWLVJu7xDh68/

[5] https://csrc.nist.gov/CSRC/media/Pr= esentations/Threshold-Cryptography-Ready-for-Prime-Time/images-media/krawcz= yk-hugo-keynote-NTCW19.pdf

[6] https://datatracker.ietf= .org/doc/html/draft-irtf-cfrg-frost-01#section-8

_______________________________________________

CFRG mailing list

CFRG@irtf.org

https://www.irtf.org/mailman/listinfo/cfrg

Hi,

This LC went below our radar and couldn't r= eply in time. We totally support the publication of the document as an RFC.=

2 different implementations of this specification are being used in= production by the Witnet protocol, and as a matter of fact no less than 40= 0 bn VRFs have been produced and validated with these since last October:-=C2=A0https:=
//crates.io/crates/vrf

This LC went below our radar and couldn't r= eply in time. We totally support the publication of the document as an RFC.=

2 different implementations of this specification are being used in= production by the Witnet protocol, and as a matter of fact no less than 40= 0 bn VRFs have been produced and validated with these since last October:

Thank you,

Mario Cao

--00000000000043b6ed05cfe19815--
From nobody Thu Nov 4 10:53:10 2021
Return-Path: Hi Dan,

New KEMs =
with Compact Representation

---------=
---------------------------

Thanks fo=
r spending time of this! I think this is great work. I don't have any comme=
nts on this part of your draft, it seems very well written. Some related st=
uff:

- After t=
he HPKE discussions on compact representations there was a suggestion from =
Karthik that the LAKE WG could specify a compact representation format that=
could be usable by other protocols.
This was done in an appendix of the EDHOC draft. I don't know if there is =
any need for alignment with your draft.

https://d=
atatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-12#appendix-B

- There i=
s an ongoing discussion in the TLS WG regarding compact representation:

https://m=
ailarchive.ietf.org/arch/browse/tls/?gbt=3D1&index=3D9f5CCCAksexcvJ5JuP=
sBOcvigpw

- There i=
s a new draft in COSE suggesting using HPKE in COSE., which is aimed at con=
strained IoT.

https://d=
atatracker.ietf.org/doc/draft-tschofenig-cose-hpke/

https://m=
ailarchive.ietf.org/arch/msg/cose/KbuVtBk5vcxrTOzi2TWTUZiikmk/

Determini=
stic AEADs

---------=
---------------------------

Having re=
ad the draft quickly once, I don't realize immediately when the use of nonc=
es would be a
big problem, but I am sure you will=
explain when you present this to CFRG.

"in =
the case proposed here, the nonce is not used"

I see non=
ce-resistant modes as an extra security
measure that
helps when nonce reuse ha=
ppens for some reason. Not using a nonce by default leads as you say to &qu=
ot;concealment of whether or not a given plaintext was encrypted twice"=
;. I don't think that is a good security level,
unless you are sure than your plaintexts will be different. I think =93no =
nonce=94 should only be recommended for applications where
it is known that the plaintexts
will be different.

Cheers,

John

**From: **CFRG <cfrg-bounces@irtf.org> on be=
half of Dan Harkins <dharkins@lounge.org>

**Date: **Monday, 14 June 2021 at 20:08

**To: **cfrg@irtf.org <cfrg@irtf.org>

**Subject: **[CFRG] new draft modifying HPKE

Hello,

I know the cement on HPKE isn't quite dry yet but I wanted to =
get

something ready

for when it is. As I've discussed on this list before I want to add 2

things to HPKE:

- compact output of the NIST curves

- deterministic authenticated encryption

There's a new draft in the repository proposing just that:

https://datatracker.ietf.org/doc/draft-harkins-cfrg-d=
nhpke/

Please take a look. Comments are welcome.

Also, I implemented this in my HPKE code:

htt=
ps://protect2.fireeye.com/v1/url?k=3D75e2b750-2a798e50-75e2f7cb-86fc6812c36=
1-5e7ecf43d4ad5e61&q=3D1&e=3Dabe1414d-b2b6-46d7-a3e2-201e6cb4b21f&a=
mp;u=3Dhttps%3A%2F%2Fgithub.com%2Fdanharkins%2Fhpke-wrap.

The test vectors there are basically copied from the standard ones but I **
replaced
the KEM with the new KEM, compacted serialization, and encrypted with
AES-SIV. I'd
welcome any attempts at interoperation.
regards,
Dan.
--
"The object of life is not to be on the side of the majority, but to**

Thank you very much, Chris, for the detailed reading. I ad=
dress your comments point-by-point below.

- Section 3: M=
any of the security properties have "weaker" versions (trusted **=C2=A0 uniqueness, trusted collision resistance, etc) and claims that the=
se are **

=C2=A0 sufficient for many applications. It is not clear under w= hat conditions

=C2=A0 applications require stronger variants. Perhaps t= his should be added to

=C2=A0 the security considerations?

There = is some language already there -- for example "Trusted uniqueness is t= he same as full uniqueness, but it must hold only if the VRF keys PK and SK= were generated in a trustworthy manner" -- and more language in Secti= on 7, where these issues are discussed with respect to the specific VRFs de= fined. In response to your comment, we have edited the document to ensure a= tighter integration between these two sections. See https://github.com/cfrg/draft-irtf-cfrg-vrf/commit/91b83b6d68d84b049= 63dd89e8afa42424ecaae98

=C2=A0

- Section 3.4: Do we have proofs = that the schemes in this document satisfy

=C2=A0 the RO-like property, = or is this merely intuitively true? If the former,

=C2=A0 perhaps we sho= uld note that this analysis remains to be done?

=C2=A0

I don't b= elieve anyone wrote down and published these proofs for these very specific= variants, but they follow easily because the output is equal to an applica= tion of RO followed by a fixed permutation (and by uniqueness no other outp= ut will be accepted). Appendix C of https://eprint.iacr.org/2017/573.pdf does this proof for a ve= ry similar variant of the ECVRF, and the proof for FDH is even simpler. To = say "analysis remains to be done" would be a bit too strong.

= =C2=A0

- Section 4/5: Unless I'm missing something, neither the = RSA-baed VRF has no

=C2=A0 variant for achieving "full" securi= ty, unlike the ECVRF, which depends on the

=C2=A0 procedures in Section = 5.6. Should this inconsistency be noted in the introduction?

=C2=A0

= It is noted in detail in Security Considerations (7.1.1). We have edited th= e introduction to security properties (Section 3, to be exact) to point to = 7.1.1 as part of the response to the first comment.

- Section 5. &qu= ot;Note that with certain software libraries (for big integer and

=C2=A0= =C2=A0 =C2=A0 elliptic curve arithmetic), the int_to_string and point_to_s= tring

=C2=A0 =C2=A0 =C2=A0 conversions are not needed" --> it se= ems worth clarifying that this is

=C2=A0 is true iff the libraries retur= n strings that are encoded in the same way

=C2=A0 as required by the cor= responding ciphersuites, for interoperability reasons.

=C2=A0

Thanks= , fixed. See https://github.com/cfrg/draft-irtf= -cfrg-vrf/commit/ba0d8b30d656825e9f03cc834bc1638dee7b5f05#diff-382a26a0bccc= b52bc8c6ab7c862ed0ee8848df81772776e9fae86b36e5b1be11R858

=C2=A0

-= Section 5.3. It might be worth noting that the verification check does not=

=C2=A0 need to be done in constant time as it's a public operation.= (The comparison

=C2=A0 check at the end might lead one to ask whether o= r not it needs to be constant

=C2=A0 time, so calling it out early would= clarify.)

Thanks, added a discusion to 7.4, where side channels are= discussed. See

https://github.com/cfrg/dr= aft-irtf-cfrg-vrf/commit/ba0d8b30d656825e9f03cc834bc1638dee7b5f05#diff-382a= 26a0bcccb52bc8c6ab7c862ed0ee8848df81772776e9fae86b36e5b1be11R1339

**- Section 5.4.4. Remove "let" in "let <variable> =3D=
..." statements, as this**

=C2=A0 is not done in other functions whe= re variables are declared and initialized.

=C2=A0

Thanks, fixed. See= https://github.com/cfrg/draft-irtf-cfrg-vrf/c= ommit/ba0d8b30d656825e9f03cc834bc1638dee7b5f05#diff-382a26a0bcccb52bc8c6ab7= c862ed0ee8848df81772776e9fae86b36e5b1be11R1174

- Section 5.6. It= 's noted that the procedure in this section does not work if either

= =C2=A0 the curve or generator are untrusted, but aren't these both fixe= d for the suites

=C2=A0 in this document? If so, I might remove this par= agraph.

=C2=A0

We prefer to mitigate against the risk that someone c= odes it in a way that has the basepoint transferred from an untrusted sourc= e rather than hardwired. We have added a clarification to that effect. See = =C2=A0https://github.com/cfrg/draft-irtf-cfrg-= vrf/commit/ba0d8b30d656825e9f03cc834bc1638dee7b5f05#diff-382a26a0bcccb52bc8= c6ab7c862ed0ee8848df81772776e9fae86b36e5b1be11R1242

=C2=A0

- Sec= tion 5.6.1. Do implementations for curves with small cofactors perform vali= dation

=C2=A0 by checking against known points? I don't know! If thi= s isn't common, I would simply

=C2=A0 remove the variant for ed2551= 9, as it just seems simpler to clear the cofactor and

=C2=A0 check agai= nst the identity element. Conversely, the hash-to-curve document has specif= ic

=C2=A0 cofactor clearing suggestions for each curve, and it seems re= asonable to be opinionated in

=C2=A0 this document, too. One might even = just re-use the methods in draft-irtf-cfrg-hash-to-curve

=C2=A0 for P-25= 6 and ed25519.

Yes, other implementations seem to -- we got this ide= a from another implementation. It's faster and quite simple.

- S= ection 7.1. Recommendations for randomness generation can probably be cribb= ed

=C2=A0 from https://datatracker.ietf.org/doc/html/rfc8446#appendix-C.1.

=C2=A0

Generation of secrets is an active R&D area and putti= ng it in the standard now seems premature.

=C2=A0

# General comments=

- Can we remove try-and-increment entirely from this specification? The= security

=C2=A0 relevant discussion in 7.4 can be easily skipped by ap= plications looking to implement

=C2=A0 one of the options in either 5.4.= 1.1 or 5.4.1.2.

It requires a more complex set of libraries to imple= ment the other options. There are people who want to use try-and-increment,= and in most cases there's no harm, because the side channel attack tha= t it enables is only against the VRF input, which is not a secret.

=C2= =A0

- In some places the public key is denoted as Y (Section 7.1.1), but= in others it's

=C2=A0 denoted as PK. Perhaps these should be consi= stent?

PK is a generic public key, while Y is the EC point specific = to the ECVRF (much like (n,e) is the PK specific to the RSAVRF). I went thr= ough to ensure we use that consistently, and corrected a couple of places.<= br>

=
=C2=A0 sufficient for many applications. It is not clear under w= hat conditions

=C2=A0 applications require stronger variants. Perhaps t= his should be added to

=C2=A0 the security considerations?

There = is some language already there -- for example "Trusted uniqueness is t= he same as full uniqueness, but it must hold only if the VRF keys PK and SK= were generated in a trustworthy manner" -- and more language in Secti= on 7, where these issues are discussed with respect to the specific VRFs de= fined. In response to your comment, we have edited the document to ensure a= tighter integration between these two sections. See https://github.com/cfrg/draft-irtf-cfrg-vrf/commit/91b83b6d68d84b049= 63dd89e8afa42424ecaae98

=C2=A0

- Section 3.4: Do we have proofs = that the schemes in this document satisfy

=C2=A0 the RO-like property, = or is this merely intuitively true? If the former,

=C2=A0 perhaps we sho= uld note that this analysis remains to be done?

=C2=A0

I don't b= elieve anyone wrote down and published these proofs for these very specific= variants, but they follow easily because the output is equal to an applica= tion of RO followed by a fixed permutation (and by uniqueness no other outp= ut will be accepted). Appendix C of https://eprint.iacr.org/2017/573.pdf does this proof for a ve= ry similar variant of the ECVRF, and the proof for FDH is even simpler. To = say "analysis remains to be done" would be a bit too strong.

= =C2=A0

- Section 4/5: Unless I'm missing something, neither the = RSA-baed VRF has no

=C2=A0 variant for achieving "full" securi= ty, unlike the ECVRF, which depends on the

=C2=A0 procedures in Section = 5.6. Should this inconsistency be noted in the introduction?

=C2=A0

= It is noted in detail in Security Considerations (7.1.1). We have edited th= e introduction to security properties (Section 3, to be exact) to point to = 7.1.1 as part of the response to the first comment.

- Section 5. &qu= ot;Note that with certain software libraries (for big integer and

=C2=A0= =C2=A0 =C2=A0 elliptic curve arithmetic), the int_to_string and point_to_s= tring

=C2=A0 =C2=A0 =C2=A0 conversions are not needed" --> it se= ems worth clarifying that this is

=C2=A0 is true iff the libraries retur= n strings that are encoded in the same way

=C2=A0 as required by the cor= responding ciphersuites, for interoperability reasons.

=C2=A0

Thanks= , fixed. See https://github.com/cfrg/draft-irtf= -cfrg-vrf/commit/ba0d8b30d656825e9f03cc834bc1638dee7b5f05#diff-382a26a0bccc= b52bc8c6ab7c862ed0ee8848df81772776e9fae86b36e5b1be11R858

=C2=A0

-= Section 5.3. It might be worth noting that the verification check does not=

=C2=A0 need to be done in constant time as it's a public operation.= (The comparison

=C2=A0 check at the end might lead one to ask whether o= r not it needs to be constant

=C2=A0 time, so calling it out early would= clarify.)

Thanks, added a discusion to 7.4, where side channels are= discussed. See

https://github.com/cfrg/dr= aft-irtf-cfrg-vrf/commit/ba0d8b30d656825e9f03cc834bc1638dee7b5f05#diff-382a= 26a0bcccb52bc8c6ab7c862ed0ee8848df81772776e9fae86b36e5b1be11R1339

=C2=A0 is not done in other functions whe= re variables are declared and initialized.

=C2=A0

Thanks, fixed. See= https://github.com/cfrg/draft-irtf-cfrg-vrf/c= ommit/ba0d8b30d656825e9f03cc834bc1638dee7b5f05#diff-382a26a0bcccb52bc8c6ab7= c862ed0ee8848df81772776e9fae86b36e5b1be11R1174

- Section 5.6. It= 's noted that the procedure in this section does not work if either

= =C2=A0 the curve or generator are untrusted, but aren't these both fixe= d for the suites

=C2=A0 in this document? If so, I might remove this par= agraph.

=C2=A0

We prefer to mitigate against the risk that someone c= odes it in a way that has the basepoint transferred from an untrusted sourc= e rather than hardwired. We have added a clarification to that effect. See = =C2=A0https://github.com/cfrg/draft-irtf-cfrg-= vrf/commit/ba0d8b30d656825e9f03cc834bc1638dee7b5f05#diff-382a26a0bcccb52bc8= c6ab7c862ed0ee8848df81772776e9fae86b36e5b1be11R1242

=C2=A0

- Sec= tion 5.6.1. Do implementations for curves with small cofactors perform vali= dation

=C2=A0 by checking against known points? I don't know! If thi= s isn't common, I would simply

=C2=A0 remove the variant for ed2551= 9, as it just seems simpler to clear the cofactor and

=C2=A0 check agai= nst the identity element. Conversely, the hash-to-curve document has specif= ic

=C2=A0 cofactor clearing suggestions for each curve, and it seems re= asonable to be opinionated in

=C2=A0 this document, too. One might even = just re-use the methods in draft-irtf-cfrg-hash-to-curve

=C2=A0 for P-25= 6 and ed25519.

Yes, other implementations seem to -- we got this ide= a from another implementation. It's faster and quite simple.

- S= ection 7.1. Recommendations for randomness generation can probably be cribb= ed

=C2=A0 from https://datatracker.ietf.org/doc/html/rfc8446#appendix-C.1.

=C2=A0

Generation of secrets is an active R&D area and putti= ng it in the standard now seems premature.

=C2=A0

# General comments=

- Can we remove try-and-increment entirely from this specification? The= security

=C2=A0 relevant discussion in 7.4 can be easily skipped by ap= plications looking to implement

=C2=A0 one of the options in either 5.4.= 1.1 or 5.4.1.2.

It requires a more complex set of libraries to imple= ment the other options. There are people who want to use try-and-increment,= and in most cases there's no harm, because the side channel attack tha= t it enables is only against the VRF input, which is not a secret.

=C2= =A0

- In some places the public key is denoted as Y (Section 7.1.1), but= in others it's

=C2=A0 denoted as PK. Perhaps these should be consi= stent?

PK is a generic public key, while Y is the EC point specific = to the ECVRF (much like (n,e) is the PK specific to the RSAVRF). I went thr= ough to ensure we use that consistently, and corrected a couple of places.<= br>

On Fri, Nov 5, 2021 at 9:42 AM Christopher Wood <caw@heapingbits.net> wrote:

--0000000000000aa40505d05d84e6--
From nobody Tue Nov 9 10:27:32 2021
Return-Path: I read the document and = think it's ready to publish. I implemented ECVRF-P256-SHA256-SSWU and v= alidated that the test vectors match. I left my review comments at the top = of that implementation:

=C2=A0 =C2=A0https://github.com/chris-wood/v= rf-poc/blob/main/vrf.sage

I hope this helps.

Best,

Chris

On Mon, Oct 25, 2021, at 12:07 PM, Nick Sullivan wrote:

> Dear CFRG participants,

>

> The VRF draft has received significant reviews from the RG and the

> crypto panel and is ready for a second last call. This email commences=

> a last call for this document that will end on the last day of IETF 11= 2

> Online (12 Nov 2021):

>

> https://datatracker.ietf.org/doc/draft-ir= tf-cfrg-vrf/

>

> If you've read the document by the end of this period and think th= at it

> is ready (or not ready) for publication as an RFC, please send a

> message in reply to this email. Detailed comments would be helpful. Yo= u

> can reach out directly to CFRG chairs (cfrg-chairs@ietf.org) if you

> have questions about the process.

>

> Thank you,

> Nick, Stanislav & Alexey

> _______________________________________________

> CFRG mailing list

> CFRG@irtf.org> https://www.irtf.org/mailman/listinfo/cfrg

_______________________________________________

CFRG mailing list

CFRG@irtf.org

https://www.irtf.org/mailman/listinfo/cfrg

Hello, Jiayu Xu and I have two additional remarks abo=
ut the current ECVRF draft, specifically Sections 5.4.1 and 5.6.

=

Section 5.4.1: hash-to-curve should perhaps be generally=C2=A0des=
cribed as outputting a *finite* (i.e., non-identity) EC point H in G. The t=
hree instantiations in Sections 5.4.1.1-3 are described this way, but the g=
eneral operation is not.Non-identity H is used in the p=
ublished proof of uniqueness (both trusted and full): if H is identity, the=
n discrete logs with base H are not well defined and the proof doesn't =
make=C2=A0sense as written.

However, it interestin=
gly turns out that non-identity H is not a *necessary* requirement for uniq=
ueness; the existing proof=C2=A0easily extends to deal with this case. Esse=
ntially, if a cheating prover attempts to provide some Gamma for which cofa=
ctor*Gamma is (incorrectly) not identity, then there is only one possible v=
alue of the hash-challenge c for which the prover can succeed. This is exac=
tly the same situation as when a prover attempts to provide an incorrect Ga=
mma when H is not identity.

The published proofs o=
f collision resistance (trusted and full) and pseudorandomness also do not =
require H to be non-identity.

So, there is an opti=
on to drop this non-identity requirement, or at least provide further clari=
ty about it. (Perhaps it will be needed for some future security property w=
e have yet to contemplate.)

Section 5.6 says:

<= /div>

--00000000000097549505d063c249--
From nobody Wed Nov 10 04:27:29 2021
Return-Path: <= /div>

=C2=A0 =C2=A0In order to obtain "full uniquen=
ess" and "full collision resistance" (which provide protecti=
on against a malicious VRF public key), the Verifier MUST perform the follo=
wing additional validation procedure upon receipt of the public VRF key. [T=
he procedure simply rejects any public key that belongs to the small-order =
"torsion" subgroup.]

This text is formal=
ly true but somewhat confusing. The validation is needed only for "ful=
l collision resistance," not "full uniqueness." (Details fol=
low.) So, we suggest removing the mention of "full uniqueness" fr=
om the above.

For collision resistance, there is a=
n easy attack if the public key is invalid.

Howeve=
r, full uniqueness holds as long as the public key is a valid elliptic curv=
e point --- even if it is in the torsion subgroup, or is even the identity =
element. This is essentially because a valid proof ensures that

<=
br>

=C2=A0 =C2=A0cofactor*Gamma =3D dlog_B(cofactor*pubkey) * H .=

(This holds even if the dlog on the right-hand si=
de is zero.) So the LHS, and hence the function output, is uniquely defined=
.

Sincerely yours in cryptography,

Chris=