rfc9381.original.xml		rfc9381.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE rfc [		<!DOCTYPE rfc [
	<!ENTITY nbsp "&#160;">		<!ENTITY nbsp "&#160;">
	<!ENTITY zwsp "&#8203;">		<!ENTITY zwsp "&#8203;">
	<!ENTITY nbhy "&#8209;">		<!ENTITY nbhy "&#8209;">
	<!ENTITY wj "&#8288;">		<!ENTITY wj "&#8288;">
	]>		]>
	<?rfc toc="yes"?>
	<?rfc symrefs="yes"?>		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IRTF" category="
	<?rfc compact="yes"?>		info" consensus="true" docName="draft-irtf-cfrg-vrf-15" number="9381" ipr="trust
	<?rfc subcompact="no"?>		200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs="true" s
	<?rfc strict="no"?>		ortRefs="true" version="3">
	<?rfc rfcedstyle="yes"?>
	<?rfc comments="yes"?>
	<?rfc inline="yes"?>
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-i
	rtf-cfrg-vrf-15" ipr="trust200902" obsoletes="" updates="" submissionType="IETF"
	xml:lang="en" tocInclude="true" symRefs="true" version="3">
	<!-- xml2rfc v2v3 conversion 3.11.1 -->		<!-- xml2rfc v2v3 conversion 3.11.1 -->
	<front>		<front>
	<title abbrev="VRF">Verifiable Random Functions (VRFs)</title>		<title abbrev="VRFs">Verifiable Random Functions (VRFs)</title>
	<seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-vrf-15"/>		<seriesInfo name="RFC" value="9381"/>
	<author fullname="Sharon Goldberg" initials="S." surname="Goldberg">		<author fullname="Sharon Goldberg" initials="S." surname="Goldberg">
	<organization>Boston University</organization>		<organization>Boston University</organization>
	<address>		<address>
	<postal>		<postal>
	<street>111 Cummington Mall</street>		<street>665 Commonwealth Avenue</street>
	<city>Boston</city>		<city>Boston</city>
	<region>MA</region>		<region>MA</region>
	<code>02215</code>		<code>02215</code>
	<country>USA</country>		<country>United States of America</country>
	</postal>		</postal>
	<email>goldbe@cs.bu.edu</email>		<email>goldbe@cs.bu.edu</email>
	</address>		</address>
	</author>		</author>
	<author fullname="Leonid Reyzin" initials="L." surname="Reyzin">		<author fullname="Leonid Reyzin" initials="L." surname="Reyzin">
	<organization>Boston University and Algorand</organization>		<organization>Boston University and Algorand</organization>
	<address>		<address>
	<postal>		<postal>
	<street>111 Cummington Mall</street>		<street>665 Commonwealth Avenue</street>
	<city>Boston</city>		<city>Boston</city>
	<region>MA</region>		<region>MA</region>
	<code>02215</code>		<code>02215</code>
	<country>USA</country>		<country>United States of America</country>
	</postal>		</postal>
	<email>reyzin@bu.edu</email>		<email>reyzin@bu.edu</email>
	</address>		</address>
	</author>		</author>
	<author fullname="Dimitrios Papadopoulos" initials="D." surname="Papadopoulo s">		<author fullname="Dimitrios Papadopoulos" initials="D." surname="Papadopoulo s">
	<organization>Hong Kong University of Science and Technology</organization >		<organization>Hong Kong University of Science and Technology</organization >
	<address>		<address>
	<postal>		<postal>
	<street>Clearwater Bay</street>		<city>Clearwater Bay</city>
	<country>Hong Kong</country>		<country>Hong Kong</country>
	</postal>		</postal>
	<email>dipapado@cse.ust.hk</email>		<email>dipapado@cse.ust.hk</email>
	</address>		</address>
	</author>		</author>
	<author fullname="Jan Vcelak" initials="J." surname="Vcelak">		<author fullname="Jan Včelák" initials="J." surname="Včelák">
	<organization>NS1</organization>		<organization>NS1</organization>
	<address>		<address>
	<postal>
	<street>16 Beaver St</street>
	<city>New York</city>
	<region>NY</region>
	<code>10004</code>
	<country>USA</country>
	</postal>
	<email>jvcelak@ns1.com</email>		<email>jvcelak@ns1.com</email>
	</address>		</address>
	</author>		</author>
	<date year="2022"/>		<date year="2023" month="August"/>
	<workgroup>CFRG</workgroup>		<workgroup>Crypto Forum</workgroup>
	<keyword>public key cryptography</keyword>		<keyword>public key cryptography</keyword>
	<keyword>hashing</keyword>		<keyword>hashing</keyword>
	<keyword>authenticated denial</keyword>		<keyword>authenticated denial</keyword>
	<abstract>		<abstract>
	<t>		<t>
	A Verifiable Random Function (VRF) is the public-key version of a		A Verifiable Random Function (VRF) is the public key version of a
	keyed cryptographic hash. Only the holder of the secret key		keyed cryptographic hash. Only the holder of the secret key
	can compute the hash, but anyone with the public key		can compute the hash, but anyone with the public key
	can verify the correctness of the hash.		can verify the correctness of the hash.
	VRFs are useful for preventing enumeration of hash-based data structures .		VRFs are useful for preventing enumeration of hash-based data structures .
	This document specifies VRF constructions based on RSA and elliptic curv es that are secure in		This document specifies VRF constructions based on RSA and elliptic curv es that are secure in
	the cryptographic random oracle model.		the cryptographic random oracle model.
	</t>		</t>
	<t>		<t>
	This document is a product of the Crypto Forum Research Group (CFRG) i n the IRTF.		This document is a product of the Crypto Forum Research Group (CFRG) i n the IRTF.
	</t>		</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section anchor="intro" numbered="true" toc="default">		<section anchor="intro" numbered="true" toc="default">
	<name>Introduction</name>		<name>Introduction</name>
	<t>		<t>
	A Verifiable Random Function		A Verifiable Random Function
	(VRF) <xref target="MRV99" format="default"/> is the public-key version of a		(VRF) <xref target="MRV99" format="default"/> is the public key version of a
	keyed cryptographic hash. Only the holder of the VRF secret key		keyed cryptographic hash. Only the holder of the VRF secret key
	can compute the hash, but anyone with the corresponding public key		can compute the hash, but anyone with the corresponding public key
	can verify the correctness of the hash.		can verify the correctness of the hash.
	</t>		</t>
	<t>		<t>
	A key application of the VRF is to provide privacy against		A key application of the VRF is to provide privacy against
	offline dictionary attacks (also known as enumeration attacks) on data stored in a		offline dictionary attacks (also known as enumeration attacks) on data stored in a
	hash-based data structure.		hash-based data structure.
	In this application, a Prover holds the VRF secret key and uses the VRF hashi ng to		In this application, a Prover holds the VRF secret key and uses the VRF hashi ng to
	construct a hash-based data structure on the input data.		construct a hash-based data structure on the input data.
	</t>		</t>
	<t>		<t>
	Due to the nature of the VRF, only the Prover can answer queries		Due to the nature of the VRF, only the Prover can answer queries
	about whether or not some data is stored in the data structure. Anyone who		about whether or not some data is stored in the data structure. Anyone who
	knows the VRF public key can verify that the Prover has answered the queries		knows the VRF public key can verify that the Prover has answered the queries
	correctly. However, no offline inferences (i.e. inferences without querying		correctly. However, no offline inferences (i.e., inferences without querying
	the Prover) can be made about the data stored in the data structure.		the Prover) can be made about the data stored in the data structure.
	</t>		</t>
	<t>This document defines VRFs based on RSA and elliptic curves.		<t>This document defines VRFs based on RSA and elliptic curves.
	The choices of VRFs for inclusion into this document were based, in part , on synergy with existing RFCs and		The choices of VRFs for inclusion in this document were based, in part, on synergy with existing RFCs and
	commonly available implementations of individual components that are use d within the VRFs.		commonly available implementations of individual components that are use d within the VRFs.
	</t>		</t>
	<t>		<t>
	The particular choice of the VRF for a given application depends on the desired security properties, the availability of cryptographically strong implem entations, efficiency constraints, and the trust one places in RSA and elliptic curve Diffie-Hellman assumptions (and the trust in a particular choice of curve in case of elliptic curves). Differences in the security properties provided by the different options are discussed in <xref target="secdef" format="default"/> and <xref target="securitycons" format="default"/>.</t>		The particular choice of the VRF for a given application depends on the desired security properties, the availability of cryptographically strong implem entations, efficiency constraints, and the trust one places in RSA and elliptic curve Diffie-Hellman assumptions (and the trust in a particular choice of curve in the case of elliptic curves). Differences in the security properties provided by the different options are discussed in Sections&nbsp;<xref target="secdef" f ormat="counter"/> and <xref target="securitycons" format="counter"/>.</t>
	<t>		<t>
	This document represents the consensus of the Crypto Forum Research Group (CFRG).		This document represents the consensus of the Crypto Forum Research Group (CFRG).
	</t>		</t>
	<!--
	<t>
	VRFs are used for this purpose to prevent zone content enumeration in
	Domain Name System Security Extensions (DNSSEC) with NSEC5 Authenticated
	Denial of Existence <xref target="I-D.vcelak-nsec5"/>.
	</t>
	-->
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Requirements</name>		<name>Requirements</name>
	<t>		<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NO		"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
	T",		"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in		"<bcp14>SHOULD NOT</bcp14>",
	this		"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	document are to be interpreted as described in		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
	<xref target="RFC8174" format="default"/>.		are to be interpreted as described in BCP&nbsp;14
	</t>		<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
			when, they appear in all capitals, as shown here.</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Terminology</name>		<name>Terminology</name>
	<t>		<t>
	The following terminology is used through this document:		The following terminology is used throughout this document:
	</t>		</t>
	<dl newline="false" spacing="normal">		<dl newline="false" spacing="normal">
	<dt>SK:</dt>		<dt>SK:</dt>
	<dd>		<dd>
	The secret key for the VRF. (Note: the secret key is als		The secret key for the VRF. (Note: The secret key is also sometimes
	o sometimes called "private key".)		called a "private key".)
	</dd>		</dd>
	<dt>PK:</dt>		<dt>PK:</dt>
	<dd>		<dd>
	The public key for the VRF.		The public key for the VRF.
	</dd>		</dd>
	<dt>alpha or alpha_string:</dt>		<dt>alpha or alpha_string:</dt>
	<dd>		<dd>
	The input to be hashed by the VRF.		The input to be hashed by the VRF.
	</dd>		</dd>
	<dt>beta or beta_string:</dt>		<dt>beta or beta_string:</dt>
	<dd>		<dd>
	The VRF hash output.		The VRF hash output.
	</dd>		</dd>
	<dt>pi or pi_string:</dt>		<dt>pi or pi_string:</dt>
	<dd>		<dd>
	The VRF proof.		The VRF proof.
	</dd>		</dd>
	<dt>Prover:</dt>		<dt>Prover:</dt>
	<dd>		<dd>
	The Prover holds the VRF secret key SK and public key PK		Holds the VRF secret key SK and public key PK.
	.		</dd>
	</dd>
	<dt>Verifier:</dt>		<dt>Verifier:</dt>
	<dd>		<dd>
	The Verifier holds the VRF public key PK.		Holds the VRF public key PK.
	</dd>		</dd>
	<dt>Adversary:</dt>		<dt>Adversary:</dt>
	<dd>		<dd>
	Potential attacker; often used to define a security prop		Potential attacker; often used to define a security property.
	erty.		</dd>
	</dd>
	<dt>Malicious (or adversarial):</dt>		<dt>Malicious (or adversarial):</dt>
	<dd>		<dd>
	Performed by an adversary.		Performed by an adversary.
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>VRF Algorithms</name>		<name>VRF Algorithms</name>
	<t>		<t>
	A VRF comes with a key generation algorithm that generates a VRF		A VRF comes with a key generation algorithm that generates a VRF
	public key PK and secret key SK.		public key PK and secret key SK.
	</t>		</t>
	<t>		<t>
	The prover hashes an input alpha using the VRF secret key SK to obtain a VRF		The Prover hashes an input alpha using the VRF secret key SK to obtain a VRF
	hash output beta		hash output beta:
			</t>
			<t indent="3">
			beta = VRF_hash(SK, alpha)
	</t>		</t>
	<ul empty="true" spacing="normal">
	<li> beta = VRF_hash(SK, alpha) </li>
	</ul>
	<t>		<t>
	The VRF_hash algorithm is deterministic, in		The VRF_hash algorithm is deterministic, in
	the sense that it always produces the same output beta given the same		the sense that it always produces the same output beta, given the same
	pair of inputs (SK, alpha).		pair of inputs (SK, alpha).
	</t>		</t>
	<t>		<t>
	The prover also uses the secret key SK to construct a		The Prover also uses the secret key SK to construct a
	proof pi that beta is the correct hash output		proof pi that beta is the correct hash output:
	</t>		</t>
	<ul empty="true" spacing="normal">		<t indent="3">
	<li>pi = VRF_prove(SK, alpha)</li>		pi = VRF_prove(SK, alpha)
	</ul>		</t><t>
	<t>
	The VRFs defined in this document allow anyone to deterministically		The VRFs defined in this document allow anyone to deterministically
	obtain the VRF hash output beta directly from the proof value pi by using		obtain the VRF hash output beta directly from the proof value pi by using
	the function VRF_proof_to_hash:		the function VRF_proof_to_hash:
	</t>		</t>
	<ul empty="true" spacing="normal">		<t indent="3">
	<li> beta = VRF_proof_to_hash(pi)</li>		beta = VRF_proof_to_hash(pi)
	</ul>		</t>
	<t>		<t>
	Thus, for VRFs defined in this document, VRF_hash is defined as		Thus, for the VRFs defined in this document, VRF_hash is defined as
			</t>
			<t indent="3">
			VRF_hash(SK, alpha) = VRF_proof_to_hash(VRF_prove(SK, alpha)),
	</t>		</t>
	<ul empty="true" spacing="normal">
	<li> VRF_hash(SK, alpha) = VRF_proof_to_hash(VRF_prove(SK, alpha)),</li>
	</ul>
	<t>		<t>
	and therefore this document will specify VRF_prove and VRF_proof_to_hash		and therefore this document will specify VRF_prove and VRF_proof_to_hash
	rather than VRF_hash.		rather than VRF_hash.
	</t>		</t>
	<t>		<t>
	The proof pi allows a Verifier holding the public key PK		The proof pi allows a Verifier holding the public key PK
	to verify that beta is the correct VRF hash of input alpha		to verify that beta is the correct VRF hash of input alpha
	under key PK. Thus, the VRFs defined in this document also come with an algor ithm		under key PK. Thus, the VRFs defined in this document also come with an algor ithm
	</t>		</t>
	<ul empty="true" spacing="normal">		<t indent="3">
	<li> VRF_verify(PK, alpha, pi)</li>		VRF_verify(PK, alpha, pi)
	</ul>		</t>
	<t>		<t>
	that outputs (VALID, beta = VRF_proof_to_hash(pi)) if pi is valid,		that outputs ("VALID", beta = VRF_proof_to_hash(pi)) if pi is valid,
	and INVALID otherwise.		and "INVALID" otherwise.
	</t>		</t>
	</section>		</section>
	<section anchor="secdef" numbered="true" toc="default">		<section anchor="secdef" numbered="true" toc="default">
	<name>VRF Security Properties</name>		<name>VRF Security Properties</name>
	<t> VRFs are designed to ensure the following security properties: uniquen ess (full or trusted), collision resistance (full or trusted),		<t> VRFs are designed to ensure the following security properties: uniquen ess (full or trusted), collision resistance (full or trusted),
	and pseudorandomness (full or selective). Some are designed to also en sure unpredictability under malicious key generation. We now		and pseudorandomness (full or selective). Some are designed to also en sure unpredictability under malicious key generation. We now
	describe these properties.		describe these properties.
	</t>		</t>
	<section anchor="uniqueness" numbered="true" toc="default">		<section anchor="uniqueness" numbered="true" toc="default">
	<name>Full Uniqueness</name>		<name>Full Uniqueness</name>
	<t> Uniqueness means that, for any fixed VRF public		<t> Uniqueness means that, for any fixed VRF public
	key and for any input alpha, it is infeasible to find proofs for more tha n one VRF output beta.		key and for any input alpha, it is infeasible to find proofs for more tha n one VRF output beta.
	</t>		</t>
	<t>		<t>
	More precisely, "full uniqueness" means that an adversary cannot		More precisely, "full uniqueness" means that an adversary cannot
	find</t>		find</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>a VRF public key PK,</li>		<li>a VRF public key PK,</li>
	<li>a VRF input alpha,</li>		<li>a VRF input alpha, and</li>
	<li>and two proofs pi1 and pi2</li>		<li>two proofs pi1 and pi2</li>
	</ul>		</ul>
	<t>such that</t>		<t>such that</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>VRF_verify(PK, alpha, pi1) outputs (VALID, beta1),</li>		<li>VRF_verify(PK, alpha, pi1) outputs ("VALID", beta1),</li>
	<li>VRF_verify(PK, alpha, pi2) outputs (VALID, beta2),</li>		<li>VRF_verify(PK, alpha, pi2) outputs ("VALID", beta2), and</li>
	<li>and beta1 is not equal to beta2.</li>		<li>beta1 is not equal to beta2.</li>
	</ul>		</ul>
	</section>		</section>
	<section anchor="collisionresistance" numbered="true" toc="default">		<section anchor="collisionresistance" numbered="true" toc="default">
	<name>Full Collison Resistance</name>		<name>Full Collision Resistance</name>
	<t>Like cryptographic hash functions, VRFs are collision resistant. Col		<t>Like cryptographic hash functions, VRFs are collision resistant. Col
	lison resistance means		lision resistance means
	that it is infeasible to find two different inputs alpha1 and alpha2 with the same		that it is infeasible to find two different inputs alpha1 and alpha2 with the same
	output beta.		output beta.
	</t>		</t>
	<t>		<t>
	More precisely, "full collision resistance" means that an adversary cann ot		More precisely, "full collision resistance" means that an adversary cann ot
	find</t>		find</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>a VRF public key PK,</li>		<li>a VRF public key PK,</li>
	<li>two VRF inputs alpha1 and alpha2 that are not equal to each other,		<li>two VRF inputs alpha1 and alpha2 that are not equal to each other,
	</li>		and</li>
	<li>and two proofs pi1 and pi2</li>		<li>two proofs pi1 and pi2</li>
	</ul>		</ul>
	<t>such that</t>		<t>such that</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>VRF_verify(PK, alpha1, pi1) outputs (VALID, beta1),</li>		<li>VRF_verify(PK, alpha1, pi1) outputs ("VALID", beta1),</li>
	<li>VRF_verify(PK, alpha2, pi2) outputs (VALID, beta2),</li>		<li>VRF_verify(PK, alpha2, pi2) outputs ("VALID", beta2), and</li>
	<li>and beta1 is equal to beta2.</li>		<li>beta1 is equal to beta2.</li>
	</ul>		</ul>
	</section>		</section>
	<section anchor="trustedversions" numbered="true" toc="default">		<section anchor="trustedversions" numbered="true" toc="default">
	<name>Trusted Uniqueness and Trusted Collision Resistance</name>		<name>Trusted Uniqueness and Trusted Collision Resistance</name>
	<t>		<t>
	Full uniqueness and full collision resistance hold even if the VRF ke ys are generated maliciously.		Full uniqueness and full collision resistance hold even if the VRF ke ys are generated maliciously.
	For some applications, it is sufficient for a VRF to possess weaker s ecurity		For some applications, it is sufficient for a VRF to possess weaker s ecurity
	properties than full uniqueness and full collision resistance, called		properties than full uniqueness and full collision resistance. These
	"trusted uniqueness"		properties are called "trusted uniqueness"
	and "trusted collision resistance".		and "trusted collision resistance"; they are the same as full uniquen
	These properties are the same as full uniqueness and full collision r		ess and full collision resistance, respectively, but
	esistance, respectively, but
	are not guaranteed to hold if the adversary gets to choose the VRF pu blic key PK.		are not guaranteed to hold if the adversary gets to choose the VRF pu blic key PK.
	Instead, they are guaranteed to hold		Instead, they are guaranteed to hold
	only if the VRF keys PK and SK are generated as specified		only if the VRF keys PK and SK are generated as specified
	by the VRF key generation algorithm and then given to the adversary. In other words,		by the VRF key generation algorithm and then given to the adversary. In other words,
	they are guaranteed to hold even if the adversary		they are guaranteed to hold even if the adversary
	has the knowledge of SK and PK, but not guaranteed to hold if the adv ersary has the ability to choose SK and PK.		has knowledge of SK and PK but are not guaranteed to hold if the adve rsary has the ability to choose SK and PK.
	</t>		</t>
	<t>		<t>
	As further discussed in <xref target="untrustedkeys" format="default"/ >,		As further discussed in <xref target="untrustedkeys" format="default"/ >,
	some VRFs specified in this document satisfy only trusted uniqueness a		some of the VRFs specified in this document satisfy only trusted uniqu
	nd trusted collision resistance.		eness and trusted collision resistance.
	VRFs in this document that satisfy only trusted uniqueness and trusted		VRFs in this document that satisfy only trusted uniqueness and trusted
	collision resistance MUST NOT be used in applications		collision resistance <bcp14>MUST NOT</bcp14> be used in applications
	that need protection against adversarial VRF key generation.		that need protection against adversarial VRF key generation.
	</t>		</t>
	</section>		</section>
	<section anchor="pseudodef" numbered="true" toc="default">		<section anchor="pseudodef" numbered="true" toc="default">
	<name>Full Pseudorandomness or Selective Pseudorandomness</name>		<name>Full Pseudorandomness or Selective Pseudorandomness</name>
	<t> Pseudorandomness ensures that when someone who does not know SK sees		<t> Pseudorandomness ensures that when someone who does not know SK sees
	a VRF hash output beta without its corresponding VRF proof pi,		a VRF hash output beta without its corresponding VRF proof pi,
	then beta is indistinguishable from a random value.		beta is indistinguishable from a random value.
	</t>		</t>
	<t> More precisely, suppose the public and secret VRF keys (PK, SK) wer e generated		<t> More precisely, suppose that the public and secret VRF keys (PK, SK ) were generated
	correctly.		correctly.
	Pseudorandomness ensures that the VRF hash output beta		Pseudorandomness ensures that the VRF hash output beta
	(without its corresponding VRF proof pi) on		(without its corresponding VRF proof pi) on
	any adversarially chosen "target" VRF input alpha		any adversarially chosen "target" VRF input alpha
	looks indistinguishable from random		looks indistinguishable from random
	for any adversary who does not know the VRF secret		for any adversary who does not know the VRF secret
	key SK. This holds even if the adversary sees VRF hash outputs beta' a nd proofs		key SK. This holds even if the adversary sees VRF hash outputs beta' a nd proofs
	pi' for multiple other inputs alpha' (and even if those other inputs al pha' are chosen by the adversary).		pi' for multiple other inputs alpha' (and even if those other inputs al pha' are chosen by the adversary).
	</t>		</t>
	<t>		<t>
	"Full pseudorandomness" security property holds even against an adversa		The "full pseudorandomness" security property holds even against an adv
	ry who is allowed to choose the		ersary who is allowed to choose the
	"target" VRF input alpha at any time, even after it observes VRF outpu		target VRF input alpha at any time, even after it observes VRF outputs
	ts beta'		beta'
	and proofs pi' on a variety of chosen inputs alpha'.		and proofs pi' on a variety of chosen inputs alpha'.
	</t>		</t>
	<t>		<t>
	"Selective pseudorandomness" is a weaker security property		"Selective pseudorandomness" is a weaker security property
	that suffices in many applications. This security property holds		that suffices in many applications. This security property holds
	against an adversary who chooses		against an adversary who chooses
	the target VRF input alpha first, before it learns the VRF public key P K		the target VRF input alpha first, before it learns the VRF public key P K
	and obtains VRF outputs beta'		and obtains VRF outputs beta'
	and proofs pi' on other inputs alpha' of its choice.		and proofs pi' on other inputs alpha' of its choice.
	</t>		</t>
	<t>		<t>
	As further discussed in <xref target="prsecurity" format="default"/ >,		As further discussed in <xref target="prsecurity" format="default"/ >,
	VRFs specified in this document satisfy both full pseudorandomness and selective pseudorandomness,		the VRFs specified in this document satisfy both full pseudorandomn ess and selective pseudorandomness,
	but their quantitative security against the selective pseudorandomn ess attack is stronger.		but their quantitative security against the selective pseudorandomn ess attack is stronger.
	</t>		</t>
	<t>		<t>
	It is important to remember that the VRF output beta is always disting uishable from		It is important to remember that the VRF output beta is always disting uishable from
	random by the Prover, or by any other party that knows the VRF		random by the Prover or by any other party that knows the VRF
	secret key SK. Such a party can easily distinguish beta from		secret key SK. Such a party can easily distinguish beta from
	a random value by comparing beta to the result of VRF_hash(SK, alpha).		a random value by comparing beta to the result of VRF_hash(SK, alpha). I n particular, if the key is generated maliciously, even parties other than the P rover may know SK, and thus pseudorandomness cannot be guaranteed.
	</t>		</t>
	<t> Similarly, the VRF output beta is always distinguishable from random by any party that		<t> Similarly, the VRF output beta is always distinguishable from random by any party that
	knows a valid VRF proof pi corresponding to the VRF input alpha, even		knows a valid VRF proof pi corresponding to the VRF input alpha, even
	if this party does not know the VRF secret key SK.		if this party does not know the VRF secret key SK.
	Such a party can easily distinguish beta from a random value by		Such a party can easily distinguish beta from a random value by
	checking whether VRF_verify(PK, alpha, pi) returns (VALID, beta).		checking to see whether VRF_verify(PK, alpha, pi) returns ("VALID", beta).
	</t>		</t>
	<t>		<t>
	Additionally, the VRF output beta may be distinguishable from random if VRF key generation		Additionally, the VRF output beta may be distinguishable from random if VRF key generation
	was not done correctly. (For example, if VRF keys were		was not done correctly (for example, if VRF keys were
	generated with bad randomness.)		generated with bad randomness).
	</t>		</t>
	</section>		</section>
	<section anchor="unpreddef" numbered="true" toc="default">		<section anchor="unpreddef" numbered="true" toc="default">
	<name>Unpredictability Under Malicious Key Generation</name>		<name>Unpredictability under Malicious Key Generation</name>
	<t>As explained in <xref target="pseudodef" format="default"/>, pseudora ndomness cannot hold against malicious key generation.		<t>As explained in <xref target="pseudodef" format="default"/>, pseudora ndomness cannot hold against malicious key generation.
	For instance, if an adversary outputs VRF keys that are deterministically generated (or hard-coded and publicly known), then the outputs are easily deriv ed by anyone and are therefore not pseudorandom.		For instance, if an adversary outputs VRF keys that are deterministically generated (or hard-coded and publicly known), then the outputs are easily deriv ed by anyone and are therefore not pseudorandom.
	</t>		</t>
	<t>There is, however, a different type of unpredictability that is desir able in certain VRF applications (such as leader selection in the consensus prot ocols of <xref target="GHMVZ17" format="default"/> and <xref target="DGKR18" for mat="default"/>), called "unpredictability under malicious key generation". This property is similar		<t>There is, however, a different type of unpredictability that is desir able in certain VRF applications (such as leader selection in the consensus prot ocols of <xref target="GHMVZ17" format="default"/> and <xref target="DGKR18" for mat="default"/>), called "unpredictability under malicious key generation". This property is similar
	to the unpredictability achieved by an (ordinary, unkeyed)		to the unpredictability achieved by an (ordinary, unkeyed)
	cryptographic hash function: if the input has enough entropy (i.e., canno t be predicted), then the correct output is indistinguishable		cryptographic hash function: if the input has enough entropy (i.e., canno t be predicted), then the correct output is indistinguishable
	from uniformly random, no matter how the VRF keys are generated.		from uniformly random, no matter how the VRF keys are generated.
	</t>		</t>
	<t>		<t>
	A formal definition of this property appears in Section 3.2 of <xref targ et="DGKR18" format="default"/>. As further discussed in <xref target="unpredres " format="default"/>, only some VRFs specified in this document satisfy this pro perty.		A formal definition of this property appears in Section 3.2 of <xref targ et="DGKR18" format="default"/>. As further discussed in <xref target="unpredres " format="default"/>, only some of the VRFs specified in this document satisfy t his property.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="fdh" numbered="true" toc="default">		<section anchor="fdh" numbered="true" toc="default">
	<name>RSA Full Domain Hash VRF (RSA-FDH-VRF)</name>		<name>RSA Full Domain Hash VRF (RSA-FDH-VRF)</name>
	<t>		<t>
	The RSA Full Domain Hash VRF (RSA-FDH-VRF) is a VRF that, for suita ble key lengths, satisfies		The RSA Full Domain Hash VRF (RSA-FDH-VRF) is a VRF that, for suitab le key lengths, satisfies
	the "trusted uniqueness", "trusted		the "trusted uniqueness", "trusted
	collision resistance", and "full pseudorandomness" properties define d in <xref target="secdef" format="default"/>, as further discussed in <xref tar get="securitycons" format="default"/>.		collision resistance", and "full pseudorandomness" properties define d in <xref target="secdef" format="default"/>, as further discussed in <xref tar get="securitycons" format="default"/>.
	Its security follows from the		Its security follows from the
	standard RSA assumption in the random oracle model. Formal		standard RSA assumption in the random oracle model. Formal
	security proofs are in <xref target="PWHVNRG17" format="default"/>.		security proofs are provided in <xref target="PWHVNRG17" format="def ault"/>.
	</t>		</t>
	<t>		<t>
	The VRF computes the proof pi as a deterministic RSA signature on		The VRF computes the proof pi as a deterministic RSA signature on
	input alpha using the RSA Full Domain Hash Algorithm		input alpha using the RSA Full Domain Hashing algorithm
	<xref target="RFC8017" format="default"/> parametrized with the sele		<xref target="RFC8017" format="default"/> parameterized with the sel
	cted hash algorithm.		ected hash algorithm.
	RSA signature verification is used to verify the correctness of the		RSA signature verification is used to verify the correctness of the
	proof. The VRF hash output beta is simply obtained by hashing		proof. The VRF hash output beta is simply obtained by hashing
	the proof pi with the selected hash algorithm.		the proof pi with the selected hash algorithm.
	</t>		</t>
	<t>		<t>
	The key pair for RSA-FDH-VRF MUST be generated in a way that it sati		The key pair for the RSA-FDH-VRF <bcp14>MUST</bcp14> satisfy
	sfies		the conditions specified in <xref target="RFC8017" sectionFormat="of
	the conditions specified in Section 3 of <xref target="RFC8017" form		" section="3"/>.
	at="default"/>.
	</t>		</t>
	<t>		<t>
	In this section, the notation from <xref target="RFC8017" format="de fault"/> is used.		In this section, the notation from <xref target="RFC8017" format="de fault"/> is used.
	</t>		</t>
	<t>
	Parameters used:		<dl spacing="normal" newline="false">
	</t>
	<ul empty="true" spacing="normal">		<dt>Parameters used:</dt>
	<!-- do not change the names, these are from RFC8017 -->		<dd><t><br/></t>
	<li>(n, e) - RSA public key</li>		<dl spacing="normal">
	<li>K - RSA private key (its representation is implementation-dependent)		<dt>(n, e):</dt><dd>RSA public key</dd>
	</li>		<dt>K:</dt><dd>RSA private key (its representation is implementation
	<li>k - length in octets of the RSA modulus n (k must be less than 2^32)		dependent)</dd>
	</li>		<dt>k:</dt><dd>length, in octets, of the RSA modulus n (k must be les
	</ul>		s than 2^32)</dd>
	<t>		</dl>
	Fixed options (specified in <xref target="rsavrfSuites" format="defa		</dd>
	ult"/>):
	</t>		<dt>Fixed options (specified in <xref target="rsavrfSuites" format="de
	<ul empty="true" spacing="normal">		fault"/>):</dt>
	<li>Hash - cryptographic hash function</li>		<dd><t><br/></t>
	<li>hLen - output length in octets of hash function Hash</li>		<dl spacing="normal">
	<li>suite_string - an octet string specifying the RSA-FDH-VRF		<dt>Hash:</dt><dd>cryptographic hash function</dd>
	ciphersuite, which determines the above options</li>		<dt>hLen:</dt><dd>output length, in octets, of hash function Hash</d
	</ul>		d>
	<t>		<dt>suite_string:</dt><dd>an octet string specifying the RSA-FDH-VRF
	Primitives used:		ciphersuite, which determines the above options</dd>
	</t>		</dl>
	<ul empty="true" spacing="normal">		</dd>
	<li>
	I2OSP - Conversion of a nonnegative integer to an octet stri		<dt>Primitives used:</dt>
	ng as defined in		<dd><t><br/></t>
	Section 4.1 of <xref target="RFC8017" format="default"/>		<dl spacing="normal">
	(given an integer and a length in octets, produces a big-end		<dt>I2OSP:</dt><dd>Conversion of a non-negative integer to an octet
	ian representation of the integer, zero-padded to the desired length)		string as defined in <xref target="RFC8017"
	</li>		sectionFormat="of" section="4.1"/> (given an integer and a l
	<li>		ength (in
	OS2IP - Conversion of an octet string to a nonnegative integ		octets), produces a big-endian representation of the
	er as defined in		integer, zero-padded to the desired length)
	Section 4.2 of <xref target="RFC8017" format="default"/>		</dd>
	(given a big-endian encoding of an integer, produces the int		<dt>OS2IP:</dt><dd>Conversion of an octet string to a non-negativ
	eger)		e integer as defined in <xref target="RFC8017" sectionFormat="of" section="4.2"/
	</li>		>
	<li>		(given a big-endian encoding of an integer, produces the integer
	RSASP1 - RSA signature primitive as defined in		)
	Section 5.2.1 of <xref target="RFC8017" format="default"/> (		</dd>
	given a private key and an input, raises the input to the private RSA exponent m		<dt>RSASP1:</dt><dd>RSA signature primitive as defined in <xref ta
	odulo n)		rget="RFC8017" sectionFormat="of" section="5.2.1"/> (given
	</li>		a private key and an input, raises the input to the
	<li>		private RSA exponent modulo n)
	RSAVP1 - RSA verification primitive as defined in		</dd>
	Section 5.2.2 of <xref target="RFC8017" format="default"/> (		<dt>RSAVP1:</dt><dd>RSA verification primitive as defined in <xref t
	given a public key and an input, raises the input to the public RSA exponent mod		arget="RFC8017" sectionFormat="of" section="5.2.2"/> (given a public key and an
	ulo n)		input, raises the input to the public RSA exponent modulo n)
	</li>		</dd>
	<li>		<dt>MGF1:</dt><dd>Mask generation function based on the hash function
	MGF1 - Mask Generation Function based on the hash function H		Hash as defined in <xref target="RFC8017" sectionFormat="of" section="B.2.1"/> (
	ash as defined in		given an input, produces a random-oracle-like output of desired length)
	Section B.2.1 of <xref target="RFC8017" format="default"/> (		</dd>
	given an input, produces a random-oracle-like output of desired length)		<dt>||:</dt><dd>octet string concatenation
	</li>		</dd>
	<li>		</dl>
	|| - octet string concatenation		</dd>
	</li>		</dl>
	</ul>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>RSA-FDH-VRF Proving</name>		<name>RSA-FDH-VRF Proving</name>
	<t>		<t>
	RSAFDHVRF_prove(K, alpha_string[, MGF_salt])		RSAFDHVRF_prove(K, alpha_string[, MGF_salt])
	</t>		</t>
	<t>
	Input:
	</t>
	<ul empty="true" spacing="normal">
	<li>K - RSA private key</li>
	<li>alpha_string - VRF hash input, an octet string</li>
	</ul>
	<t>		<dl spacing="normal" newline="false">
	Optional Input:		<dt>Input:</dt>
	</t>		<dd><t><br/></t>
	<ul empty="true" spacing="normal">		<dl spacing="normal" newline="false">
	<li>MGF_salt - a public octet string used as a hash function salt; thi		<dt>K:</dt><dd>RSA private key</dd>
	s input is not used when MGF_salt is specified as part of the ciphersuite</li>		<dt>alpha_string:</dt><dd>VRF hash input, an octet string</dd>
	</ul>		</dl>
	<t>		</dd>
	Output:
	</t>		<dt>Optional input:</dt>
	<ul empty="true" spacing="normal">		<dd><t><br/></t>
	<li>pi_string - proof, an octet string of length k</li>		<dl spacing="normal" newline="false">
	</ul>		<dt>MGF_salt:</dt><dd>a public octet string used as a hash function sa
	<t>		lt; this input is not used when MGF_salt is specified as part of the ciphersuite
	Steps:		</dd>
	</t>		</dl>
	<ol spacing="normal" type="1"><li>mgf_domain_separator = 0x01</li>		</dd>
			<dt>Output:</dt>
			<dd>
			<t><br/></t>
			<dl spacing="normal" newline="false">
			<dt>pi_string:</dt><dd>proof, an octet string of length k</dd>
			</dl>
			</dd>
			</dl>
			<t>Steps:</t>
			<ol spacing="normal"><li>mgf_domain_separator = 0x01</li>
	<li>EM = MGF1(suite_string || mgf_domain_separator || MGF_salt || alph a_string, k - 1)</li>		<li>EM = MGF1(suite_string || mgf_domain_separator || MGF_salt || alph a_string, k - 1)</li>
	<li>m = OS2IP(EM)</li>		<li>m = OS2IP(EM)</li>
	<li>s = RSASP1(K, m)</li>		<li>s = RSASP1(K, m)</li>
	<li>pi_string = I2OSP(s, k)</li>		<li>pi_string = I2OSP(s, k)</li>
	<li>Output pi_string</li>		<li>Output pi_string</li>
	</ol>		</ol>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>RSA-FDH-VRF Proof to Hash</name>		<name>RSA-FDH-VRF Proof to Hash</name>
	<t>		<t>
	RSAFDHVRF_proof_to_hash(pi_string)		RSAFDHVRF_proof_to_hash(pi_string)
	</t>		</t>
			<dl spacing="normal" newline="false">
			<dt>Input:</dt>
			<dd>
			<t><br/></t>
			<dl newline="false" spacing="normal">
			<dt>pi_string:</dt><dd>proof, an octet string of length k</dd>
			</dl>
			</dd>
			<dt>Output:</dt>
			<dd>
			<t><br/></t>
			<dl newline="false" spacing="normal">
			<dt>beta_string:</dt><dd>VRF hash output, an octet string of lengt
			h hLen</dd>
			</dl>
			</dd>
			</dl>
	<t>		<t>
	Input:		Important note:
	</t>
	<ul empty="true" spacing="normal">
	<li>pi_string - proof, an octet string of length k</li>
	</ul>
	<t>
	Output:
	</t>
	<ul empty="true" spacing="normal">
	<li>beta_string - VRF hash output, an octet string of length hLen</li>
	</ul>
	<t>
	Important note:
	</t>		</t>
	<ul empty="true" spacing="normal">		<t indent="3">RSAFDHVRF_proof_to_hash should be run only on a pi_strin
	<li>RSAFDHVRF_proof_to_hash should be run only on pi_string that is kn		g value that is known to have been produced by RSAFDHVRF_prove, or from within R
	own to have been produced by RSAFDHVRF_prove, or from within RSAFDHVRF_verify as		SAFDHVRF_verify as specified in <xref target="rsaverify" format="default"/>.
	specified in <xref target="rsaverify" format="default"/>.</li>
	</ul>
	<t>
	Steps:
	</t>		</t>
	<ol spacing="normal" type="1"><li>proof_to_hash_domain_separator = 0x02<		<t>Steps:</t>
	/li>		<ol spacing="normal">
			<li>proof_to_hash_domain_separator = 0x02</li>
	<li>beta_string = Hash(suite_string || proof_to_hash_domain_separator || pi_string)</li>		<li>beta_string = Hash(suite_string || proof_to_hash_domain_separator || pi_string)</li>
	<li>Output beta_string</li>		<li>Output beta_string</li>
	</ol>		</ol>
	</section>		</section>
	<section anchor="rsaverify" numbered="true" toc="default">		<section anchor="rsaverify" numbered="true" toc="default">
	<name>RSA-FDH-VRF Verifying</name>		<name>RSA-FDH-VRF Verifying</name>
	<t>		<t>
	RSAFDHVRF_verify((n, e), alpha_string, pi_string[, MGF_salt])		RSAFDHVRF_verify((n, e), alpha_string, pi_string[, MGF_salt])
	</t>		</t>
	<t>		<dl spacing="normal" newline="false">
	Input:		<dt>Input:</dt>
	</t>		<dd>
	<ul empty="true" spacing="normal">		<t><br/></t>
	<li>(n, e) - RSA public key</li>		<dl newline="false" spacing="normal">
	<li>alpha_string - VRF hash input, an octet string</li>		<dt>(n, e):</dt><dd>RSA public key</dd>
	<li>pi_string - proof to be verified, an octet string of length k</li>		<dt>alpha_string:</dt><dd>VRF hash input, an octet string</dd>
	</ul>		<dt>pi_string:</dt><dd>proof to be verified, an octet string of length
	<t>		k</dd>
	Optional Input:		</dl>
	</t>		</dd>
	<ul empty="true" spacing="normal">
	<li>MGF_salt - a public octet string used as a hash function salt; thi
	s input is not used when MGF_salt is specified as part of the ciphersuite</li>
	</ul>
	<t>
	Output:
	</t>
	<t>		<dt>Optional input:</dt>
	Output:		<dd>
	</t>		<t><br/></t>
	<ul empty="true" spacing="normal">		<dl newline="false" spacing="normal">
	<li>		<dt>MGF_salt:</dt><dd>a public octet string used as a hash fu
	<t>("VALID", beta_string), where beta_string is the VRF hash output,		nction salt; this input is not used when MGF_salt is specified as part of the ci
	an octet string of length hLen; or		phersuite</dd>
	</t>		</dl>
	<t>"INVALID"</t>		</dd>
	</li>
	</ul>		<dt>Output:</dt>
	<t>		<dd>
	Steps:		<t><br/></t>
	</t>		<t>("VALID", beta_string), where beta_string is the VRF hash ou
	<ol spacing="normal" type="1"><li>s = OS2IP(pi_string)</li>		tput, an octet string of length hLen, or</t>
	<li>m = RSAVP1((n, e), s); if RSAVP1 returns "signature representative		<t>"INVALID"</t>
	out of range", output "INVALID" and stop.</li>		</dd>
			</dl>
			<t>Steps:</t>
			<ol spacing="normal"><li>s = OS2IP(pi_string)</li>
			<li>m = RSAVP1((n, e), s); if RSAVP1 returns "signature representative
			out of range", output "INVALID" and stop</li>
	<li>mgf_domain_separator = 0x01</li>		<li>mgf_domain_separator = 0x01</li>
	<li>EM' = MGF1(suite_string || mgf_domain_separator || MGF_salt || al pha_string, k - 1)</li>		<li>EM' = MGF1(suite_string || mgf_domain_separator || MGF_salt || al pha_string, k - 1)</li>
	<li>m' = OS2IP(EM')</li>		<li>m' = OS2IP(EM')</li>
	<li>		<li>
	If m and m' are equal, output ("VALID", RSAFDHVRF_proof_		If m and m' are equal, output ("VALID", RSAFDHVRF_proof_to_hash(pi_s
	to_hash(pi_string));		tring));
	else output "INVALID".		else output "INVALID"
	</li>		</li>
	</ol>		</ol>
	</section>		</section>
	<section anchor="rsavrfSuites" numbered="true" toc="default">		<section anchor="rsavrfSuites" numbered="true" toc="default">
	<name>RSA-FDH-VRF Ciphersuites</name>		<name>RSA-FDH-VRF Ciphersuites</name>
	<t>This document defines RSA-FDH-VRF-SHA256 as follows:</t>		<t>This document defines RSA-FDH-VRF-SHA256 as follows:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>suite_string = 0x01</li>		<li>suite_string = 0x01.</li>
	<li>The hash function Hash is SHA-256 as specified in <xref target="RF		<li>The hash function Hash is SHA-256 as specified in <xref target="RF
	C6234" format="default"/>, with hLen = 32</li>		C6234" format="default"/>, with hLen = 32.</li>
	<li>MGF_salt = I2OSP(k, 4) || I2OSP(n, k)</li>		<li>MGF_salt = I2OSP(k, 4) || I2OSP(n, k).</li>
	</ul>		</ul>
	<t>This document defines RSA-FDH-VRF-SHA384 as follows:</t>		<t>This document defines RSA-FDH-VRF-SHA384 as follows:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>suite_string = 0x02</li>		<li>suite_string = 0x02.</li>
	<li>The hash function Hash is SHA-384 as specified in <xref target="RF		<li>The hash function Hash is SHA-384 as specified in <xref target="RF
	C6234" format="default"/>, with hLen = 48</li>		C6234" format="default"/>, with hLen = 48.</li>
	<li>MGF_salt = I2OSP(k, 4) || I2OSP(n, k)</li>		<li>MGF_salt = I2OSP(k, 4) || I2OSP(n, k).</li>
	</ul>		</ul>
	<t>This document defines RSA-FDH-VRF-SHA512 as follows:</t>		<t>This document defines RSA-FDH-VRF-SHA512 as follows:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>suite_string = 0x03</li>		<li>suite_string = 0x03.</li>
	<li>The hash function Hash is SHA-512 as specified in <xref target="RF		<li>The hash function Hash is SHA-512 as specified in <xref target="RF
	C6234" format="default"/>, with hLen = 64</li>		C6234" format="default"/>, with hLen = 64.</li>
	<li>MGF_salt = I2OSP(k, 4) || I2OSP(n, k)</li>		<li>MGF_salt = I2OSP(k, 4) || I2OSP(n, k).</li>
	</ul>		</ul>
	</section>		</section>
	</section>		</section>
	<section anchor="ecvrf" numbered="true" toc="default">		<section anchor="ecvrf" numbered="true" toc="default">
	<name>Elliptic Curve VRF (ECVRF)</name>		<name>Elliptic Curve VRF (ECVRF)</name>
	<t>		<t>
	The Elliptic Curve Verifiable Random Function (ECVRF) is a VRF that, for suitable parameter choices,		The Elliptic Curve Verifiable Random Function (ECVRF) is a VRF that, for suitable parameter choices,
	satisfies the "full uniqueness", "trusted collision resistance",		satisfies the "full uniqueness", "trusted collision resistance",
	and "full pseudorandomness properties" defined in <xref target="secd		and "full pseudorandomness" properties defined in <xref target="secd
	ef" format="default"/>.		ef" format="default"/>.
	If validate_key parameter given to the ECVRF_verify is TRUE, then		If the validate_key parameter given to ECVRF_verify is TRUE, then
	the ECVRF additionally satisfies "full collision resistance" and "un predictability under malicious key generation". See <xref target="securitycons" format="default"/>		the ECVRF additionally satisfies "full collision resistance" and "un predictability under malicious key generation". See <xref target="securitycons" format="default"/>
	for further discussion. Formal security proofs are		for further discussion. Formal security proofs are provided
	in <xref target="PWHVNRG17" format="default"/>.		in <xref target="PWHVNRG17" format="default"/>.
	</t>		</t>
	<t>		<dl newline="false" spacing="normal">
	Notation used:		<dt>Notation used:</dt>
	</t>		<dd>
	<ul empty="true" spacing="normal">		<t><br/></t>
	<li>Elliptic curve operations are written in additive notation, with P+Q		<t>Elliptic curve operations are written in additive notation, with P+
	denoting point addition and x*P denoting scalar multiplication of a point P by		Q denoting point addition and x*P denoting scalar multiplication of a point P by
	a scalar x</li>		a scalar x</t>
	<li>x^y - x raised to the power y</li>		<dl spacing="normal">
	<li>x*y - x multiplied by y</li>		<dt>x^y:</dt><dd>x raised to the power y</dd>
	<li>s || t - concatenation of octet strings s and t</li>		<dt>x*y:</dt><dd>x multiplied by y</dd>
	<li>0xMN (where M and N are hexadecimal digits) - a single octet with va		<dt>s || t:</dt><dd>concatenation of octet strings s and t</dd>
	lue M*16+N; equivalently, int_to_string(M*16+N, 1), where int_to_string is as de		<dt>0xMN (where M and N are hexadecimal digits):</dt><dd>a single oc
	fined below.</li>		tet with value M*16+N; equivalently, int_to_string(M*16+N, 1), where int_to_stri
	</ul>		ng is as defined below</dd>
	<t>		</dl>
	Fixed options (specified in <xref target="ecvrfSuites" format="defau		</dd>
	lt"/>):		<dt>Fixed options (specified in <xref target="ecvrfSuites" format="defaul
	</t>		t"/>):</dt>
	<ul empty="true" spacing="normal">		<dd>
	<li>F - finite field</li>		<t><br/></t>
	<li>fLen - length, in octets, of an element in F encoded as an octet str		<dl spacing="normal">
	ing</li>		<dt>F:</dt><dd>finite field</dd>
	<li>E - elliptic curve (EC) defined over F</li>		<dt>fLen:</dt><dd>length, in octets, of an element in F encoded as a
	<li>ptLen - length, in octets, of a point on E encoded as an octet strin		n octet string</dd>
	g</li>		<dt>E:</dt><dd>elliptic curve (EC) defined over F</dd>
	<li>G - subgroup of E of large prime order</li>		<dt>ptLen:</dt><dd>length, in octets, of a point on E encoded as an
	<li>q - prime order of group G</li>		octet string</dd>
	<li>qLen - length of q in octets, i.e., smallest integer such that 2^(8q		<dt>G:</dt><dd>subgroup of E of large prime order</dd>
	Len)&gt;q</li>		<dt>q:</dt><dd>prime order of group G</dd>
	<li>cLen - length, in octets, of a challenge value used by the VRF (note		<dt>qLen:</dt><dd>length of q, in octets, i.e., the smallest integer
	that in the typical case, cLen is qLen/2 or close to it)</li>		such that 2^(8qLen) &gt; q</dd>
	<li>cofactor - number of points on E divided by q</li>		<dt>cLen:</dt><dd>length, in octets, of a challenge value used by th
	<li>B - generator of group G</li>		e VRF (note that in the typical case, cLen is qLen/2 or close to it)</dd>
	<li>Hash - cryptographic hash function</li>		<dt>cofactor:</dt><dd>number of points on E divided by q</dd>
	<li>hLen - output length in octets of Hash (hLen must be at least cLen;		<dt>B:</dt><dd>generator of group G</dd>
	in the typical case, it is at least qLen)</li>		<dt>Hash:</dt><dd>cryptographic hash function</dd>
	<li>ECVRF_encode_to_curve - a function that hashes strings to points on		<dt>hLen:</dt><dd>output length, in octets, of Hash (hLen must be at
	E.</li>		least cLen; in the typical case, it is at least qLen)</dd>
	<li>ECVRF_nonce_generation - a function that derives a pseudorandom nonc		<dt>ECVRF_encode_to_curve:</dt><dd>a function that hashes strings to
	e		points on E</dd>
	from SK and the input as part of ECVRF proving.</li>		<dt>ECVRF_nonce_generation:</dt><dd>a function that derives a pseudo
	<li>suite_string - an octet string specifying the ECVRF		random nonce
	ciphersuite, which determines the above options as well as type		from SK and the input as part of ECVRF proving</dd>
	conversions and parameter generation </li>		<dt>suite_string:</dt><dd>an octet string specifying the ECVRF
	</ul>		ciphersuite, which determines the above options as well as type conv
	<t>		ersions and parameter generation</dd>
	Type conversions (specified in <xref target="ecvrfSuites" format="de		</dl>
	fault"/>):		</dd>
	</t>		<dt>Type conversions (specified in <xref target="ecvrfSuites" format="defa
	<ul empty="true" spacing="normal">		ult"/>):
	<li>int_to_string(a, len) - conversion of nonnegative integer a		</dt>
	to octet string of length len</li>		<dd>
	<li> string_to_int(a_string) - conversion of an octet string a_string		<t><br/></t>
	to a nonnegative integer</li>		<dl newline="false" spacing="normal">
	<li>point_to_string - conversion of a point on E to an ptLen-octet strin		<dt>int_to_string(a, len):</dt><dd>conversion of non-negative integer a
	g</li>		to octet string of length len</dd>
	<li>string_to_point - conversion of an ptLen-octet string to a point on		<dt>string_to_int(a_string):</dt><dd>conversion of an octet string a_str
	E.		ing
	string_to_point returns INVALID if the octet string does not		to a non-negative integer</dd>
	convert to a valid EC point on the curve E.</li>		<dt>point_to_string:</dt><dd>conversion of a point on E to a ptLen-octet
	<li>		string</dd>
			<dt>string_to_point:</dt><dd>conversion of a ptLen-octet string to a poi
			nt on E.
			string_to_point returns "INVALID" if the octet string does n
			ot convert to a valid EC point on the curve E</dd>
			</dl>
			<t>
	Note that with certain software libraries		Note that with certain software libraries
	(for big integer and elliptic curve arithmetic),		(for big integer and elliptic curve arithmetic), the int_to_
	the int_to_string and point_to_string conversions are not ne		string and point_to_string conversions are not needed when
	eded, when		the libraries encode integers and EC points in the same way
	the libraries encode integers and EC points in the same way		as
	as required		required by the ciphersuites.
	by the ciphersuites.
	For example, in some implementations, EC point		For example, in some implementations, EC point
	operations will take octet strings as inputs and		operations will take octet strings as inputs and
	produce octet strings as outputs, without introducing		produce octet strings as outputs, without introducing
	a separate elliptic curve point type.		a separate elliptic curve point type.</t>
	</li>		</dd>
	</ul>
	<t>		<dt>
	Parameters used (the generation of these parameters is specified in		Parameters used (the generation of these parameters is specified in
	<xref target="ecvrfSuites" format="default"/>):		<xref target="ecvrfSuites" format="default"/>):</dt>
	</t>		<dd>
	<ul empty="true" spacing="normal">		<t><br/></t>
	<li>SK - VRF secret key</li>		<dl spacing="normal" newline="false">
	<li>x - VRF secret scalar, an integer.		<dt>SK:</dt><dd>VRF secret key</dd>
	Note: depending on the ciphersuite used, the VRF secret		<dt>x:</dt><dd>VRF secret scalar, an integer.
	scalar may be equal		Note: Depending on the ciphersuite used, the VRF secret
	to SK; else, it is derived from SK		scalar may be equal
	</li>		to SK; else it is derived from SK
	<li>Y = x*B - VRF public key, an point on E</li>		</dd>
	<li>PK_string = point_to_string(Y) - VRF public key represented as an oc		<dt>Y = x*B:</dt><dd>VRF public key, a point on E</dd>
	tet string</li>		<dt>PK_string = point_to_string(Y):</dt><dd>VRF public key represented a
	<li>encode_to_curve_salt - a public value used as a hash function salt</		s an octet string</dd>
	li>		<dt>encode_to_curve_salt:</dt><dd>a public value used as a hash function
	</ul>		salt</dd>
			</dl>
			</dd>
			</dl>
	<section anchor="ecvrfprove" numbered="true" toc="default">		<section anchor="ecvrfprove" numbered="true" toc="default">
	<name>ECVRF Proving</name>		<name>ECVRF Proving</name>
	<t>		<t>
	ECVRF_prove(SK, alpha_string[, encode_to_curve_salt])		ECVRF_prove(SK, alpha_string[, encode_to_curve_salt])
	</t>		</t>
	<t>
	Input:
	</t>
	<ul empty="true" spacing="normal">
	<li>SK - VRF secret key</li>
	<li>alpha_string - input alpha, an octet string</li>
	</ul>
	<t>		<dl spacing="normal" newline="false">
	Optional input:
	</t>		<dt>Input:</dt>
	<ul empty="true" spacing="normal">		<dd>
	<li>encode_to_curve_salt - a public salt value, an octet string; this		<t><br/></t>
	input is not used when encode_to_curve_salt is specified as part of the ciphersu		<dl spacing="normal" newline="false">
	ite</li>		<dt>SK:</dt><dd>VRF secret key</dd>
	</ul>		<dt>alpha_string:</dt><dd>input alpha, an octet string</dd>
			</dl>
			</dd>
			<dt>Optional input:</dt>
			<dd>
			<t><br/></t>
			<dl spacing="normal" newline="false">
			<dt>encode_to_curve_salt:</dt><dd>a public salt value, an octet st
			ring; this input is not used when encode_to_curve_salt is specified as part of t
			he ciphersuite</dd>
			</dl>
			</dd>
			<dt>Output:</dt>
			<dd>
			<t><br/></t>
			<dl spacing="normal" newline="false">
			<dt>pi_string:</dt><dd>VRF proof, an octet string of length ptLen+
			cLen+qLen</dd>
			</dl>
			</dd>
			</dl>
	<t>		<t>
	Output:		Steps:
	</t>
	<ul empty="true" spacing="normal">
	<li>pi_string - VRF proof, octet string of length ptLen+cLen+qLen</li>
	</ul>
	<t>
	Steps:
	</t>		</t>
	<ol spacing="normal" type="1"><li>		<ol spacing="normal"><li>
	<t>Use SK to derive the VRF secret scalar x and the VRF public key Y = x*B		<t>Use SK to derive the VRF secret scalar x and the VRF public key Y = x*B
	</t>		</t>
	<t>(this derivation depends on the ciphersuite, as per <xref target		<t>(this derivation depends on the ciphersuite, as per <xref target=
	="ecvrfSuites" format="default"/>;		"ecvrfSuites" format="default"/>; these values can be cached, for example, after
	</t>		key generation, and need not be rederived each time)</t>
	<t>these values can be cached, for example, after key generation, an
	d need not be rederived each time)</t>
	</li>		</li>
	<li>H = ECVRF_encode_to_curve(encode_to_curve_salt, alpha_string) (see <xref target="ecvrfH2C" format="default"/>)</li>		<li>H = ECVRF_encode_to_curve(encode_to_curve_salt, alpha_string) (see <xref target="ecvrfH2C" format="default"/>)</li>
	<li>h_string = point_to_string(H)</li>		<li>h_string = point_to_string(H)</li>
	<li>Gamma = x*H</li>		<li>Gamma = x*H</li>
	<li>k = ECVRF_nonce_generation(SK, h_string) (see <xref target="ecvrfN onceGeneration" format="default"/>)</li>		<li>k = ECVRF_nonce_generation(SK, h_string) (see <xref target="ecvrfN onceGeneration" format="default"/>)</li>
	<li>c = ECVRF_challenge_generation(Y, H, Gamma, k*B, k*H) (see <xref t arget="ecvrfChallengeGeneration" format="default"/>)</li>		<li>c = ECVRF_challenge_generation(Y, H, Gamma, k*B, k*H) (see <xref t arget="ecvrfChallengeGeneration" format="default"/>)</li>
	<li>s = (k + c*x) mod q</li>		<li>s = (k + c*x) mod q</li>
	<li>pi_string = point_to_string(Gamma) || int_to_string(c, cLen) || in t_to_string(s, qLen)</li>		<li>pi_string = point_to_string(Gamma) || int_to_string(c, cLen) || in t_to_string(s, qLen)</li>
	<li>Output pi_string</li>		<li>Output pi_string</li>
	</ol>		</ol>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>ECVRF Proof to Hash</name>		<name>ECVRF Proof to Hash</name>
	<t>		<t>
	ECVRF_proof_to_hash(pi_string)		ECVRF_proof_to_hash(pi_string)
	</t>		</t>
	<t>		<dl spacing="normal" newline="false">
	Input:		<dt>Input:</dt>
	</t>		<dd>
	<ul empty="true" spacing="normal">		<t><br/></t>
	<li>pi_string - VRF proof, octet string of length ptLen+cLen+qLen</li>		<dl spacing="normal" newline="false">
	</ul>		<dt>pi_string:</dt><dd>VRF proof, an octet string of length ptLen+
	<t>		cLen+qLen</dd>
	Output:		</dl>
	</t>		</dd>
	<ul empty="true" spacing="normal">
	<li>"INVALID", or </li>		<dt>Output:</dt>
	<li>beta_string - VRF hash output, octet string of length hLen</li>		<dd>
	</ul>		<t><br/></t>
	<t>		<dl spacing="normal" newline="false">
	Important note:		<dt>"INVALID", or </dt><dd></dd>
			<dt>beta_string:</dt><dd>VRF hash output, an octet string of lengt
			h hLen</dd></dl></dd>
			</dl>
			<t>
			Important note:
	</t>		</t>
	<ul empty="true" spacing="normal">		<t indent="3">ECVRF_proof_to_hash should be run only on a pi_string valu
	<li>ECVRF_proof_to_hash should be run only on pi_string that is known		e that is known to have been produced by ECVRF_prove, or
	to have been produced by ECVRF_prove, or		from within ECVRF_verify as specified in <xref target="ecverify" format=
	from within ECVRF_verify as specified in <xref target="e		"default"/>.
	cverify" format="default"/>.</li>
	</ul>
	<t>
	Steps:
	</t>		</t>
	<ol spacing="normal" type="1"><li>D = ECVRF_decode_proof(pi_string) (see		<t>Steps:</t>
	<xref target="ecvrfDecodeProof" format="default"/>)</li>		<ol spacing="normal"><li>D = ECVRF_decode_proof(pi_string) (see <xref ta
			rget="ecvrfDecodeProof" format="default"/>)</li>
	<li>If D is "INVALID", output "INVALID" and stop</li>		<li>If D is "INVALID", output "INVALID" and stop</li>
	<li>(Gamma, c, s) = D</li>		<li>(Gamma, c, s) = D</li>
	<li>proof_to_hash_domain_separator_front = 0x03</li>		<li>proof_to_hash_domain_separator_front = 0x03</li>
	<li>proof_to_hash_domain_separator_back = 0x00</li>		<li>proof_to_hash_domain_separator_back = 0x00</li>
	<li>beta_string = Hash(suite_string || proof_to_hash_domain_separator_ front || point_to_string(cofactor * Gamma) || proof_to_hash_domain_separator_bac k)</li>		<li>beta_string = Hash(suite_string || proof_to_hash_domain_separator_ front || point_to_string(cofactor * Gamma) || proof_to_hash_domain_separator_bac k)</li>
	<li>Output beta_string</li>		<li>Output beta_string</li>
	</ol>		</ol>
	</section>		</section>
	<section anchor="ecverify" numbered="true" toc="default">		<section anchor="ecverify" numbered="true" toc="default">
	<name>ECVRF Verifying</name>		<name>ECVRF Verifying</name>
	<t>		<t>
	ECVRF_verify(PK_string, alpha_string, pi_string[, encode_to_curv e_salt, validate_key])		ECVRF_verify(PK_string, alpha_string, pi_string[, encode_to_curv e_salt, validate_key])
	</t>		</t>
	<t>		<dl spacing="normal" newline="false">
	Input:		<dt>Input:</dt>
	</t>		<dd>
	<ul empty="true" spacing="normal">		<t><br/></t>
	<li>PK_string - public key, an octet string</li>		<dl spacing="normal" newline="false">
	<li>alpha_string - VRF input, octet string</li>		<dt>PK_string:</dt><dd>public key, an octet string</dd>
	<li>pi_string - VRF proof, octet string of length ptLen+cLen+qLen</li>		<dt>alpha_string:</dt><dd>VRF input, an octet string</dd>
	</ul>		<dt>pi_string:</dt><dd>VRF proof, an octet string of length ptLen+
	<t>		cLen+qLen</dd>
	Optional input:		</dl>
	</t>		</dd></dl>
	<ul empty="true" spacing="normal">		<dl spacing="normal" newline="false">
	<li>encode_to_curve_salt - a public salt value, an octet string; this		<dt>Optional input:</dt>
	input is not used when encode_to_curve_salt is specified as part of the ciphersu		<dd>
	ite</li>		<t><br/></t>
	<li>validate_key - a boolean. An implementation MAY support only the o		<dl spacing="normal" newline="false">
	ption of validate_key = TRUE, or only the option of validate_key = FALSE, in whi		<dt>encode_to_curve_salt:</dt><dd>a public salt value, an octet st
	ch case this input is not needed. If an implementation supports only one option,		ring; this input is not used when encode_to_curve_salt is specified as part of t
	it MUST specify which option is supports.</li>		he ciphersuite</dd>
	</ul>		<dt>validate_key:</dt><dd>a boolean. An implementation <bcp14>MAY<
			/bcp14> support only the option of validate_key = TRUE, or only the option of va
	<t>		lidate_key = FALSE, in which case this input is not needed. If an implementation
	Output:		supports only one option, it <bcp14>MUST</bcp14> specify which option it suppor
	</t>		ts</dd>
	<ul empty="true" spacing="normal">		</dl>
	<li>		</dd>
	<t>("VALID", beta_string), where beta_string is the VRF hash output,		<dt>Output:</dt>
	octet string of length hLen; or		<dd>
	</t>		<t><br/></t>
	<t> "INVALID"</t>		<t>("VALID", beta_string), where beta_string is the VRF hash output,
	</li>		an octet string of length hLen, or</t>
	</ul>		<t>"INVALID"</t>
			</dd>
			</dl>
	<t>		<t>Steps:</t>
	Steps:		<ol spacing="normal">
	</t>
	<ol spacing="normal" type="1">
	<li>Y = string_to_point(PK_string)</li>		<li>Y = string_to_point(PK_string)</li>
	<li>If Y is "INVALID", output "INVALID" and stop</li>		<li>If Y is "INVALID", output "INVALID" and stop</li>
	<li>If validate_key, run ECVRF_validate_key(Y) (<xref target="keycheck " format="default"/>); if it outputs "INVALID", output "INVALID" and stop		<li>If validate_key, run ECVRF_validate_key(Y) (<xref target="keycheck " format="default"/>); if it outputs "INVALID", output "INVALID" and stop
	</li>		</li>
	<li>D = ECVRF_decode_proof(pi_string) (see <xref target="ecvrfDecodePr oof" format="default"/>)</li>		<li>D = ECVRF_decode_proof(pi_string) (see <xref target="ecvrfDecodePr oof" format="default"/>)</li>
	<li>If D is "INVALID", output "INVALID" and stop</li>		<li>If D is "INVALID", output "INVALID" and stop</li>
	<li>(Gamma, c, s) = D</li>		<li>(Gamma, c, s) = D</li>
	<li>H = ECVRF_encode_to_curve(encode_to_curve_salt, alpha_string) (see <xref target="ecvrfH2C" format="default"/>)</li>		<li>H = ECVRF_encode_to_curve(encode_to_curve_salt, alpha_string) (see <xref target="ecvrfH2C" format="default"/>)</li>
	<li>U = s*B - c*Y</li>		<li>U = s*B - c*Y</li>
	<li>V = s*H - c*Gamma</li>		<li>V = s*H - c*Gamma</li>
	skipping to change at line 809 ¶		skipping to change at line 808 ¶
	<li>H = ECVRF_encode_to_curve(encode_to_curve_salt, alpha_string) (see <xref target="ecvrfH2C" format="default"/>)</li>		<li>H = ECVRF_encode_to_curve(encode_to_curve_salt, alpha_string) (see <xref target="ecvrfH2C" format="default"/>)</li>
	<li>U = s*B - c*Y</li>		<li>U = s*B - c*Y</li>
	<li>V = s*H - c*Gamma</li>		<li>V = s*H - c*Gamma</li>
	<li>c' = ECVRF_challenge_generation(Y, H, Gamma, U, V) (see <xref targ et="ecvrfChallengeGeneration" format="default"/>)</li>		<li>c' = ECVRF_challenge_generation(Y, H, Gamma, U, V) (see <xref targ et="ecvrfChallengeGeneration" format="default"/>)</li>
	<li>		<li>
	If c and c' are equal, output ("VALID", ECVRF_proof_to_h ash(pi_string));		If c and c' are equal, output ("VALID", ECVRF_proof_to_h ash(pi_string));
	else output "INVALID"		else output "INVALID"
	</li>		</li>
	</ol>		</ol>
	<t>Note that the first three steps need to be performed only once for a given public key.</t>		<t>Note that the first three steps need to be performed only once for a given public key.</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>ECVRF Auxiliary Functions</name>		<name>ECVRF Auxiliary Functions</name>
	<section anchor="ecvrfH2C" numbered="true" toc="default">		<section anchor="ecvrfH2C" numbered="true" toc="default">
	<name>ECVRF Encode to Curve</name>		<name>ECVRF Encode to Curve</name>
	<t>The ECVRF_encode_to_curve algorithm takes a public salt (see <xref target="salt" format="default"/>) and the VRF input alpha		<t>The ECVRF_encode_to_curve algorithm takes a public salt (see <xref target="salt" format="default"/>) and the VRF input alpha
	and converts it to H, an EC point in G.		and converts it to H, an EC point in G.
	This algorithm is the only place the VRF input alpha is used		This algorithm is the only place the VRF input alpha is used
	for proving and verifying. See		for proving and verifying. See
	<xref target="prehash" format="default"/> for further discussion.		<xref target="prehash" format="default"/> for further discussion.
	</t>		</t>
	<t>This section specifies a number of such algorithms, which are not c		<t>This section specifies a number of such algorithms; these algorithm
	ompatible with each other and are intended to use with various ciphersuites spec		s are not compatible with each other and are intended for use with the various c
	ified in <xref target="ecvrfSuites" format="default"/>.</t>		iphersuites specified in <xref target="ecvrfSuites" format="default"/>.</t>
	<t>
	Input:
	</t>
	<ul empty="true" spacing="normal">
	<li>encode_to_curve_salt - public salt value, an octet string</li>
	<li>alpha_string - value to be hashed, an octet string</li>
	</ul>
	<t>
	Output:
	</t>
	<ul empty="true" spacing="normal">
	<li>H - hashed value, a point in G </li>
	</ul>
			<dl spacing="normal" newline="false">
			<dt>Input:</dt>
			<dd>
			<t><br/></t>
			<dl spacing="normal" newline="false">
			<dt>encode_to_curve_salt:</dt><dd>public salt value, an octet str
			ing</dd>
			<dt>alpha_string:</dt><dd>value to be hashed, an octet string</dd
			>
			</dl>
			</dd>
			<dt>Output:</dt>
			<dd>
			<t><br/></t>
			<dl spacing="normal" newline="false">
			<dt>H:</dt><dd>hashed value, a point in G</dd>
			</dl>
			</dd>
			</dl>
	<section anchor="ecvrfH2C1" numbered="true" toc="default">		<section anchor="ecvrfH2C1" numbered="true" toc="default">
	<name>ECVRF_encode_to_curve_try_and_increment</name>		<name>ECVRF_encode_to_curve_try_and_increment</name>
	<t>		<t>
	The following ECVRF_encode_to_curve_try_and_increment(encode_to_curv e_salt, alpha_string) algorithm		The ECVRF_encode_to_curve_try_and_increment(encode_to_curve_salt, al pha_string) algorithm
	implements ECVRF_encode_to_curve in a simple and		implements ECVRF_encode_to_curve in a simple and
	generic way that works for any elliptic curve. To use this algorithm ,		generic way that works for any elliptic curve. To use this algorithm ,
	hLen MUST be at least fLen.		hLen <bcp14>MUST</bcp14> be at least fLen.
	</t>		</t>
	<t>		<t>
	The running time of this algorithm depends on alpha_string.		The running time of this algorithm depends on alpha_string.
	For the ciphersuites specified		For the ciphersuites specified
	in <xref target="ecvrfSuites" format="default"/>, this algorithm		in <xref target="ecvrfSuites" format="default"/>, this algorithm
	is expected to find a valid curve point after approximately two atte mpts		is expected to find a valid curve point after approximately two atte mpts
	(i.e., when ctr=1) on average.		(i.e., when ctr = 1) on average.
	</t>		</t>
	<t>		<t>
	However, because the running time of algorithm depends on alpha_stri		However, because the algorithm's running time depends on alpha_strin
	ng,		g,
	this algorithm SHOULD be avoided in		this algorithm <bcp14>SHOULD</bcp14> be avoided in
	applications where it is important that		applications where it is important that
	the VRF input alpha remain secret.		the VRF input alpha remain secret.
	</t>		</t>
	<t>		<t>
	ECVRF_encode_to_curve_try_and_increment(encode_to_curve_salt, al pha_string)		ECVRF_encode_to_curve_try_and_increment(encode_to_curve_salt, al pha_string)
	</t>		</t>
	<t>		<dl spacing="normal" newline="false">
	Fixed option (specified in <xref target="ecvrfSuites" format="d		<dt>Fixed option (specified in <xref target="ecvrfSuites" format=
	efault"/>):		"default"/>):</dt>
	</t>		<dd>
	<ul empty="true" spacing="normal">		<t><br/></t>
	<li>interpret_hash_value_as_a_point - a function that attempts to		<dl spacing="normal" newline="false">
	convert a cryptographic hash value to a point on E; may output INVALID.</li>		<dt>interpret_hash_value_as_a_point:</dt><dd>a function that at
	</ul>		tempts to convert a cryptographic hash value to a point on E; may output "INVALI
	<t>		D"</dd>
	Steps:		</dl></dd></dl>
	</t>		<t>Steps:</t>
	<ol spacing="normal" type="1"><li>ctr = 0</li>		<ol spacing="normal"><li>ctr = 0</li>
	<li>encode_to_curve_domain_separator_front = 0x01</li>		<li>encode_to_curve_domain_separator_front = 0x01</li>
	<li>encode_to_curve_domain_separator_back = 0x00</li>		<li>encode_to_curve_domain_separator_back = 0x00</li>
	<li>H = "INVALID"</li>		<li>H = "INVALID"</li>
	<li>		<li>
	<t>While H is "INVALID" or H is the identity element of the elli ptic curve group:		<t>While H is "INVALID" or H is the identity element of the elli ptic curve group:
	</t>		</t>
	<ol spacing="normal" type="a"><li>ctr_string = int_to_string(ctr , 1)</li>		<ol spacing="normal" type="a"><li>ctr_string = int_to_string(ctr , 1)</li>
	<li>hash_string = Hash(suite_string || encode_to_curve_domain_ separator_front || encode_to_curve_salt || alpha_string || ctr_string || encode_ to_curve_domain_separator_back)</li>		<li>hash_string = Hash(suite_string || encode_to_curve_domain_ separator_front || encode_to_curve_salt || alpha_string || ctr_string || encode_ to_curve_domain_separator_back)</li>
	<li>H = interpret_hash_value_as_a_point(hash_string)</li>		<li>H = interpret_hash_value_as_a_point(hash_string)</li>
	<li>If H is not "INVALID" and cofactor &gt; 1, set H = cofacto r * H</li>		<li>If H is not "INVALID" and cofactor &gt; 1, set H = cofacto r * H</li>
	<li>ctr = ctr + 1</li>		<li>ctr = ctr + 1</li>
	</ol>		</ol>
	</li>		</li>
	<li>Output H</li>		<li>Output H</li>
	</ol>		</ol>
	<t>		<t>
	Note even though the loop is infinite as written, and int_to_string(		Note that even though the loop is infinite as written and int_to_str
	ctr,1) may fail when ctr reaches 256,		ing(ctr, 1) may fail when ctr reaches 256,
	interpret_hash_value_as_a_point functions specified in <xref target=		each of the options for the interpret_hash_value_as_a_point function
	"ecvrfSuites" format="default"/>		specified in <xref target="ecvrfSuites" format="default"/>
	will succeed on roughly half hash_string values. Thus the loop is ex		will succeed on roughly half hash_string values. Thus, the loop is e
	pected to stop after two iterations, and ctr is overwhelmingly unlikely (probabi		xpected to stop after two iterations, and ctr is overwhelmingly unlikely (probab
	lity about 2^-256) to reach 256.		ility about 2^-256) to reach 256.
	</t>		</t>
	</section>		</section>
	<section anchor="h2csuite" numbered="true" toc="default">		<section anchor="h2csuite" numbered="true" toc="default">
	<name>ECVRF_encode_to_curve_h2c_suite</name>		<name>ECVRF_encode_to_curve_h2c_suite</name>
	<t>The ECVRF_encode_to_curve_h2c_suite(encode_to_curve_salt, alpha_s tring) algorithm		<t>The ECVRF_encode_to_curve_h2c_suite(encode_to_curve_salt, alpha_s tring) algorithm
	implements ECVRF_encode_to_curve using one of the several		implements ECVRF_encode_to_curve using one of the several
	hash-to-curve options defined in		hash-to-curve options defined in
	<xref target="I-D.irtf-cfrg-hash-to-curve" format="default"/>.		<xref target="RFC9380" format="default"/>.
	The specific choice of the hash-to-curve option		The specific choice of the hash-to-curve option
	(called Suite ID in <xref target="I-D.irtf-cfrg-hash-to-curve" f ormat="default"/>)		(called the Suite ID in <xref target="RFC9380" format="default"/ >)
	is given by the h2c_suite_ID_string parameter.		is given by the h2c_suite_ID_string parameter.
	</t>		</t>
	<t>		<t>
	ECVRF_encode_to_curve_h2c_suite(encode_to_curve_salt, alpha_stri ng)		ECVRF_encode_to_curve_h2c_suite(encode_to_curve_salt, alpha_stri ng)
	</t>		</t>
	<t>		<dl spacing="normal" newline="false">
	Fixed option (specified in <xref target="ecvrfSuites" format="de		<dt>Fixed option (specified in <xref target="ecvrfSuites" format="d
	fault"/>):		efault"/>):</dt>
	</t>		<dd>
	<ul empty="true" spacing="normal">		<t><br/></t>
	<li>h2c_suite_ID_string - a hash-to-curve suite ID, encoded in ASC		<dl spacing="normal" newline="false">
	II (see discussion below)</li>		<dt>h2c_suite_ID_string:</dt><dd>a hash-to-curve Suite ID, enco
	</ul>		ded in ASCII (see discussion below)</dd>
	<t>		</dl>
	Steps:		</dd>
	</t>		</dl>
	<ol spacing="normal" type="1">		<t>Steps:</t>
			<ol spacing="normal">
	<li>string_to_be_hashed = encode_to_curve_salt || alpha_string</li >		<li>string_to_be_hashed = encode_to_curve_salt || alpha_string</li >
	<li>		<li>
	<t>H = encode(string_to_be_hashed)		<t>H = encode(string_to_be_hashed)</t>
	</t>
	<t>(the encode function is discussed below) </t>		<t>(the encode function is discussed below) </t>
	</li>		</li>
	<li>Output H</li>		<li>Output H</li>
	</ol>		</ol>
	<t>The encode function is provided by the hash-to-curve suite whose		<t>The encode function is provided by the hash-to-curve suite (as sp
	ID is h2c_suite_ID_string, as specified in		ecified in <xref target="RFC9380" sectionFormat="of" section="8"/>) whose ID is
	<xref target="I-D.irtf-cfrg-hash-to-curve" format="default"/>, S		h2c_suite_ID_string.
	ection 8.		The domain separation tag DST, a parameter in the hash-to-curve
	The domain separation tag DST, a parameter to the hash-to-curve		suite, <bcp14>SHALL</bcp14> be set to
	suite, SHALL be set to
	</t>		</t>
	<ul empty="true" spacing="normal">		<t indent="3">"ECVRF_" || h2c_suite_ID_string || suite_string
	<li>		</t>
	"ECVRF_" || h2c_suite_ID_string || suite_string
	</li>
	</ul>
	<t>		<t>
	where "ECVRF_" is represented as a 6-byte ASCII encoding (in hex adecimal, octets 45 43 56 52 46 5F).		where "ECVRF_" is represented as a 6-byte ASCII encoding (in hex adecimal, octets 45 43 56 52 46 5F).
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="ecvrfNonceGeneration" numbered="true" toc="default">		<section anchor="ecvrfNonceGeneration" numbered="true" toc="default">
	<name>ECVRF Nonce Generation</name>		<name>ECVRF Nonce Generation</name>
	<t>The following algorithms generate the		<t>The following algorithms generate the
	nonce value k in a deterministic pseudorandom fashion.		nonce value k in a deterministic pseudorandom fashion.
	This section specifies a number of such algorithms, which are not co mpatible with each other.		This section specifies a number of such algorithms; these algorithms are not compatible with each other.
	The choice of a particular algorithm from the options specified in t his section depends on the ciphersuite, as specified in <xref target="ecvrfSuite s" format="default"/>.</t>		The choice of a particular algorithm from the options specified in t his section depends on the ciphersuite, as specified in <xref target="ecvrfSuite s" format="default"/>.</t>
	<section anchor="nonceP256" numbered="true" toc="default">		<section anchor="nonceP256" numbered="true" toc="default">
	<name>ECVRF Nonce Generation from RFC 6979</name>		<name>ECVRF Nonce Generation from RFC 6979</name>
	<t>		<t>
	ECVRF_nonce_generation_RFC6979(SK, h_string)		ECVRF_nonce_generation_RFC6979(SK, h_string)
	</t>		</t>
			<dl spacing="normal" newline="false">
			<dt>Input:</dt>
			<dd>
			<t><br/></t>
			<dl spacing="normal" newline="false">
			<dt>SK:</dt><dd>an ECVRF secret key</dd>
			<dt>h_string:</dt><dd>an octet string</dd>
			</dl>
			</dd>
			<dt>Output:</dt>
			<dd>
			<t><br/></t>
			<dl spacing="normal" newline="false">
			<dt>k:</dt><dd>an integer nonce between 1 and q-1</dd>
			</dl>
			</dd>
			</dl>
	<t>		<t>
	Input:		The ECVRF_nonce_generation function is implemented according
	</t>		to the process specified in
	<ul empty="true" spacing="normal">		<xref target="RFC6979" sectionFormat="of" section="3.2"/>, w
	<li>SK - an ECVRF secret key</li>		here
	<li>h_string - an octet string</li>
	</ul>
	<t>
	Output:
	</t>
	<ul empty="true" spacing="normal">
	<li>k - an integer nonce between 1 and q-1</li>
	</ul>
	<t>
	The ECVRF_nonce_generation function is as specified in
	<xref target="RFC6979" format="default"/> Section 3.2 where
	</t>		</t>
	<ul empty="true" spacing="normal">		<ul spacing="normal">
	<li> Input m is set equal to h_string</li>		<li> Input m is set equal to h_string.</li>
	<li> The "suitable for DSA or ECDSA" check in step h.3 is omitted<		<li> The "suitable for DSA or ECDSA" check in Step h.3 is omitted.
	/li>		</li>
	<li> The hash function H is Hash and its output length hlen (in bi		<li> The hash function H is Hash, and its output length hlen (in b
	ts) is set as hLen*8</li>		its) is set as hLen*8 (note that hlen is not to be confused with hLen, which is
	<li> The secret key x is set equal to the VRF secret scalar x </li		used in this document to represent the length of the output of Hash in octets).<
	>		/li>
	<li> The prime q is the same as in this specification</li>		<li> The secret key x is set equal to the VRF secret scalar x.</li
	<li> qlen is the binary length of q, i.e., the smallest integer su		>
	ch that 2^qlen &gt; q (this qlen is not to be confused with qLen in this documen		<li> The prime q is the same as in this specification.</li>
	t, which is the length of q in octets)</li>		<li> qlen is the binary length of q, i.e., the smallest integer su
	<li> All the other values and primitives as defined in <xref targe		ch that 2^qlen &gt; q (this qlen is not to be confused with qLen, which is used
	t="RFC6979" format="default"/> </li>		in this document to represent the length of q in octets).</li>
			<li> All the other values and primitives are as defined in <xref t
			arget="RFC6979" format="default"/>.</li>
	</ul>		</ul>
	</section>		</section>
	<section anchor="nonce25519" numbered="true" toc="default">		<section anchor="nonce25519" numbered="true" toc="default">
	<name>ECVRF Nonce Generation from RFC 8032</name>		<name>ECVRF Nonce Generation from RFC 8032</name>
	<t> The following is from Steps 2-3 of Section 5.1.6		<t> The following is derived from Steps 2 and 3 in
	in <xref target="RFC8032" format="default"/>. To use this algori		<xref target="RFC8032" sectionFormat="of" section="5.1.6"/>. To
	thm, hLen MUST be at least 64.		use this algorithm, hLen <bcp14>MUST</bcp14> be at least 64.
	</t>		</t>
	<t>		<t>
	ECVRF_nonce_generation_RFC8032(SK, h_string)		ECVRF_nonce_generation_RFC8032(SK, h_string)
	</t>		</t>
	<t>		<dl spacing="normal" newline="false">
	Input:		<dt>Input:</dt>
	</t>		<dd>
	<ul empty="true" spacing="normal">		<t><br/></t>
	<li>SK - an ECVRF secret key</li>		<dl spacing="normal" newline="false">
	<li>h_string - an octet string</li>		<dt>SK:</dt><dd>an ECVRF secret key</dd>
	</ul>		<dt>h_string:</dt><dd>an octet string</dd>
	<t>		</dl>
	Output:		</dd>
	</t>		<dt>Output:</dt>
	<ul empty="true" spacing="normal">		<dd>
	<li>k - an integer nonce between 0 and q-1</li>		<t><br/></t>
	</ul>		<dl spacing="normal" newline="false">
	<t>		<dt>k:</dt><dd>an integer nonce between 0 and q-1</dd>
	Steps:		</dl>
	</t>		</dd>
	<ol spacing="normal" type="1"><li>hashed_sk_string = Hash(SK)</li>		</dl>
			<t>Steps:</t>
			<ol spacing="normal"><li>hashed_sk_string = Hash(SK)</li>
	<li>truncated_hashed_sk_string = hashed_sk_string[32]...hashed_sk_ string[63]</li>		<li>truncated_hashed_sk_string = hashed_sk_string[32]...hashed_sk_ string[63]</li>
	<li>k_string = Hash(truncated_hashed_sk_string || h_string)</li>		<li>k_string = Hash(truncated_hashed_sk_string || h_string)</li>
	<li>k = string_to_int(k_string) mod q</li>		<li>k = string_to_int(k_string) mod q</li>
	</ol>		</ol>
	</section>		</section>
	</section>		</section>
	<section anchor="ecvrfChallengeGeneration" numbered="true" toc="default" >		<section anchor="ecvrfChallengeGeneration" numbered="true" toc="default" >
	<name>ECVRF Challenge Generation</name>		<name>ECVRF Challenge Generation</name>
	<t>		<t>
	ECVRF_challenge_generation(P1, P2, P3, P4, P5)		ECVRF_challenge_generation(P1, P2, P3, P4, P5)
	</t>		</t>
	<t>		<dl spacing="normal" newline="false">
	Input:		<dt>Input:</dt>
	</t>		<dd>
	<ul empty="true" spacing="normal">		<t><br/></t>
	<li>P1, P2, P3, P4, P5 - EC points</li>		<dl spacing="normal" newline="false">
	</ul>		<dt>P1, P2, P3, P4, P5:</dt><dd>EC points</dd>
	<t>		</dl>
	Output:		</dd>
	</t>		<dt>Output:</dt>
	<ul empty="true" spacing="normal">		<dd>
	<li>c - challenge value, integer between 0 and 2^(8*cLen)-1</li>		<t><br/></t>
	</ul>		<dl spacing="normal" newline="false">
	<t>		<dt>c:</dt><dd>challenge value, an integer between 0 and 2^(8*cLe
	Steps:		n)-1</dd>
	</t>		</dl>
	<ol spacing="normal" type="1"><li>challenge_generation_domain_separato		</dd>
	r_front = 0x02</li>		</dl>
			<t>Steps:</t>
			<ol spacing="normal">
			<li>challenge_generation_domain_separator_front = 0x02</li>
	<li>Initialize str = suite_string || challenge_generation_domain_sep arator_front </li>		<li>Initialize str = suite_string || challenge_generation_domain_sep arator_front </li>
	<li>		<li>
	<t>for PJ in [P1, P2, P3, P4, P5]:		<t>For PJ in [P1, P2, P3, P4, P5]:
	</t>		</t>
	<t>str = str || point_to_string(PJ)		<t>str = str || point_to_string(PJ)
	</t>		</t>
	</li>		</li>
	<li>challenge_generation_domain_separator_back = 0x00</li>		<li>challenge_generation_domain_separator_back = 0x00</li>
	<li>str = str || challenge_generation_domain_separator_back</li>		<li>str = str || challenge_generation_domain_separator_back</li>
	<li>c_string = Hash(str)</li>		<li>c_string = Hash(str)</li>
	<li>truncated_c_string = c_string[0]...c_string[cLen-1]		<li>truncated_c_string = c_string[0]...c_string[cLen-1]</li>
	<!--(first cLen octets of c_string)-->
	</li>
	<li>c = string_to_int(truncated_c_string)</li>		<li>c = string_to_int(truncated_c_string)</li>
	<li>Output c</li>		<li>Output c</li>
	</ol>		</ol>
	</section>		</section>
	<section anchor="ecvrfDecodeProof" numbered="true" toc="default">		<section anchor="ecvrfDecodeProof" numbered="true" toc="default">
	<name>ECVRF Decode Proof</name>		<name>ECVRF Decode Proof</name>
	<t>		<t>
	ECVRF_decode_proof(pi_string)		ECVRF_decode_proof(pi_string)
	</t>		</t>
	<t>		<dl spacing="normal" newline="false">
	Input:		<dt>Input:</dt>
	</t>		<dd>
	<ul empty="true" spacing="normal">		<t><br/></t>
	<li>pi_string - VRF proof, octet string (ptLen+cLen+qLen octets)</li		<dl spacing="normal" newline="false">
	>		<dt>pi_string:</dt><dd>VRF proof, an octet string (ptLen+cLen+qLe
	</ul>		n octets)</dd>
	<t>		</dl>
	Output:		</dd>
	</t>		<dt>Output:</dt>
	<ul empty="true" spacing="normal">		<dd>
	<li>"INVALID", or </li>		<t><br/></t>
	<li>Gamma - a point on E</li>		<dl spacing="normal" newline="false">
	<li>		<dt>"INVALID", or</dt><dd></dd>
	c - integer between 0 and 2^(8*cLen)-1		<dt>Gamma:</dt><dd>a point on E</dd>
	</li>		<dt>c:</dt><dd>an integer between 0 and 2^(8*cLen)-1</dd>
	<li>		<dt>s:</dt><dd>an integer between 0 and q-1
	s - integer between 0 and q-1		</dd>
	</li>		</dl>
	</ul>		</dd>
	<t>		</dl>
	Steps:		<t>Steps:</t>
	</t>		<ol spacing="normal"><li>gamma_string = pi_string[0]...pi_string[ptLen
	<ol spacing="normal" type="1"><li>gamma_string = pi_string[0]...pi_str		-1]</li>
	ing[ptLen-1]</li>
	<li>c_string = pi_string[ptLen]...pi_string[ptLen+cLen-1]</li>		<li>c_string = pi_string[ptLen]...pi_string[ptLen+cLen-1]</li>
	<li>s_string = pi_string[ptLen+cLen]...pi_string[ptLen+cLen+qLen-1]< /li>		<li>s_string = pi_string[ptLen+cLen]...pi_string[ptLen+cLen+qLen-1]< /li>
	<li>Gamma = string_to_point(gamma_string)</li>		<li>Gamma = string_to_point(gamma_string)</li>
	<li>if Gamma = "INVALID" output "INVALID" and stop</li>		<li>If Gamma = "INVALID", output "INVALID" and stop</li>
	<li>c = string_to_int(c_string)</li>		<li>c = string_to_int(c_string)</li>
	<li>s = string_to_int(s_string)</li>		<li>s = string_to_int(s_string)</li>
	<li>if s &gt;= q output "INVALID" and stop</li>		<li>If s &gt;= q, output "INVALID" and stop</li>
	<li>Output Gamma, c, and s</li>		<li>Output Gamma, c, and s</li>
	</ol>		</ol>
	</section>		</section>
	<section anchor="keycheck" numbered="true" toc="default">		<section anchor="keycheck" numbered="true" toc="default">
	<name>ECVRF Validate Key</name>		<name>ECVRF Validate Key</name>
	<t>		<t>
	ECVRF_validate_key(Y)		ECVRF_validate_key(Y)
	</t>		</t>
	<t>		<dl spacing="normal" newline="false">
	Input:		<dt>Input:</dt>
	</t>		<dd>
	<ul empty="true" spacing="normal">		<t><br/></t>
	<li>Y - public key, a point on E</li>		<dl spacing="normal" newline="false">
	</ul>		<dt>Y:</dt><dd>public key, a point on E</dd>
	<t>		</dl>
	Output:		</dd>
	</t>		<dt>Output:</dt>
	<ul empty="true" spacing="normal">		<dd>
	<li>"VALID" or "INVALID"</li>		<t><br/></t>
	</ul>		<t>"VALID" or "INVALID"</t>
			</dd>
			</dl>
	<t>		<t>
	Important note: the public key Y given to this procedure MUST be a v		Important note:</t>
	alid point on E.		<t indent="3">The public key Y provided as input to this procedure <
			bcp14>MUST</bcp14> be a valid point on E.
	</t>		</t>
			<t>Steps:</t>
	<t>		<ol spacing="normal">
	Steps:
	</t>
	<ol spacing="normal" type="1">
	<li>Let Y' = cofactor*Y</li>		<li>Let Y' = cofactor*Y</li>
	<li>If Y' is the identity element of the elliptic curve group, out put "INVALID" and stop</li>		<li>If Y' is the identity element of the elliptic curve group, out put "INVALID" and stop</li>
	<li>Output "VALID"</li>		<li>Output "VALID"</li>
	</ol>		</ol>
	<t>Note that if the cofactor = 1, then Step 1 simply sets Y'=Y. In particular, for the P-256 curve, ECVRF_validate_key simply ensures that Y is not the point at infinity.</t>		<t>Note that if the cofactor = 1, then Step 1 simply sets Y'=Y. In particular, for the P-256 curve, ECVRF_validate_key simply ensures that Y is not the point at infinity.</t>
	<t>		<t>
	Any algorithm with identical input-output behavior MAY be used i n place of the above steps. For example, if the total number		Any algorithm with identical input-output behavior <bcp14>MAY</b cp14> be used in place of the above steps. For example, if the total number
	of Y values that could cause Step 2 to output "INVALID" is sma ll, it may be more efficient to simply		of Y values that could cause Step 2 to output "INVALID" is sma ll, it may be more efficient to simply
	check Y against a fixed list of such values. For example, the following algorithm MAY be used for the edwards25519 curve:		check Y against a fixed list of such values. For example, the following algorithm <bcp14>MAY</bcp14> be used for the edwards25519 curve:
	</t>		</t>
	<ol spacing="normal" type="1">		<ol spacing="normal" type="1">
	<li>PK_string = point_to_string(Y)</li>		<li>PK_string = point_to_string(Y)</li>
	<li>oneTwentySeven_string = 0x7F</li>		<li>oneTwentySeven_string = 0x7F</li>
	<li>		<li>
	<t>y_string[31] = y_string[31] &amp; oneTwentySeven_string		<t>y_string[31] = y_string[31] &amp; oneTwentySeven_string
	</t>		</t>
	<t>(this step clears the high-order bit of octet 31)</t>		<t>(this step clears the high-order bit of octet 31)</t>
	</li>		</li>
	<li>bad_pk[0] = int_to_string(0, 32)</li>		<li>bad_pk[0] = int_to_string(0, 32)</li>
	skipping to change at line 1140 ¶		skipping to change at line 1144 ¶
	<li>bad_y2 = 27073855011448406493182252872256587889368042675753135 19463743609750303402022</li>		<li>bad_y2 = 27073855011448406493182252872256587889368042675753135 19463743609750303402022</li>
	<li>bad_pk[2] = int_to_string(bad_y2, 32)</li>		<li>bad_pk[2] = int_to_string(bad_y2, 32)</li>
	<li>bad_pk[3] = int_to_string(p-bad_y2, 32)</li>		<li>bad_pk[3] = int_to_string(p-bad_y2, 32)</li>
	<li>bad_pk[4] = int_to_string(p-1, 32)</li>		<li>bad_pk[4] = int_to_string(p-1, 32)</li>
	<li>bad_pk[5] = int_to_string(p, 32)</li>		<li>bad_pk[5] = int_to_string(p, 32)</li>
	<li>bad_pk[6] = int_to_string(p+1, 32)</li>		<li>bad_pk[6] = int_to_string(p+1, 32)</li>
	<li>If y_string is in the list [bad_pk[0],...,bad_pk[6]], output " INVALID" and stop</li>		<li>If y_string is in the list [bad_pk[0],...,bad_pk[6]], output " INVALID" and stop</li>
	<li>Output "VALID"</li>		<li>Output "VALID"</li>
	</ol>		</ol>
	<t>		<t>
	(This algorithm works for the following reason. Note that ther e are 8 bad points -- namely, the points whose order is 1, 2, 4, or 8 -- on the edwards25519 curve. Their y coordinates happen to be 0 (two points of order 4), 1 (one point of order 1), bad_y2 (two points of order 8), p-bad_y2 (two points o f order 8), and p-1 (one point of order 2). They can obtained by converting the points specified in <xref target="X25519" format="default"/> to Edwards coordina tes. Thus, bad_pk[0] (of order 4), bad_pk[2] (of order 8), and bad_pk[3] (of ord er 8) each match two bad points, depending on the sign of the x-coordinate, whic h was cleared in step 3, in order to make sure that it does not affect the compa rison. bad_pk[1] (of order 1) and bad_pk[4] (of order 2) each match one bad poin t, because x-coordinate is 0 for these two points. Note that the first 5 list el ements cover the 8 bad points. However, in case the y-coordinate of the public k ey Y had not been modular reduced by p, the list also includes bad_pk[5] and bad _pk[6], which are simply bad_pk[0] and bad_pk[1] shifted by p. There is no need to shift the other bad_pk values by p (or any bad_pk values by a larger multiple of p), because their y coordinate would exceed 2^255; and we ensure that y_stri ng corresponds to an integer less than 2^255 in step 3.)		(This algorithm works for the following reason. Note that ther e are eight bad points -- namely, the points whose order is 1, 2, 4, or 8 -- on the edwards25519 curve. Their y-coordinates happen to be 0 (two points of order 4), 1 (one point of order 1), bad_y2 (two points of order 8), p-bad_y2 (two poin ts of order 8), and p-1 (one point of order 2). They can be obtained by converti ng the points specified in <xref target="X25519" format="default"/> to Edwards c oordinates. Thus, bad_pk[0] (of order 4), bad_pk[2] (of order 8), and bad_pk[3] (of order 8) each match two bad points, depending on the sign of the x-coordinat e. This sign is cleared in Step 3 in order to make sure that it does not affect the comparison. &nbsp;bad_pk[1] (of order 1) and bad_pk[4] (of order 2) each mat ch one bad point, because the x-coordinate is 0 for these two points. Note that the first five list elements cover the eight bad points. However, to cover the c ase when the y-coordinate of the public key Y has not been modular reduced by p, the list also includes bad_pk[5] and bad_pk[6], which are simply bad_pk[0] and bad_pk[1] shifted by p. There is no need to shift the other bad_pk values by p ( or any bad_pk values by a larger multiple of p), because their y-coordinates wou ld exceed 2^255, and the algorithm ensures that y_string corresponds to an integ er less than 2^255 in Step 3.)
	</t>		</t>
	</section>		</section>
	<!-- Untrusted keys -->
	</section>		</section>
	<!-- Auxiliary Functions -->
	<section anchor="ecvrfSuites" numbered="true" toc="default">		<section anchor="ecvrfSuites" numbered="true" toc="default">
	<name>ECVRF Ciphersuites</name>		<name>ECVRF Ciphersuites</name>
	<t>This document defines ECVRF-P256-SHA256-TAI as follows:		<t>This document defines ECVRF-P256-SHA256-TAI as follows:
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	suite_string = 0x01.</li>		suite_string = 0x01.</li>
	<li>		<li>
	The EC group G is the NIST P-256 elliptic curve, with curve paramete		The EC group G is the NIST P-256 elliptic curve, with the finite fie
	rs		ld and curve parameters
	as specified in <xref target="FIPS-186-4" format="default"/> (Sectio		as specified in Section 3.2.1.3 of <xref target="SP-800-186"/>
	n D.1.2.3)		and <xref target="RFC5114" sectionFormat="of" section="2.6"/>. For t
	and <xref target="RFC5114" format="default"/> (Section 2.6). For th		his group,
	is group,
	fLen = qLen = 32 and cofactor = 1.		fLen = qLen = 32 and cofactor = 1.
	</li>		</li>
	<li>		<li>
	cLen = 16.		cLen = 16.
	</li>		</li>
	<li> The key pair generation primitive is specified in		<li> The key pair generation primitive is specified in
	Section 3.2.1 of <xref target="SECG1" format="default"/> (q, B, SK, and Y in this document		Section 3.2.1 of <xref target="SECG1" format="default"/> (q, B, SK, and Y in this document
	correspond to n, G, d, and Q in Section 3.2.1 of <xref target="SECG1 " format="default"/>).		correspond to n, G, d, and Q in Section 3.2.1 of <xref target="SECG1 " format="default"/>).
	In this ciphersuite, the secret scalar x is equal to the secret key SK.		In this ciphersuite, the secret scalar x is equal to the secret key SK.
	</li>		</li>
	<li> encode_to_curve_salt = PK_string</li>		<li> encode_to_curve_salt = PK_string.</li>
	<li> The ECVRF_nonce_generation function is as specified in <xref targ et="nonceP256" format="default"/>.</li>		<li> The ECVRF_nonce_generation function is as specified in <xref targ et="nonceP256" format="default"/>.</li>
	<li>The int_to_string function is the I2OSP function specified in Sect		<li>The int_to_string function is the I2OSP function specified in <xre
	ion		f target="RFC8017" sectionFormat="of" section="4.1"/>. (This is big-endian repre
	4.1 of <xref target="RFC8017" format="default"/>. (This is big-endian re		sentation.)</li>
	presentation.)</li>		<li>The string_to_int function is the OS2IP function specified in <xre
	<li>The string_to_int function is the OS2IP function specified in Sect		f target="RFC8017" sectionFormat="of" section="4.2"/>. (This is big-endian repre
	ion		sentation.)</li>
	4.2 of <xref target="RFC8017" format="default"/>. (This is big-endian re
	presentation.)</li>
	<li>		<li>
	The point_to_string function converts a point on E to an octet strin g		The point_to_string function converts a point on E to an octet strin g
	according to the encoding specified in Section 2.3.3 of		according to the encoding specified in Section 2.3.3 of
	<xref target="SECG1" format="default"/> with point compression on.		<xref target="SECG1" format="default"/> with point compression on.
	This implies ptLen = fLen + 1 = 33.		This implies that ptLen = fLen + 1 = 33.
	(Note that certain software implementations do not introduce a		(Note that certain software implementations do not introduce a
	separate elliptic curve point type and instead directly treat the		separate elliptic curve point type and instead directly treat the
	EC point as an octet string per above encoding. When using such		EC point as an octet string per the above encoding. When using such
	an implementation, the point_to_string function		an implementation, the point_to_string function
	can be treated as the identity function.)		can be treated as the identity function.)
	</li>		</li>
	<li> The string_to_point function converts an octet string to an		<li> The string_to_point function converts an octet string to
	a point on E according to the encoding specified in Section 2.3.4 of		a point on E according to the encoding specified in Section 2.3.4 of
	<xref target="SECG1" format="default"/>. This function MUST output I NVALID if		<xref target="SECG1" format="default"/>. This function <bcp14>MUST</ bcp14> output "INVALID" if
	the octet string does not decode to a point on the curve E.		the octet string does not decode to a point on the curve E.
	</li>		</li>
	<li>		<li>
	The hash function Hash is SHA-256 as specified in <xref target="RFC6 234" format="default"/>, with hLen = 32.		The hash function Hash is SHA-256 as specified in <xref target="RFC6 234" format="default"/>, with hLen = 32.
	</li>		</li>
	<li>		<li>
	The ECVRF_encode_to_curve function is as specified in <xref target=" ecvrfH2C1" format="default"/>, with interpret_hash_value_as_a_point(s) = string_ to_point(0x02 || s).		The ECVRF_encode_to_curve function is as specified in <xref target=" ecvrfH2C1" format="default"/>, with interpret_hash_value_as_a_point(s) = string_ to_point(0x02 || s).
	</li>		</li>
	</ul>		</ul>
	<t>This document defines ECVRF-P256-SHA256-SSWU as identical to ECVRF-P2 56-SHA256-TAI, except that:		<t>This document defines ECVRF-P256-SHA256-SSWU as identical to ECVRF-P2 56-SHA256-TAI, except that
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li> suite_string = 0x02.</li>		<li> suite_string = 0x02.</li>
	<li>the ECVRF_encode_to_curve function is as specified in <xref target ="h2csuite" format="default"/>		<li>The ECVRF_encode_to_curve function is as specified in <xref target ="h2csuite" format="default"/>,
	with h2c_suite_ID_string = P256_XMD:SHA-256_SSWU_NU_		with h2c_suite_ID_string = P256_XMD:SHA-256_SSWU_NU_
	(the suite is defined in <xref target="I-D.irtf-cfrg-has		(the suite is defined in
	h-to-curve" format="default"/> Section 8.2)</li>		<xref target="RFC9380" sectionFormat="of" section="8.2"/>).</li>
	</ul>		</ul>
	<t>This document defines ECVRF-EDWARDS25519-SHA512-TAI as follows:		<t>This document defines ECVRF-EDWARDS25519-SHA512-TAI as follows:
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	suite_string = 0x03.</li>		suite_string = 0x03.</li>
	<li>		<li>
	The EC group G is the edwards25519		The EC group G is the edwards25519
	elliptic curve with parameters defined in Table 1 of		elliptic curve, with the finite field and curve parameters as define
	<xref target="RFC8032" format="default"/>.		d in
			Table 1 in <xref target="RFC8032" sectionFormat="of" section="5.1"/>
			.
	For this group, fLen = qLen = 32 and cofactor = 8.		For this group, fLen = qLen = 32 and cofactor = 8.
	</li>		</li>
	<li>		<li>
	cLen = 16.		cLen = 16.
	</li>		</li>
	<li> The secret key and generation of the secret scalar and the public		<li> The secret key and generation of the secret scalar and the public
	key are specified in Section 5.1.5 of <xref target="RFC8032" format="def		key are specified in <xref target="RFC8032" sectionFormat="of" section="
	ault"/>.</li>		5.1.5"/>.</li>
	<li> encode_to_curve_salt = PK_string</li>		<li> encode_to_curve_salt = PK_string.</li>
	<li> The ECVRF_nonce_generation function is as specified in <xref targ et="nonce25519" format="default"/>.</li>		<li> The ECVRF_nonce_generation function is as specified in <xref targ et="nonce25519" format="default"/>.</li>
	<li>The int_to_string function as specified in the first paragraph of		<li>The int_to_string function is implemented as specified in the firs
	Section 5.1.2 of <xref target="RFC8032" format="default"/>. (This is lit		t paragraph of <xref target="RFC8032" sectionFormat="of" section="5.1.2"/>. (Thi
	tle-endian representation.)</li>		s is little-endian representation.)</li>
	<li>The string_to_int function interprets the string as an integer in little-endian		<li>The string_to_int function interprets the string as an integer in little-endian
	representation.</li>		representation.</li>
	<li> The point_to_string function converts an point on E to an		<li> The point_to_string function converts a point on E to an
	octet string according to the encoding specified		octet string according to the encoding specified
	in Section 5.1.2 of <xref target="RFC8032" format="default"/>.		in <xref target="RFC8032" sectionFormat="of" section="5.1.2"/>.
	This implies ptLen = fLen = 32.		This implies that ptLen = fLen = 32.
	(Note that certain software implementations do not introduce a		(Note that certain software implementations do not introduce a
	separate elliptic curve point type and instead directly treat the		separate elliptic curve point type and instead directly treat the
	EC point as an octet string per above encoding. When using such		EC point as an octet string per the above encoding. When using such
	and implementation, the point_to_string		an implementation, the point_to_string
	function can be treated as the identity function.)		function can be treated as the identity function.)
	</li>		</li>
	<li> The string_to_point function converts an octet string to a point on E		<li> The string_to_point function converts an octet string to a point on E
	according to the encoding specified in Section 5.1.3		according to the encoding specified in <xref target="RFC8032" sectionFor
	of <xref target="RFC8032" format="default"/>. This function MUST output		mat="of" section="5.1.3"/>. This function <bcp14>MUST</bcp14> output "INVALID"
	INVALID if		if
	the octet string does not decode to a point on the curve E.		the octet string does not decode to a point on the curve E.
	</li>		</li>
	<li>		<li>
	The hash function Hash is SHA-512 as specified in <xref target="RFC6 234" format="default"/>, with hLen = 64.		The hash function Hash is SHA-512 as specified in <xref target="RFC6 234" format="default"/>, with hLen = 64.
	</li>		</li>
	<li>		<li>
	The ECVRF_encode_to_curve function is as specified in <xref target=" ecvrfH2C1" format="default"/>, with interpret_hash_value_as_a_point(s) = string_ to_point(s[0]...s[31]).		The ECVRF_encode_to_curve function is as specified in <xref target=" ecvrfH2C1" format="default"/>, with interpret_hash_value_as_a_point(s) = string_ to_point(s[0]...s[31]).
	</li>		</li>
	</ul>		</ul>
	<t>This document defines ECVRF-EDWARDS25519-SHA512-ELL2 as identical to ECVRF-EDWARDS25519-SHA512-TAI, except:		<t>This document defines ECVRF-EDWARDS25519-SHA512-ELL2 as identical to ECVRF-EDWARDS25519-SHA512-TAI, except that
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	suite_string = 0x04.		suite_string = 0x04.
	</li>		</li>
	<li>the ECVRF_encode_to_curve function is as specified in <xref target ="h2csuite" format="default"/> with		<li>The ECVRF_encode_to_curve function is as specified in <xref target ="h2csuite" format="default"/>, with
	h2c_suite_ID_string = edwards25519_XMD:SHA-512_ELL2_NU_		h2c_suite_ID_string = edwards25519_XMD:SHA-512_ELL2_NU_
	(the suite is defined in		(the suite is defined in
	<xref target="I-D.irtf-cfrg-hash-to-curve" format="default"/> Sectio n 8.5).		<xref target="RFC9380" sectionFormat="of" section="8.5"/>).
	</li>		</li>
	</ul>		</ul>
	</section>		</section>
	</section>		</section>
			<section anchor="ianacons" numbered="true" toc="default">
	<section anchor="imp" numbered="true" toc="default">		<name>IANA Considerations</name>
	<name>Implementation Status</name>		<t>This document has no IANA actions.</t>
	<t>
	Note to RFC editor: Remove before publication
	</t>
	<t>
	A reference C++ implementation of ECVRF-P256-SHA256-TAI, ECVRF-P256-SHA256-S
	SWU, ECVRF-EDWARDS25519-SHA512-TAI, and ECVRF-EDWARDS25519-SHA512-ELL2
	is available at <eref target="https://github.com/reyzin/ecvrf"/>. This imple
	mentation is neither secure nor especially efficient, but can be used to generat
	e
	test vectors.
	</t>
	<t>
	A Python implementation of an older version of ECVRF-EDWARDS25519-SHA512-E
	LL2 from the -05 version of this draft is available at <eref target="https://git
	hub.com/integritychain/draft-irtf-cfrg-vrf-05"/>.
	</t>
	<t>
	A C implementation of an older version of ECVRF-EDWARDS25519-SHA512-ELL2 f
	rom the -03 version of this draft is available at <eref target="https://github.c
	om/algorand/libsodium/tree/draft-irtf-cfrg-vrf-03/src/libsodium/crypto_vrf/ietfd
	raft03"/>.
	</t>
	<t>
	A Rust implementation of an older version of ECVRF-P256-SHA256-TAI from th
	e -05 version of this draft, as well as variants for the sect163k1 and secp256k1
	curves, is available at <eref target="https://crates.io/crates/vrf"/>.
	</t>
	<t>
	A C implementation of a variant of ECVRF-P256-SHA256-TAI from the -05 vers
	ion of this draft adapted for the secp256k1 curve is available at <eref target="
	https://github.com/aergoio/secp256k1-vrf"/>.
	</t>
	<t>
	An implementation of an earlier version of RSA-FDH-VRF (SHA-256) and
	ECVRF-P256-SHA256-TAI was
	first developed
	as a part of the NSEC5 project <xref target="I-D.vcelak-nsec5" forma
	t="default"/> and is available
	at <eref target="http://github.com/fcelda/nsec5-crypto"/>.
	</t>
	<t>
	The Key Transparency project at Google
	uses a VRF implementation that is similar to
	the ECVRF-P256-SHA256-TAI, with a few changes
	including the use of SHA-512 instead of SHA-256. Its implementation
	is available at <eref target="https://github.com/google/keytransparency/blob
	/master/core/crypto/vrf/"/>
	</t>
	<t>
	An implementation by Ryuji Ishiguro following an older version of ECVRF-EDWA
	RDS25519-SHA512-TAI from the -00 version of this draft is available at
	<eref target="https://github.com/r2ishiguro/vrf"/>.
	</t>
	<t>
	An implementation similar to ECVRF-EDWARDS25519-SHA512-ELL2 (with some chang
	es, including the use of SHA-3) is available as part of the
	CONIKS implementation in Golang at
	<eref target="https://github.com/coniks-sys/coniks-go/tree/master/crypto/vrf
	"/>.
	</t>
	<t>
	Open Whisper Systems also uses a VRF similar to
	ECVRF-EDWARDS25519-SHA512-ELL2, called VXEdDSA, and specified here
	<eref target="https://whispersystems.org/docs/specifications/xeddsa/"/>
	and here <eref target="https://moderncrypto.org/mail-archive/curves/2017/000
	925.html"/>.
	Implementations in C and Java are available at <eref target="https://github.
	com/signalapp/curve25519-java"/> and
	<eref target="https://github.com/wavesplatform/curve25519-java"/>.
	</t>
	</section>		</section>
	<section anchor="securitycons" numbered="true" toc="default">		<section anchor="securitycons" numbered="true" toc="default">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Key Generation</name>		<name>Key Generation</name>
	<t>Implementations of VRFs defined in this		<t>Implementations of the VRFs defined in this
	document MUST ensure that they generate VRF keys correctly and		document <bcp14>MUST</bcp14> ensure that they generate VRF keys correctly an
	using good randomness. However, in some applications keys may be generated b		d
	y an adversary who		use good randomness. However, in some applications, keys may be generated by
			an adversary who
	does not necessarily implement this document. We now discuss the implication s of this possibility.		does not necessarily implement this document. We now discuss the implication s of this possibility.
	</t>		</t>
	<section anchor="untrustedkeys" numbered="true" toc="default">		<section anchor="untrustedkeys" numbered="true" toc="default">
	<name>Uniqueness and collision resistance under malicious key generati on</name>		<name>Uniqueness and Collision Resistance under Malicious Key Generati on</name>
	<t>See <xref target="secdef" format="default"/> for definitions of uni queness and collision resistance properties.		<t>See <xref target="secdef" format="default"/> for definitions of uni queness and collision resistance properties.
	</t>		</t>
	<t>The RSA-FDH-VRF satisfies only the "trusted" variants of uniqueness		<t>The RSA-FDH-VRF satisfies only the "trusted" variants of uniqueness
	and collision resistance.		and collision resistance.
	Thus, for RSA-FDH-VRF, uniqueness and collision resistance may not hold if t		Thus, for the RSA-FDH-VRF, uniqueness and collision resistance may not hold
	he keys are generated adversarially		if the keys are generated adversarially
	(specifically, if the RSA function specified in the public key is not biject		(specifically, if the RSA function specified in the public key is not biject
	ive because the modulus n or the exponent e are chosen not in compliance with <x		ive because the modulus n or the exponent e are chosen without complying with <x
	ref target="RFC8017" format="default"/>); thus,		ref target="RFC8017" format="default"/>); thus, the
	RSA-FDH-VRF defined in this document does not have "full uniqueness" and "fu		RSA-FDH-VRF as defined in this document does not have "full uniqueness" and
	ll collision resistance".		"full collision resistance".
	Therefore, if malicious key generation is a concern, the		Therefore, if malicious key generation is a concern, the
	RSA-FDH-VRF has to be enhanced by additional cryptographic checks (such as z		RSA-FDH-VRF has to be enhanced by additional cryptographic checks (such as z
	ero-knowledge proofs)		ero-knowledge proofs) to ensure
	that its public key has the right form. These enhancements are left for fut		that its public key has the right form. These enhancements are left for fut
	ure specification.		ure specifications.
	</t>		</t>
			<t>For the ECVRF, the Verifier <bcp14>MUST</bcp14> obtain E and B from
	<t>For the ECVRF, the Verifier MUST obtain E and B from a trusted sour		a trusted source, such as a ciphersuite specification, rather than from the Pro
	ce, such as a ciphersuite specification, rather than from the prover. If the ver		ver. If the Verifier does so, then the
	ifier does so, then the
	ECVRF		ECVRF
	satisfies the "full uniqueness", ensuring uniqueness even under malicious ke		satisfies "full uniqueness", ensuring uniqueness even under malicious key ge
	y generation. The ECVRF also satisfies "trusted collision resistance".		neration. The ECVRF also satisfies "trusted collision resistance".
	It additionally satisfies "full collision resistance" if validate_key parame		It additionally satisfies "full collision resistance" if the validate_key pa
	ter given to the ECVRF_verify is TRUE. This setting of ECVRF_verify ensures coll		rameter given to ECVRF_verify is TRUE. This setting of ECVRF_verify ensures coll
	ision resistance under malicious key generation.		ision resistance under malicious key generation.
	</t>		</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Pseudorandomness under malicious key generation</name>		<name>Pseudorandomness under Malicious Key Generation</name>
	<t> Without good randomness, the "pseudorandomness"		<t> Without good randomness, the "pseudorandomness"
	properties of the VRF (defined in <xref target="pseudodef" format="default"/ >) may not hold. Note that it is not possible to guarantee		properties of the VRF (defined in <xref target="pseudodef" format="default"/ >) may not hold. Note that it is not possible to guarantee
	pseudorandomness in the face of adversarially generated VRF keys. This is		pseudorandomness in the face of adversarially generated VRF keys. This is
	because an adversary can always use bad randomness to generate the VRF keys,		because an adversary can always use bad randomness to generate the VRF keys,
	and thus, the VRF output may not be pseudorandom.		and thus the VRF output may not be pseudorandom.
	</t>		</t>
	</section>		</section>
	<section anchor="unpredres" numbered="true" toc="default">		<section anchor="unpredres" numbered="true" toc="default">
	<name>Unpredictability under malicious key generation</name>		<name>Unpredictability under Malicious Key Generation</name>
	<t>		<t>
	Unpredictability under malicious key generation (defined in <xref		Unpredictability under malicious key generation (defined in <xref
	target="unpreddef" format="default"/>) does not hold for the RSA-FDH-VRF. (Speci		target="unpreddef" format="default"/>) does not hold for the RSA-FDH-VRF. (Speci
	fically, the VRF output may be predictable if the RSA function specified in the		fically, the VRF output may be predictable if the RSA function specified in the
	public key is far from bijective because the modulus n or the exponent e are cho		public key is far from bijective because the modulus n or the exponent e are cho
	sen not in compliance with <xref target="RFC8017" format="default"/>.) If unpre		sen without complying with <xref target="RFC8017" format="default"/>.) If unpre
	dictability under malicious key generation is desired, the		dictability under malicious key generation is desired, the
	RSA-FDH-VRF has to be enhanced by additional cryptographic checks		RSA-FDH-VRF has to be enhanced by additional cryptographic checks
	(such as zero-knowledge proofs)		(such as zero-knowledge proofs) to ensure
	that its public key has the right form. These enhancements are le		that its public key has the right form. These enhancements are le
	ft for future specification.		ft for future specifications.
	</t>		</t>
	<t>		<t>
	Unpredictability under malicious key generation holds for the ECVR F if validate_key parameter given to the ECVRF_verify is TRUE.		Unpredictability under malicious key generation holds for the ECVR F if the validate_key parameter given to ECVRF_verify is TRUE.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="seclevel" numbered="true" toc="default">		<section anchor="seclevel" numbered="true" toc="default">
	<name>Security Levels</name>		<name>Security Levels</name>
	<t>		<t>
	As shown in <xref target="PWHVNRG17" format="default"/>, RSA-FDH-VRF satisfies the trusted uniqueness property unconditionally. The security level o f the RSA-FDH-VRF, measured in bits, for the other two properties is as follows (in the random oracle model for the functions MGF1 and Hash):		As shown in <xref target="PWHVNRG17" format="default"/>, the RSA-FDH -VRF satisfies the trusted uniqueness property unconditionally. The security lev el of the RSA-FDH-VRF, measured in bits, for the other two properties is as foll ows (in the random oracle model for the functions MGF1 and Hash):
	</t>		</t>
	<ul>		<dl newline="false" spacing="normal">
	<li>For trusted collision resistance: approximately 8*min(k/2, h		<dt>For trusted collision resistance:</dt><dd>approximately 8*mi
	Len/2) (as shown in <xref target="PWHVNRG17" format="default"/>).</li>		n(k/2, hLen/2) (as shown in <xref target="PWHVNRG17" format="default"/>).</dd>
	<li>For selective pseudorandomness: approximately as strong as t		<dt>For selective pseudorandomness:</dt><dd>approximately as str
	he security, in bits, of the RSA problem for the key (n, e) (as shown in <xref t		ong as the security, in bits, of the RSA problem for the key (n, e) (as shown in
	arget="GNPRVZ15" format="default"/>).</li>		<xref target="GNPRVZ15" format="default"/>).</dd>
	</ul>		</dl>
	<t>		<t>
	As shown in <xref target="PWHVNRG17" format="default"/>, the securit y level of the ECVRF, measured in bits, is as follows (in the random oracle mode l for the functions Hash and ECVRF_encode_to_curve):		As shown in <xref target="PWHVNRG17" format="default"/>, the securit y level of the ECVRF, measured in bits, is as follows (in the random oracle mode l for the functions Hash and ECVRF_encode_to_curve):
	</t>		</t>
	<ul>		<dl newline="false" spacing="normal">
	<li>For uniqueness (both trusted and full): approximately 8*min(		<dt>For uniqueness (both trusted and full):</dt><dd>approximatel
	qLen, cLen).</li>		y 8*min(qLen, cLen).</dd>
	<li>For collision resistance (trusted or full, depending on whet		<dt>For collision resistance (trusted or full, depending on whet
	her validation is performed as explained in <xref target="untrustedkeys" format=		her validation is performed as explained in <xref target="untrustedkeys" format=
	"default"/>): approximately 8*min(qLen/2, hLen/2).</li>		"default"/>):</dt><dd><br/>approximately 8*min(qLen/2, hLen/2).</dd>
	<li>For the selective pseudorandomness property: approximately a		<dt>For selective pseudorandomness:</dt><dd>approximately as str
	s strong as the security, in bits, of the decisional Diffie-Hellman problem in t		ong as the security, in bits, of the decisional Diffie-Hellman problem in the gr
	he group G (which is at most 8*qLen/2).</li>		oup G (which is at most 8*qLen/2).</dd>
	</ul>		</dl>
	<t>See <xref target="secdef" format="default"/> for the definitions		<t>See <xref target="secdef" format="default"/> for the definitions
	of these security properties. See <xref target="prsecurity" format="default"/> f		of these security properties and <xref target="prsecurity" format="default"/> fo
	or the discussion of full pseudorandomness.</t>		r the discussion of full pseudorandomness.</t>
	</section>		</section>
	<section anchor="prsecurity" numbered="true" toc="default">		<section anchor="prsecurity" numbered="true" toc="default">
	<name>Selective vs. Full Pseudorandomness</name>		<name>Selective vs. Full Pseudorandomness</name>
	<t><xref target="PWHVNRG17" format="default"/> presents cryptographic re ductions to an		<t><xref target="PWHVNRG17" format="default"/> presents cryptographic re ductions to an
	underlying hard problem (namely, the RSA problem for RSA-FDH-VRF		underlying hard problem (namely, the RSA problem for the RSA-FDH-VRF
	and the Decisional Diffie-Hellman problem for the ECVRF)		and the decisional Diffie-Hellman problem for the ECVRF)
	to prove that the VRFs specified in this		to prove that the VRFs specified in this
	document possess not only selective pseudorandomness, but also		document possess not only selective pseudorandomness but also
	full pseudorandomness		full pseudorandomness
	(see <xref target="pseudodef" format="default"/> for an explanation of these notions).		(see <xref target="pseudodef" format="default"/> for an explanation of these notions).
	However, the cryptographic reductions are tighter for selective		However, the cryptographic reductions are tighter for selective
	pseudorandomness than for full pseudorandomness. Specifically, the approxima te provable security level, measured in bits,		pseudorandomness than for full pseudorandomness. Specifically, the approxima te provable security level, measured in bits,
	for full pseudorandomness may be obtained from the provable security level f or selective pseudorandomness (given in <xref target="seclevel" format="default" />) by subtracting the binary logarithm		for full pseudorandomness may be obtained from the provable security level f or selective pseudorandomness (given in <xref target="seclevel" format="default" />) by subtracting the binary logarithm
	of the number of proofs produced for a given secret key. This holds for both the RSA-FDH-VRF and the ECVRF.		of the number of proofs produced for a given secret key. This holds for both the RSA-FDH-VRF and the ECVRF.
	</t>		</t>
	<t>While no known attacks against full pseudorandomness are stronger tha n similar attacks against selective pseudorandomness, some applications may be c oncerned about tightness of cryptographic		<t>While no known attacks against full pseudorandomness are stronger tha n similar attacks against selective pseudorandomness, some applications may be c oncerned about tightness of cryptographic
	reductions to ensure specific levels of provable security. Such applications may consider the following three options:		reductions to ensure specific levels of provable security. Such applications may consider the following three options:
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>They may limit the number of proofs produced for a given secret ke y, to reduce the loss in the provable security level.</li>		<li>They may limit the number of proofs produced for a given secret ke y, to reduce the loss in the provable security level.</li>
	<li>They may work to ensure that selective pseudorandomness is suffici ent for		<li>They may work to ensure that selective pseudorandomness is suffici ent for
	the application. That is, they may design the application in such a way that		the application. That is, they may design the application such that
	pseudorandomness of outputs matters only for inputs that are chosen		pseudorandomness of outputs matters only for inputs that are chosen
	independently of the VRF key.		independently of the VRF key.
	</li>		</li>
	<li>They		<li>They
	may increase		may increase
	security parameters to make up for the loose security reduction.		security parameters to make up for lossy security reductions.
	For RSA-FDH-VRF, this means increasing the RSA key length. For		For the RSA-FDH-VRF, this means increasing the RSA key length. For the
	ECVRF, this means increasing the cryptographic strength of the EC group		ECVRF, this means increasing the cryptographic strength of the EC group
	G by specifying a new ciphersuite.		G by specifying a new ciphersuite.
	</li>		</li>
	</ul>		</ul>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Proper pseudorandom nonce for ECVRF</name>		<name>Proper Pseudorandom Nonce for the ECVRF</name>
	<t>		<t>
	The security of the ECVRF defined in this document relies on the		The security of the ECVRF defined in this document relies on the
	fact that the nonce k used in the ECVRF_prove algorithm is		fact that the nonce k used in the ECVRF_prove algorithm is
	chosen uniformly and pseudorandomly modulo q, and is unknown to the adversar y.		chosen uniformly and pseudorandomly modulo q and is unknown to the adversary .
	Otherwise, an adversary may be able to recover		Otherwise, an adversary may be able to recover
	the VRF secret scalar x (and thus break pseudorandomness of the VRF)		the VRF secret scalar x (and thus break pseudorandomness of the VRF)
	after observing several valid VRF proofs pi, using, for example, techniques described in		after observing several valid VRF proofs pi, using, for example, techniques described in
	<xref target="BreHen19" format="default"/>. The nonce generation methods		<xref target="BreHen19" format="default"/>. The nonce generation methods
	specified in the ECVRF ciphersuites of <xref target="ecvrfSuites" format="de fault"/>		specified in the ECVRF ciphersuites of <xref target="ecvrfSuites" format="de fault"/>
	are designed with this requirement in mind.		are designed with this requirement in mind.
	</t>		</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Side-channel attacks</name>		<name>Side-Channel Attacks</name>
	<t>Side channel attacks on cryptographic primitives are an important iss		<t>Side-channel attacks on cryptographic primitives are an important iss
	ue.		ue.
	Implementers should		Implementers should
	take care to avoid side-channel attacks that leak information about		take care to avoid side-channel attacks that leak information about
	the VRF secret key SK (and the nonce k used in the ECVRF), which is		the VRF secret key SK (and the nonce k used in the ECVRF), which is
	used in VRF_prove.		used in VRF_prove.
	In most applications, VRF_proof_to_hash and VRF_verify		In most applications, the VRF_proof_to_hash and VRF_verify
	algorithms take only inputs that are public, and thus side channel		algorithms take only inputs that are public, and thus side-channel
	attacks are typically not a concern for these algorithms.		attacks are typically not a concern for these algorithms.
	</t>		</t>
	<t>		<t>
	The VRF input alpha may be also a sensitive input to VRF_prove and may		The VRF input alpha may also be a sensitive input to VRF_prove and may
	need to be protected against side channel attacks.		need to be protected against side-channel attacks.
	Below we discuss one particular class of such attacks: timing attacks that c		Below, we discuss one particular class of such attacks: timing attacks that
	an		can
	be used to leak information about the VRF input alpha.		be used to leak information about the VRF input alpha.
	</t>		</t>
	<t>The ECVRF_encode_to_curve_try_and_increment algorithm defined in		<t>The ECVRF_encode_to_curve_try_and_increment algorithm (defined in
	<xref target="ecvrfH2C1" format="default"/> SHOULD NOT be used in applicatio		<xref target="ecvrfH2C1" format="default"/>) <bcp14>SHOULD NOT</bcp14> be us
	ns where		ed in applications where
	the VRF input alpha is secret and is hashed by the VRF on-the-fly.		the VRF input alpha is secret and is hashed by the VRF on the fly.
	This is because the algorithm's running time depends		This is because the algorithm's running time depends
	on the VRF input alpha, and thus creates a timing channel that		on the VRF input alpha and thus creates a timing channel that
	can be used to learn information about alpha.		can be used to learn information about alpha.
	That said, for most inputs the amount of information obtained from		That said, for most inputs, the amount of information obtained from
	such a timing attack is likely to be small (1 bit, on average), since the al gorithm		such a timing attack is likely to be small (1 bit, on average), since the al gorithm
	is expected to find a valid curve point after only two attempts.		is expected to find a valid curve point after only two attempts.
	However, there might be inputs which cause the algorithm to make many attemp ts		However, there might be inputs that cause the algorithm to make many attempt s
	before it finds a valid curve point; for such inputs, the information leaked		before it finds a valid curve point; for such inputs, the information leaked
	in a timing attack will be more than 1 bit.		in a timing attack will be more than 1 bit.
	</t>		</t>
	<t>ECVRF-P256-SHA256-SSWU and ECVRF-EDWARDS25519-SHA512-ELL2 can be made to		<t>ECVRF-P256-SHA256-SSWU and ECVRF-EDWARDS25519-SHA512-ELL2 can be made to
	run in time independent of alpha, following recommendations in <xref tar get="I-D.irtf-cfrg-hash-to-curve" format="default"/>.		run in time that is independent of alpha, following recommendations in < xref target="RFC9380" format="default"/>.
	</t>		</t>
	<t>		<t>
	</t>		</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Proofs provide no secrecy for the VRF input</name>		<name>Proofs Provide No Secrecy for the VRF Input</name>
	<t>The VRF proof pi is not designed to provide secrecy and, in general,		<t>The VRF proof pi is not designed to provide secrecy and, in general,
	may reveal the VRF input alpha.		may reveal the VRF input alpha.
	Anyone who knows PK and pi is able to perform an offline		Anyone who knows PK and pi is able to perform an offline
	dictionary attack to search for alpha, by verifying guesses for alpha us ing VRF_verify.		dictionary attack to search for alpha, by verifying guesses for alpha us ing VRF_verify.
	This is in contrast to the VRF hash output beta which, without the proof , is pseudorandom		This is in contrast to the VRF hash output beta, which, without the proo f, is pseudorandom
	and thus is designed to reveal no information about alpha.		and thus is designed to reveal no information about alpha.
	</t>		</t>
	</section>		</section>
	<section anchor="prehash" numbered="true" toc="default">		<section anchor="prehash" numbered="true" toc="default">
	<name>Prehashing</name>		<name>Prehashing</name>
	<t>The VRFs specified in this document allow for read-once access to		<t>The VRFs specified in this document allow for read-once access to
	the input alpha for both signing and verifying. Thus, additional		the input alpha for both signing and verifying. Thus, additional
	prehashing of alpha (as specified, for example, in		prehashing of alpha (as specified, for example, in
	<xref target="RFC8032" format="default"/> for EdDSA signatures) is not n eeded,		<xref target="RFC8032" format="default"/> for Edwards-curve Digital Sign ature Algorithm (EdDSA) signatures) is not needed,
	even for applications that need to handle long alpha or		even for applications that need to handle long alpha or
	to support the		to support the
	Initialize-Update-Finalize (IUF) interface (in such an interface,		Initialize-Update-Finalize (IUF) interface (in such an interface,
	alpha is not supplied		alpha is not supplied
	all at once, but rather in pieces by a sequence of calls to Update).		all at once, but rather in pieces by a sequence of calls to Update).
	The ECVRF, in particular, uses alpha only in		The ECVRF, in particular, uses alpha only in
	ECVRF_encode_to_curve. The curve point H becomes the representative		ECVRF_encode_to_curve. The curve point H becomes the representative
	of alpha thereafter.</t>		of alpha thereafter.</t>
	</section>		</section>
	<section anchor="domainsep" numbered="true" toc="default">		<section anchor="domainsep" numbered="true" toc="default">
	<name>Hash function domain separation</name>		<name>Hash Function Domain Separation</name>
	<t>		<t>
	Hashing is used for different purposes in the two VRFs. Specifically, i n the RSA-FDH-VRF, hashing is used in MGF1 and in proof_to_hash; in the ECVRF, h ashing is used in encode_to_curve, nonce_generation, challenge_generation, and p roof_to_hash. The		Hashing is used for different purposes in the two VRFs. Specifically, i n the RSA-FDH-VRF, hashing is used in MGF1 and in proof_to_hash; in the ECVRF, h ashing is used in encode_to_curve, nonce_generation, challenge_generation, and p roof_to_hash. The
	theoretical analysis treats each of these functions as a separate hash function, modeled as a random oracle.		theoretical analysis treats each of these functions as a separate hash function, modeled as a random oracle.
	This analysis still holds even if the same hash function is used, as lo ng as the four		This analysis still holds even if the same hash function is used, as lo ng as the
	inputs given to the hash function for a given SK and alpha are overwhel mingly unlikely		inputs given to the hash function for a given SK and alpha are overwhel mingly unlikely
	to equal each other or to any inputs given to the hash function for the same SK and		to be equal to each other or to any inputs given to the hash function f or the same SK and
	different alpha. This is indeed the case for the RSA-FDH-VRF defined in this document, because the second octets		different alpha. This is indeed the case for the RSA-FDH-VRF defined in this document, because the second octets
	of the input to the hash function used in MGF1 and in proof_to_hash are different.		of the inputs to the hash function used in MGF1 and in proof_to_hash ar e different.
	</t>		</t>
	<t>		<t>
	This is also the case for the ECVRF ciphersuites defined in this docume nt, because:		This is also the case for the ECVRF ciphersuites defined in this docume nt, because
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>inputs to the hash function used during nonce_generation are unlik ely to equal		<li>Inputs to the hash function used in nonce_generation are unlikely to equal
	inputs used in encode_to_curve, proof_to_hash, and challenge_generatio n. This		inputs used in encode_to_curve, proof_to_hash, and challenge_generatio n. This
	follows since nonce_generation inputs a secret to the hash function th		follows, since nonce_generation inputs a secret to the hash function t
	at is not used by		hat is not used by
	honest parties as input to any other hash function, and is not availab		honest parties as input to any other hash function and is not availabl
	le to the adversary.</li>		e to the adversary.</li>
	<li>the second octets of the inputs to the hash function used in		<li>The second octets of the inputs to the hash function used in
	proof_to_hash, challenge_generation, and encode_to_curve_try_and_incre ment		proof_to_hash, challenge_generation, and encode_to_curve_try_and_incre ment
	are all different.</li>		are all different.</li>
	<li>the last octet of the input to the hash function used in		<li>The last octet of the inputs to the hash function used in
	proof_to_hash, challenge_generation, and encode_to_curve_try_and_incre		proof_to_hash, challenge_generation, and encode_to_curve_try_and_incre
	ment is always zero,		ment is always zero
	and therefore different from the last octet of the input to the hash f		and is therefore different from the last octet of the input to the has
	unction used in ECVRF_encode_to_curve_h2c_suite,		h function used in ECVRF_encode_to_curve_h2c_suite,
	which is set equal to the nonzero length of the domain separation tag		which is set equal to the nonzero length of the domain separation tag
	by <xref target="I-D.irtf-cfrg-hash-to-curve" format="default"/>.</li>		per <xref target="RFC9380" format="default"/>.</li>
	</ul>		</ul>
	</section>		</section>
	<section anchor="salt" numbered="true" toc="default">		<section anchor="salt" numbered="true" toc="default">
	<name>Hash function salting</name>		<name>Hash Function Salting</name>
	<t>		<t>
	In case a hash collision is found, in order to make it more difficult fo r the adversary to exploit such a collision, the MGF1 function for the RSA-FDH-V RF and ECVRF_encode_to_curve function for the ECVRF use a public value in additi on to alpha (as a so-called salt). This value is determined by the ciphersuite. For the ciphersuites defined in this document, it is set equal to the string rep resentation of the RSA modulus and EC public key, respectively. Implementations that do not use one of the ciphersuites (see <xref target="futureproofing" forma t="default" />) MAY use a different salt. For example, if a group of public keys to share the same salt, then the hash of the VRF input alpha will be the same f or the entire group of public keys, which may aid in some protocol that uses the VRF.		If a hash collision is found, in order to make it more difficult for the adversary to exploit such a collision, the MGF1 function for the RSA-FDH-VRF an d the ECVRF_encode_to_curve function for the ECVRF use a public value in additio n to alpha (as a so-called salt). This value is determined by the ciphersuite. F or the ciphersuites defined in this document, it is set equal to the string repr esentation of the RSA modulus and EC public key, respectively. Implementations t hat do not use one of the ciphersuites (see <xref target="futureproofing" format ="default" />) <bcp14>MAY</bcp14> use a different salt. For example, if a group of public keys shares the same salt, then the hash of the VRF input alpha will b e the same for the entire group of public keys; this can be helpful for some pro tocols that use the VRF.
	</t>		</t>
	</section>		</section>
	<section anchor="futureproofing" numbered="true" toc="default">		<section anchor="futureproofing" numbered="true" toc="default">
	<name>Futureproofing</name>		<name>Futureproofing</name>
	<t>If future designs need to specify variants (e.g., additional ciphersu ites) of the RSA-FDH-VRF or the ECVRF in this document,		<t>If future designs need to specify variants (e.g., additional ciphersu ites) of the RSA-FDH-VRF or the ECVRF as defined in this document,
	then, to avoid the possibility		then, to avoid the possibility
	that an adversary can obtain a VRF output under one variant, and the n claim it was obtained under		that an adversary can obtain a VRF output under one variant and then claim it was obtained under
	another variant,		another variant,
	they should specify a different suite_string constant. The suite_stri		they should specify a different suite_string constant. The suite_stri
	ng constants in this document are all single octets; if a future suite_string co		ng constants discussed in this document are all single octets; if a future suite
	nstant is longer than one octet, then it should start with a different octet tha		_string constant is longer than one octet, then it should start with a different
	n the suite_string constants in this document. Then, for the RSA-FDH-VRF, the in		octet than the suite_string constants discussed in this document. Then, for the
	puts to the hash function used in MGF1 and proof_to_hash will be different from		RSA-FDH-VRF, the inputs to the hash function used in MGF1 and proof_to_hash wil
	other ciphersuites.		l be different from other ciphersuites.
	For the ECVRF, the inputs		For the ECVRF, the inputs to the
	ECVRF_encode_to_curve hash function used in producing H are then guarant eed to be different from other		ECVRF_encode_to_curve hash function used in producing H are then guarant eed to be different from other
	ciphersuites; since all the other hashing done by the prover		ciphersuites; since all the other hashing done by the Prover
	depends on H, inputs to all the hash functions used by the prover will a		depends on H, inputs to all the hash functions used by the Prover will a
	lso be		lso be
	different from other ciphersuites as long as ECVRF_encode_to_curve is co llision resistant.		different from other ciphersuites as long as ECVRF_encode_to_curve is co llision resistant.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section numbered="true" toc="default">
	<name>Change Log</name>
	<t>
	Note to RFC Editor: if this document does not obsolete an existing R
	FC,
	please remove this appendix before publication as an RFC.
	</t>
	<ul empty="true" spacing="normal">
	<!--<t>
	draft-goldbe-vrf-00 - Forked this document from draft-vcelak
	-nsec5-04.
	Cleaned up the definitions of VRF algorithms.
	Added security definitions for VRF and security consideratio
	ns.
	Parameterized ECVRF so it could support curves other than
	P-256 and Ed25519.
	</t>
	<t>
	draft-goldbe-vrf-01 - Fixed ECVRF to work when cofactor > 1.
	Changed ECVRF_proof_to_hash(pi) so that it outputs a value r
	aised
	to the cofactor and then processed by the cryptographic hash
	function Hash.
	Included the VRF public key Y as input to the hash function
	ECVRF_hash_to_curve1.
	Cleaned up ciphersuites and ECVRF description so that it wor
	ks with
	EC point encodings for both P256 and Ed25519 curves.
	Added ECVRF_validate_key so that ECVRF can satisfy "full
	uniqueness" and "full collision" resistance.
	Updated implementation status.
	Added "an additional pseudorandomness property" to security
	definitions.
	</t>-->
	<li> 00 - Forked this document from draft-goldbe-vrf-01.</li>
	<li> 01 - Minor updates, mostly highlighting TODO items.</li>
	<li> 02 - Added specification of elligator2 for Curve25519, along
	with ciphersuites for ECVRF-ED25519-SHA512-Elligator.
	Changed
	ECVRF-ED25519-SHA256 suite_string to ECVRF-ED25519-SHA512. (This
	change
	made because Ed25519 in <xref target="RFC8032" format="default"/
	> signatures
	use SHA512 and not SHA256.)
	Made ECVRF nonce generation a separate component, so that nonces
	are deterministic.
	In ECVRF proving, changed + to - (and made corresponding
	verification changes) in order to be consistent with EdDSA and E
	CDSA.
	Highlighted that ECVRF_hash_to_curve acts like a prehash.
	Added "suites" variable to ECVRF for futureproofing.
	Ensured domain separation for hash functions by modifying hash_p
	oints and added
	discussion about domain separation.
	Updated todos in the "additional pseudorandomness property"
	section. Added a discussion of secrecy into security considerati
	ons.
	Removed B and PK=Y from ECVRF_hash_points because they are alrea
	dy present
	via H, which is computed via hash_to_curve using the suite_strin
	g (which identifies B) and Y.</li>
	<li> 03 - Changed Ed25519 conversions to little-endian, to match RFC 803
	2; added simple key validation for Ed25519; added Simple SWU cipher suite; clar
	ified Elligator and removed the extra x0 bit, to make Montgomery and Edwards Ell
	igator the same; added domain separation for RSA VRF; improved notation througho
	ut; added nonce generation as a section; changed counter in try-and-increment fr
	om four bytes to one, to avoid endian issues; renamed try-and-increment ciphersu
	ites to -TAI; added qLen as a separate parameter; changed output length to hLen
	for ECVRF, to match RSAVRF; made Verify return beta so unverified proofs don't e
	nd
	up in proof_to_hash; added test vectors.</li>
	<li> 04 - Clarified handling of optional arguments x and PK in ECVRF_pro
	ve. Edited implementation status to bring it up to date.</li>
	<li> 05 - Renamed ed25519 into the more commonly used edwards25519. Corr
	ected ECVRF_nonce_generation_RFC6979 (thanks to
	Gorka Irazoqui Apecechea and Mario Cao Cueto for finding the
	problem) and corresponding test vectors for the P256 suites. Added a reference
	to the Rust implementation.</li>
	<li> 06 - Made some variable names more descriptive. Added a few impleme
	ntation references.</li>
	<li> 07 - Incorporated hash-to-curve draft by reference to replace our o
	wn Elligator2 and Simple SWU. Clarified discussion of EC parameters and function
	s. Added a 0 octet to all hashing to enforce domain separation from hashing done
	inside hash-to-curve.</li>
	<li> 08 - Incorporated suggestions from crypto panel review by Chloe Mar
	tindale. Changed Reyzin's affiliation. Updated references.</li>
	<li> 09 - Added a note to remove the implementation page before publicat
	ion.</li>
	<li> 10 - Added a check in ECVRF_decode_proof to ensure that s is reduce
	d mod q. Connected security properties (Section 3) and security considerations (
	Section 7) with more cross-references. </li>
	<li> 11 - Processed last call comments. Clarified various notation, incl
	uding lengths of various parameters for ECVRF; added error handling to RSA-FDH-V
	RF; added security levels section; clarified full vs trusted uniqueness and full
	vs selective pseudorandomness; added RSA ciphersuites; made key validation clea
	rer; renamed hash_to_curve to encode_to_curve to be consistent with the hash_to_
	curve draft; allowed a more general salt in hashing, added the public key as inp
	ut to ECVRF_challenge_generation, and added an explanation about the salt.</li>
	<li> 12 - Added k_string to edwards25519 test vectors</li>
	<li> 13 - Clarified key validation for edwards25519 and addressed IRTF C
	hair comments</li>
	<li> 14 - Addressed IRSG review comments, which resulted in a substantia
	l reworking of section 3.</li>
	<li> 15 - Added RSA-FDH-VRF test vectors.</li>
	</ul>
	</section>
	<section numbered="true" toc="default">
	<name>Contributors</name>
	<t>
	This document would not be possible without the work of
	Moni Naor,
	Sachin Vasant, and
	Asaf Ziv. Chloe Martindale provided a thorough cryptographer's revie
	w.
	Liliya Akhmetzyanova, Tony Arcieri, Gary Belvin, Mario Cao Cueto, Br
	ian Chen, Sergey Gorbunov, Shumon Huque, Gorka Irazoqui Apecechea, Marek Jankows
	ki,
	Burt Kaliski, Mallory Knodel, David C. Lawerence, Derek Ting-Haye Le
	ung, Antonio Marcedone, Piotr Nojszewski, Chris Peikert, Colin Perkins, Trevor P
	errin, Sam Scott,
	Stanislav Smyshlyaev, Adam Suhl, Nick Sullivan, Christopher Wood, J
	iayu Xu, and Annie Yousar provided
	valuable input to this draft. Christopher Wood, Malte Thomsen, Marcu
	s Rasmussen, and Tobias Vestergaard provided independent verification of the tes
	t vectors. Riad Wahby helped this document align with draft-irtf-cfrg-hash-to-cu
	rve.
	</t>
	</section>
	</middle>		</middle>
	<back>		<back>
	<!-- References Section -->
	<!--
	Section 4.7f of [RFC2223bis] specifies the requirements for the
	references sections. In particular, there MUST be separate lists of
	normative and informative references, each in a separate section.
	The style SHOULD follow that of recently published RFCs.
	In general, each normative reference SHOULD reference the most recent
	version of the specification in question.
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references>		<references>
	<name>Normative References</name>		<name>Normative References</name>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
	FC.8174.xml"/>		19.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	FC.8017.xml"/>		174.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	FC.5114.xml"/>		017.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
	FC.6234.xml"/>		114.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
	FC.8032.xml"/>		234.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	FC.6979.xml"/>		032.xml"/>
	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-irtf-cf		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
	rg-hash-to-curve.xml"/>		979.xml"/>
	<reference anchor="FIPS-186-4" target="https://csrc.nist.gov/publication		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	s/detail/fips/186/4/final">		380.xml"/>
			<reference anchor="SP-800-186" target="https://nvlpubs.nist.gov/nistpubs
			/SpecialPublications/NIST.SP.800-186.pdf">
	<front>		<front>
	<title>Digital Signature Standard (DSS)</title>		<title>Recommendations for Discrete
			Logarithm-based Cryptography:
			Elliptic Curve Domain Parameters</title>
	<author>		<author>
	<organization>National Institute for Standards and Technology</org anization>		<organization>National Institute for Standards and Technology (NIS T)</organization>
	</author>		</author>
	<date year="2013" month="July"/>		<date year="2023" month="February"/>
	</front>		</front>
	<seriesInfo name="FIPS" value="PUB 186-4"/>		<refcontent>NIST SP 800-186</refcontent>
			<seriesInfo name="DOI" value="10.6028/NIST.SP.800-186"/>
	</reference>		</reference>
	<reference anchor="SECG1" target="http://www.secg.org/sec1-v2.pdf">		<reference anchor="SECG1" target="https://www.secg.org/sec1-v2.pdf">
	<front>		<front>
	<title>SEC 1: Elliptic Curve Cryptography</title>		<title>SEC 1: Elliptic Curve Cryptography</title>
	<author>		<author>
	<organization>Standards for Efficient Cryptography Group (SECG)</o rganization>		<organization>Standards for Efficient Cryptography Group (SECG)</o rganization>
	</author>		</author>
	<date year="2009" month="May"/>		<date year="2009" month="May"/>
	</front>		</front>
	<seriesInfo name="Version" value="2.0"/>		<refcontent>Version 2.0</refcontent>
	</reference>		</reference>
	</references>		</references>
	<references>		<references>
	<name>Informative References</name>		<name>Informative References</name>
	<reference anchor="ANSI.X9-62-2005">
			<reference anchor="ANSI.X9-62-2005" target="https://standards.globalspec
			.com/std/1955141/ANSI%20X9.62">
	<front>		<front>
	<title>Public Key Cryptography for the Financial Services Industry:		<title>Public Key Cryptography for the Financial Services Industry:
	The Elliptic Curve Digital Signature Algorithm (ECDSA)</title>		the Elliptic Curve Digital Signature Algorithm (ECDSA)</title>
	<author surname="American National Standards Institute">		<author>
	<organization/>		<organization>American National Standards Institute (ANSI)</organiz
	</author>		ation>
	<date year="2005"/>		</author>
			<date year="2005" month="November"/>
	</front>		</front>
	<seriesInfo name="" value="ANSI X9.62"/>		<refcontent>ANSI X9.62</refcontent>
	</reference>		</reference>
	<reference anchor="BreHen19" target="https://eprint.iacr.org/2019/023">		<reference anchor="BreHen19" target="https://eprint.iacr.org/2019/023">
	<front>		<front>
	<title>Biased Nonce Sense: Lattice Attacks against		<title>Biased Nonce Sense: Lattice Attacks against
	Weak ECDSA Signatures in Cryptocurrencies</title>		Weak ECDSA Signatures in Cryptocurrencies</title>
	<author initials="J." surname="Breitner">		<author initials="J." surname="Breitner">
	<organization/>
	</author>		</author>
	<author initials="N." surname="Heninger">		<author initials="N." surname="Heninger">
	<organization/>
	</author>		</author>
	<date year="2019"/>		<date month="April" year="2019"/>
	</front>		</front>
	<seriesInfo name="in" value="Financial Cryptography"/>		<refcontent>Cryptology ePrint Archive, Paper 2019/023</refcontent>
	</reference>		</reference>
	<reference anchor="DGKR18" target="https://eprint.iacr.org/2017/573">		<reference anchor="DGKR18" target="https://eprint.iacr.org/2017/573">
	<front>		<front>
	<title>Ouroboros Praos: An adaptively-secure, semi-synchronous proof -of-stake protocol</title>		<title>Ouroboros Praos: An adaptively-secure, semi-synchronous proof -of-stake blockchain</title>
	<author initials="B." surname="David">		<author initials="B." surname="David">
	<organization/>
	</author>		</author>
	<author initials="P." surname="Gazi">		<author initials="P." surname="Gaži">
	<organization/>
	</author>		</author>
	<author initials="A." surname="Kiayias">		<author initials="A." surname="Kiayias">
	<organization/>
	</author>		</author>
	<author initials="A." surname="Russell">		<author initials="A." surname="Russell">
	<organization/>
	</author>		</author>
	<date year="2018"/>		<date month="April" year="2023"/>
	</front>		</front>
	<seriesInfo name="in" value="Advances in Cryptology - EUROCRYPT"/>		<refcontent>Cryptology ePrint Archive, Paper 2017/573</refcontent>
	</reference>		</reference>
	<reference anchor="GHMVZ17" target="https://eprint.iacr.org/2017/454">		<reference anchor="GHMVZ17" target="https://eprint.iacr.org/2017/454">
	<front>		<front>
	<title>Algorand: Scaling Byzantine Agreements for Cryptocurrencies</ title>		<title>Algorand: Scaling Byzantine Agreements for Cryptocurrencies</ title>
	<author initials="Y." surname="Gilad">		<author initials="Y." surname="Gilad">
	<organization/>
	</author>		</author>
	<author initials="R." surname="Hemo">		<author initials="R." surname="Hemo">
	<organization/>
	</author>		</author>
	<author initials="Y." surname="Micali">		<author initials="S." surname="Micali">
	<organization/>
	</author>		</author>
	<author initials="Y." surname="Vlachos">		<author initials="G." surname="Vlachos">
	<organization/>
	</author>		</author>
	<author initials="Y." surname="Zeldovich">		<author initials="N." surname="Zeldovich">
	<organization/>
	</author>		</author>
	<date year="2017"/>		<date month="September" year="2017"/>
	</front>		</front>
	<seriesInfo name="in" value="Proceedings of the 26th Symposium on Oper ating Systems Principles (SOSP)"/>		<refcontent>Cryptology ePrint Archive, Paper 2017/454</refcontent>
	</reference>		</reference>
	<reference anchor="GNPRVZ15" target="https://eprint.iacr.org/2014/582.pd f">		<reference anchor="GNPRVZ15" target="https://eprint.iacr.org/2014/582">
	<front>		<front>
	<title>NSEC5: Provably Preventing		<title>NSEC5: Provably Preventing
	DNSSEC Zone Enumeration</title>		DNSSEC Zone Enumeration</title>
	<author initials="S." surname="Goldberg">		<author initials="S." surname="Goldberg">
	<organization/>
	</author>		</author>
	<author initials="M." surname="Naor">		<author initials="M." surname="Naor">
	<organization/>
	</author>		</author>
	<author initials="D." surname="Papadopoulos">		<author initials="D." surname="Papadopoulos">
	<organization/>
	</author>		</author>
	<author initials="L." surname="Reyzin">		<author initials="L." surname="Reyzin">
	<organization/>
	</author>		</author>
	<author initials="S." surname="Vasant">		<author initials="S." surname="Vasant">
	<organization/>
	</author>		</author>
	<author initials="A." surname="Ziv">		<author initials="A." surname="Ziv">
	<organization/>
	</author>		</author>
	<date year="2015"/>		<date month="December" year="2014"/>
	</front>		</front>
	<seriesInfo name="in" value="NDSS"/>		<refcontent>Cryptology ePrint Archive, Paper 2014/582</refcontent>
	</reference>		</reference>
	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-vcelak-
	nsec5.xml"/>
	<reference anchor="MRV99" target="https://dash.harvard.edu/handle/1/5028 196">		<reference anchor="MRV99" target="https://dash.harvard.edu/handle/1/5028 196">
	<front>		<front>
	<title>Verifiable Random Functions</title>		<title>Verifiable Random Functions</title>
	<author initials="S." surname="Micali">		<author initials="S." surname="Micali">
	<organization/>		<organization/>
	</author>		</author>
	<author initials="M." surname="Rabin">		<author initials="M." surname="Rabin">
	<organization/>		<organization/>
	</author>		</author>
	<author initials="S." surname="Vadhan">		<author initials="S." surname="Vadhan">
	<organization/>		<organization/>
	</author>		</author>
	<date year="1999"/>		<date year="1999" month="October"/>
	</front>		</front>
	<seriesInfo name="in" value="FOCS"/>		<seriesInfo name="DOI" value="10.1109/SFFCS.1999.814584"/>
			<refcontent>FOCS '99: Proceedings of the 40th Annual Symposium on Foun
			dations of Computer Science, pp. 120-130</refcontent>
	</reference>		</reference>
	<reference anchor="PWHVNRG17" target="https://eprint.iacr.org/2017/099">		<reference anchor="PWHVNRG17" target="https://eprint.iacr.org/2017/099">
	<front>		<front>
	<title>Making NSEC5 Practical for DNSSEC</title>		<title>Making NSEC5 Practical for DNSSEC</title>
	<author initials="D." surname="Papadopoulos">		<author initials="D." surname="Papadopoulos">
	<organization/>
	</author>		</author>
	<author initials="D." surname="Wessels">		<author initials="D." surname="Wessels">
	<organization/>
	</author>		</author>
	<author initials="S." surname="Huque">		<author initials="S." surname="Huque">
	<organization/>
	</author>		</author>
	<author initials="J." surname="Vcelak">		<author initials="M." surname="Naor">
	<organization/>		</author>
	</author>		<author initials="J." surname="Včelák">
	<author initials="M." surname="Naor">
	<organization/>
	</author>		</author>
	<author initials="L." surname="Reyzin">		<author initials="L." surname="Reyzin">
	<organization/>
	</author>		</author>
	<author initials="S." surname="Goldberg">		<author initials="S." surname="Goldberg">
	<organization/>
	</author>		</author>
	<date year="2017" month="February"/>		<date year="2022" month="August"/>
	</front>		</front>
	<seriesInfo name="in" value="ePrint Cryptology Archive 2017/099"/>		<refcontent>Cryptology ePrint Archive, Paper 2017/099</refcontent>
	</reference>		</reference>
	<reference anchor="X25519" target="https://cr.yp.to/ecdh.html#validate">		<reference anchor="X25519" target="https://cr.yp.to/ecdh.html#validate">
	<front>		<front>
	<title>How do I validate Curve25519 public keys?</title>		<title>How do I validate Curve25519 public keys?</title>
	<author initials="D.J." surname="Bernstein">		<author initials="D.J." surname="Bernstein">
	<organization/>
	</author>		</author>
	<date year="2006"/>		<date year="2006"/>
	</front>		</front>
	</reference>		</reference>
	</references>		</references>
	</references>		</references>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Test Vectors for the RSA-FDH-VRF ciphersuites</name>		<name>Test Vectors for the RSA-FDH-VRF Ciphersuites</name>
	<t>The test vectors in this section were generated using code at <eref tar		<t>The test vectors in this section were generated using code provided at
	get="https://github.com/reyzin/rsa-fdh-vrf"/>.</t>		<eref target="https://github.com/reyzin/rsa-fdh-vrf" brackets="angle"/>.</t>
	<t>There are three keys used in the nine examples below. First, we provide the keys. They are shown in hexadecimal big-endian notation.</t>		<t>There are three keys used in the nine examples below. First, we provide the keys. They are shown in hexadecimal big-endian notation.</t>
	<t>2048-bit key:</t>		<t>2048-bit key:</t>
	<ul empty="true" spacing="compact">
	<li> p = efb52a568fa3038fffb853e2183791c6bc81ceee86d20e8f9b6401dc79a8f1
	f6248d3a25fdb3f99245fce41667da038f59745b87cc1aed8b4a9c1d74e7d5c16cf7343f2b12f1b5
	055337369bf018fa07adc0d16f2164a516e80d2b4734f0c6563d6ee6d4a9e1a54e300cfe9ee679af
	c3d14a152dfb49b6cfb208bbf921f764af</li>
	<li> q = ecbca5ee88bbc635d8263aaba84f6502fdb2b4998a40f7c149133d840b6b1b
	d9a972fe2a981c770272b78fda213f76a062dd865dd116d4c8980975ee9347fe0f500567e51d78db
	ee4a34e626051cf018d7feb72f19189525d4f70b6467d0cef514633ab08a9e7a9ec632064b7b5e3e
	82128fe563757a614092fc5cf624d10e1b</li>
	<li> n = ddaba77202bafb796b85bcec98958aa58ae2d117cbc66a6e75c4c2af983985
	a3064eaef93e2b03393256d94d75d6a6656b2956524ed8711898a0c3abae84371da0283bc5f433fc
	384d810a3c118ed302c0b03da16bee70b80ba3480e7acc1eb358b3f20fbe90cc4c8a7e2ba9e28b2a
	3800a5efbaa3c264f79b231f7cdc9577818df1bac60ef7a3f78a44f046fd29b0689556da7a7f61ee
	fe67427f3f691aee0a4b1efe2ee2e0e6091143ebb7d69254c9d8ab01ff5e0ad7329f566082f9251e
	64f436c547e68de75351ea3a09746ceb7efed2d234121088aaed01696583c172ec88bc173a0d4d8e
	c43f4dcc18ff8379317e83ef9685536283368c9c6deb783075</li>
	<li> e = 010001</li>
	<li> d = d5c5ceab929a841e2a654536de4788f7f0a2a086d44bbb245f8aab3df00db9
	24e8d644c3b502820f4cce98adacf09e73bc0e9762b50ae2b697aaa24914fa08b51758f59c07cf82
	7341bb2a0597e126f9c69db031d60692c9cadf62842444696f08223154a1b0be752a325725748644
	e6d12935b1c66f983379773bcc8c65d06262e93b5bb774dd2784265c23e9a7fc5e8871eb6bcc9968
	a6bc360a98874b623ec59f41af0a9ecec6af095cb7e5aca11472363950dcbbfcf678fe003358b4ff
	0060a391daa45a1bd81c166b6221fb07e4f5da75e27d8d5fdbbf87ecbd7f5a4d804597070faaed22
	f197511b218788816689375245ddf7fa12337f3e7e898fb9d9</li>
	</ul>
			<sourcecode type="test-vectors"><![CDATA[p = efb52a568fa3038fffb853e2183791c6bc8
			1ceee86d20e8f9b6401dc79a8f1
			f6248d3a25fdb3f99245fce41667da038f59745b87cc1aed8b4a9c1d74e7d5c16c
			f7343f2b12f1b5055337369bf018fa07adc0d16f2164a516e80d2b4734f0c6563d
			6ee6d4a9e1a54e300cfe9ee679afc3d14a152dfb49b6cfb208bbf921f764af
			q = ecbca5ee88bbc635d8263aaba84f6502fdb2b4998a40f7c149133d840b6b1b
			d9a972fe2a981c770272b78fda213f76a062dd865dd116d4c8980975ee9347fe0f
			500567e51d78dbee4a34e626051cf018d7feb72f19189525d4f70b6467d0cef514
			633ab08a9e7a9ec632064b7b5e3e82128fe563757a614092fc5cf624d10e1b
			n = ddaba77202bafb796b85bcec98958aa58ae2d117cbc66a6e75c4c2af983985
			a3064eaef93e2b03393256d94d75d6a6656b2956524ed8711898a0c3abae84371d
			a0283bc5f433fc384d810a3c118ed302c0b03da16bee70b80ba3480e7acc1eb358
			b3f20fbe90cc4c8a7e2ba9e28b2a3800a5efbaa3c264f79b231f7cdc9577818df1
			bac60ef7a3f78a44f046fd29b0689556da7a7f61eefe67427f3f691aee0a4b1efe
			2ee2e0e6091143ebb7d69254c9d8ab01ff5e0ad7329f566082f9251e64f436c547
			e68de75351ea3a09746ceb7efed2d234121088aaed01696583c172ec88bc173a0d
			4d8ec43f4dcc18ff8379317e83ef9685536283368c9c6deb783075
			e = 010001
			d = d5c5ceab929a841e2a654536de4788f7f0a2a086d44bbb245f8aab3df00db9
			24e8d644c3b502820f4cce98adacf09e73bc0e9762b50ae2b697aaa24914fa08b5
			1758f59c07cf827341bb2a0597e126f9c69db031d60692c9cadf62842444696f08
			223154a1b0be752a325725748644e6d12935b1c66f983379773bcc8c65d06262e9
			3b5bb774dd2784265c23e9a7fc5e8871eb6bcc9968a6bc360a98874b623ec59f41
			af0a9ecec6af095cb7e5aca11472363950dcbbfcf678fe003358b4ff0060a391da
			a45a1bd81c166b6221fb07e4f5da75e27d8d5fdbbf87ecbd7f5a4d804597070faa
			ed22f197511b218788816689375245ddf7fa12337f3e7e898fb9d9
			]]></sourcecode>
	<t>3072-bit key:</t>		<t>3072-bit key:</t>
	<ul empty="true" spacing="compact">		<sourcecode type="test-vectors"><![CDATA[p = ee5adea28491084e6635bd73fd95649915a
	<li> p = ee5adea28491084e6635bd73fd95649915a11da410d3f361c8eccc90a4b834		11da410d3f361c8eccc90a4b834
	25146da7b9e9d3994fd37d5fad7fb759ae451eb99b1102d4671ead23a2925133d19df49cf9d7e9dc		25146da7b9e9d3994fd37d5fad7fb759ae451eb99b1102d4671ead23a2925133d1
	b69fd7555ca095338d0d2a84abb6825050eaf5fffaeff17ccb0833c6079081dfcbd98ced36a59355		9df49cf9d7e9dcb69fd7555ca095338d0d2a84abb6825050eaf5fffaeff17ccb08
	7d29d64b0e0253ce2ee4e07fe2a06269dfe5ca230fad221a593a69d9534b2521c1b41d116cafdee0		33c6079081dfcbd98ced36a593557d29d64b0e0253ce2ee4e07fe2a06269dfe5ca
	2106228ff41433605453e237777626953e79b46a84f50069e25b4f50496a928708abce30559eb183		230fad221a593a69d9534b2521c1b41d116cafdee02106228ff41433605453e237
	cf</li>		777626953e79b46a84f50069e25b4f50496a928708abce30559eb183cf
	<li> q = fb585bbc12f5695951f70a25e27682dc568acf56115ad749709b2a6e915cdd		q = fb585bbc12f5695951f70a25e27682dc568acf56115ad749709b2a6e915cdd
	66dfa06db09b390c00b7c7ebeea00845f73c999d8ea9352b1128bdf10113c7500b76a03f6b38d092		66dfa06db09b390c00b7c7ebeea00845f73c999d8ea9352b1128bdf10113c7500b
	0b5589961549be3d841ccc306f3edd600a53b4b9d4fa1249af87af58dfb3ed694289477e853f7d06		76a03f6b38d0920b5589961549be3d841ccc306f3edd600a53b4b9d4fa1249af87
	2f58911f7bdb98033b001ee90f11b78f031cffac2b5a07e11b01a2a6c1cda059a728f8253a5ff872		af58dfb3ed694289477e853f7d062f58911f7bdb98033b001ee90f11b78f031cff
	67623253fc022d3993b27e2f344b99eb6072ff7c7ee160724f8fbca562be49247ffae42b55ea79da		ac2b5a07e11b01a2a6c1cda059a728f8253a5ff87267623253fc022d3993b27e2f
	d5</li>		344b99eb6072ff7c7ee160724f8fbca562be49247ffae42b55ea79dad5
	<li> n = ea055cef495dec2d8fb3aef519ca87bd1575fa0ae15dd433f4a5f6c40d34ed		n = ea055cef495dec2d8fb3aef519ca87bd1575fa0ae15dd433f4a5f6c40d34ed
	6ba2388172ab7d2183ed970a669d427dc2774ced66a3f082b8e23e94e7de7532f4f30bb4a5bbf2e1		6ba2388172ab7d2183ed970a669d427dc2774ced66a3f082b8e23e94e7de7532f4
	db2cba0752858a7c7a9bb892c5d6af7e90a7cee8f0097d14498c8b482f86348640af61b66640538e		f30bb4a5bbf2e1db2cba0752858a7c7a9bb892c5d6af7e90a7cee8f0097d14498c
	834f23ba8f906048db0e57b6fdc162ba2a8a0eaedd5423f23d8f89413223d89f473029cba11a211e		8b482f86348640af61b66640538e834f23ba8f906048db0e57b6fdc162ba2a8a0e
	b59e41fb8f0b8ddc651d115d9f07ac30296485a9adbd71cc5d9e4a448bd6d70785e838a978b2e665		aedd5423f23d8f89413223d89f473029cba11a211eb59e41fb8f0b8ddc651d115d
	13eb897c962e85f00a36cc0a3a613183d8bd1572f895901eb8155af9797dbd4aa14726f415712bf0		9f07ac30296485a9adbd71cc5d9e4a448bd6d70785e838a978b2e66513eb897c96
	eb29fa0a9e938cf5325def05d3af7e686227456d903233e316c8cc50341615e59b665f0a4a2c32cf		2e85f00a36cc0a3a613183d8bd1572f895901eb8155af9797dbd4aa14726f41571
	ccbf9469bdf89564481fb7afc27a7127741f79424e0a35cdc466dd33ef5a2067f75c86e06af9c03c		2bf0eb29fa0a9e938cf5325def05d3af7e686227456d903233e316c8cc50341615
	68c6e78be5f1a4f49ea03569cd9f74c3a0ff290ca4ce2c2fa5b770ef8032b26a517c257b7b1c4246		e59b665f0a4a2c32cfccbf9469bdf89564481fb7afc27a7127741f79424e0a35cd
	22c5c04cf20f2290a268939e0cc79dfbac71842f94727b07bfafaded7db6c7f13b</li>		c466dd33ef5a2067f75c86e06af9c03c68c6e78be5f1a4f49ea03569cd9f74c3a0
	<li> e = 010001</li>		ff290ca4ce2c2fa5b770ef8032b26a517c257b7b1c424622c5c04cf20f2290a268
	<li> d = 6e68e957dbfd7c1862dc1b87780b9dcf0ff9016770bc9c09873b66194941d7		939e0cc79dfbac71842f94727b07bfafaded7db6c7f13b
	6218bf2013c1e4df9326dd4402f5df110656d2ec8ea87a28b2a1cb74e590872aeb765fe772ea21c5		e = 010001
	7d6ab4ba0fad019189273f05c061719afd14af02277dd28d67c5ef50b75b521ca51819b9bcb44cb7		d = 6e68e957dbfd7c1862dc1b87780b9dcf0ff9016770bc9c09873b66194941d7
	c82be66776a45f490050dc0171e77374f1ed00d06f8beb09b711a9682107d8840d4a23edf6ac2544		6218bf2013c1e4df9326dd4402f5df110656d2ec8ea87a28b2a1cb74e590872aeb
	1fdbf2b584dfa6a67cee21eb51c484f09416e11914e774713f1a17600fb9e4e99fbbd83fdcba4b09		765fe772ea21c57d6ab4ba0fad019189273f05c061719afd14af02277dd28d67c5
	145dd9809449a1713777161c912d5d595362314b0ea9d1199e97780e8b3293a39af4019fcc746aaf		ef50b75b521ca51819b9bcb44cb7c82be66776a45f490050dc0171e77374f1ed00
	78dbb7db06852c3358a9ed02ab1d15831a148b27b932c117445a4a6f5114edfa3ccc9a9862df714b		d06f8beb09b711a9682107d8840d4a23edf6ac25441fdbf2b584dfa6a67cee21eb
	78a5362aab5e30501b4a729af73e3cdcabe19aac4928b668969780ad33d9df206d904b978a055f4a		51c484f09416e11914e774713f1a17600fb9e4e99fbbd83fdcba4b09145dd98094
	bbc64987744526856e16ef55962453e3ed7a8055b0d79d051c50c94584ec7501dbd4856d7a21e43f		49a1713777161c912d5d595362314b0ea9d1199e97780e8b3293a39af4019fcc74
	25d8749e683cca2f53f575af1d80f39d8e6932ffdf201d179cbf98314c4048c6c1</li>		6aaf78dbb7db06852c3358a9ed02ab1d15831a148b27b932c117445a4a6f5114ed
	</ul>		fa3ccc9a9862df714b78a5362aab5e30501b4a729af73e3cdcabe19aac4928b668
			969780ad33d9df206d904b978a055f4abbc64987744526856e16ef55962453e3ed
			7a8055b0d79d051c50c94584ec7501dbd4856d7a21e43f25d8749e683cca2f53f5
			75af1d80f39d8e6932ffdf201d179cbf98314c4048c6c1
			]]></sourcecode>
	<t>4096-bit key:</t>		<t>4096-bit key:</t>
	<ul empty="true" spacing="compact">		<sourcecode type="test-vectors"><![CDATA[p = ac803464c8b2082153e15d5a0698d0a2990
	<li> p = ac803464c8b2082153e15d5a0698d0a2990397fa01c1edd6171a5315e743c9		397fa01c1edd6171a5315e743c9
	9feb7acd31c37529d4f83405e657c390488d19f7da9ef9d9f9cff4b460d2a26eb10f90cf4aaf55a1		9feb7acd31c37529d4f83405e657c390488d19f7da9ef9d9f9cff4b460d2a26eb1
	9e21dc3bb697723a673e12bbc6580adc7bb72adaddf4682d656ff5b992e62379bc7b0ac977f2bfbc		0f90cf4aaf55a19e21dc3bb697723a673e12bbc6580adc7bb72adaddf4682d656f
	fac634e04ed597ef302684be72c6bf7db10b80f452d412d09e63e017acba378ccc6ea58e683e5641		f5b992e62379bc7b0ac977f2bfbcfac634e04ed597ef302684be72c6bf7db10b80
	d1e72248f3201a5632f4af7525e91f9e0733731d264fe36802f416cb3e182b21e67a12e3bfba9a9c		f452d412d09e63e017acba378ccc6ea58e683e5641d1e72248f3201a5632f4af75
	f40a45ff32addfae78063933120238ac61fbb995300a8602aa84f993bed375d6ccba86ad0c8efa5f		25e91f9e0733731d264fe36802f416cb3e182b21e67a12e3bfba9a9cf40a45ff32
	0950aa2c92779febce9d05fa7a1f0d6e5c0d785de93c108297</li>		addfae78063933120238ac61fbb995300a8602aa84f993bed375d6ccba86ad0c8e
	<li> q = feb39bb6ee78adfa524e9c0821f60c20d3cff74f8b49731d67ea27d218bcb2		fa5f0950aa2c92779febce9d05fa7a1f0d6e5c0d785de93c108297
	0c87498d30dfd398bc23daff7b33dc330db93e6c0e5e6196e035446c6db7cfdb9868b9518d94670b		q = feb39bb6ee78adfa524e9c0821f60c20d3cff74f8b49731d67ea27d218bcb2
	31f9c4d2109cf32c9cc8ac2fc4a6c2e1078510522c81610a81a707997933ee24030b572a76ee51aa		0c87498d30dfd398bc23daff7b33dc330db93e6c0e5e6196e035446c6db7cfdb98
	683312ecaa51d8558b3b19cccf65fc867354ae193fd5c4f5d5a7180c5ca1e90fcc42f6915dff69a3		68b9518d94670b31f9c4d2109cf32c9cc8ac2fc4a6c2e1078510522c81610a81a7
	d1e49046f6c3ef841b262ba89ddcfde2ed3caeb5bd594181a76f6f1ce01fc65c6f925f6d5b77037c		07997933ee24030b572a76ee51aa683312ecaa51d8558b3b19cccf65fc867354ae
	2cbf7b6047e19f7b9c846c80238f1c8284c33bfd90c79de91381bb883b0de568aaf4b4a3c3f9c98f		193fd5c4f5d5a7180c5ca1e90fcc42f6915dff69a3d1e49046f6c3ef841b262ba8
	92e9f6a51f010bcc1dacfd72bfdfda29f527d7f4913153bef7</li>		9ddcfde2ed3caeb5bd594181a76f6f1ce01fc65c6f925f6d5b77037c2cbf7b6047
	<li> n = aba03a8d8527bfc0cbea1cb9a100f4ee7870aedd74a6406f108f7a07f37433		e19f7b9c846c80238f1c8284c33bfd90c79de91381bb883b0de568aaf4b4a3c3f9
	6025357e256d655b342d73369102d03c7dcf3c14ed70aac7ebb62498c570068f71f1f165e14527f9		c98f92e9f6a51f010bcc1dacfd72bfdfda29f527d7f4913153bef7
	6d946ba839412252eacea604e7d6fd47a0bb9de776679fa9ad6485a076fda04a2015322626dcd2eb		n = aba03a8d8527bfc0cbea1cb9a100f4ee7870aedd74a6406f108f7a07f37433
	91d6b6248802e6d453eb4cbf5e1bfebed02d6ab36cfe3dd1e8b9749d4853a029940a0bed3aa3128f		6025357e256d655b342d73369102d03c7dcf3c14ed70aac7ebb62498c570068f71
	d8e2e6cd1115db15405bb3837012f56bdc5a6895ec5cc6bca52f7952cfe3c7d5d81d4d3d1c9a29a4		f1f165e14527f96d946ba839412252eacea604e7d6fd47a0bb9de776679fa9ad64
	29eeedfbf58da0a5b17480875b8071f49eb568fc8d8c023c83b3ed870c3775aaf0578485d757b4ab		85a076fda04a2015322626dcd2eb91d6b6248802e6d453eb4cbf5e1bfebed02d6a
	18d8e5fdb30c2b5586047e6203ab1636e376f1c7031f171e2807a2058ece890cc8fae29ba819df76		b36cfe3dd1e8b9749d4853a029940a0bed3aa3128fd8e2e6cd1115db15405bb383
	b45ddb514caee63db1c5e7a3af7468febff82bfe2eb79e3c5d1383b7ebee86f02e9cc1853f0f4486		7012f56bdc5a6895ec5cc6bca52f7952cfe3c7d5d81d4d3d1c9a29a429eeedfbf5
	f7eb8fee23a2f794317ffd1c39471086dfbfc0e3c0f412f917225f5c551557f38c11f172eca257e4		8da0a5b17480875b8071f49eb568fc8d8c023c83b3ed870c3775aaf0578485d757
	b5908a571e4daa7c7434903701f21937df87d10de9b50ada97e65855d5e786db8f3f86248b55d999		b4ab18d8e5fdb30c2b5586047e6203ab1636e376f1c7031f171e2807a2058ece89
	ec31538bd1a409f3e13de46dccc05325774e89016708f8a96240ae1c16641e8b12ab07257e88aa50		0cc8fae29ba819df76b45ddb514caee63db1c5e7a3af7468febff82bfe2eb79e3c
	d3546e7a91073d85ed601775a3c08e9b7c242d20664dfd4e70a05218d9f2c7d760fab3cd772d9362		5d1383b7ebee86f02e9cc1853f0f4486f7eb8fee23a2f794317ffd1c39471086df
	527917cf5b51817e8c2aef51cb3b0dd8cb838097e513537f1d9c3c4708f44ed270db963c7d72cf11		bfc0e3c0f412f917225f5c551557f38c11f172eca257e4b5908a571e4daa7c7434
	b1</li>		903701f21937df87d10de9b50ada97e65855d5e786db8f3f86248b55d999ec3153
	<li> e = 010001</li>		8bd1a409f3e13de46dccc05325774e89016708f8a96240ae1c16641e8b12ab0725
	<li> d = 1efd8dd524282b4deb04592f83cd226d353e53b5156d37d15652321ce16f28		7e88aa50d3546e7a91073d85ed601775a3c08e9b7c242d20664dfd4e70a05218d9
	1fc258487105b1f9a81054ef937bc89243bd7a01e56624d078d5a9021514c77a7b7eceb230dd45fc		f2c7d760fab3cd772d9362527917cf5b51817e8c2aef51cb3b0dd8cb838097e513
	9a36e4c1b9a4f347b9b29af3e3d14466fcb5242c398b389f70f9e7cf33ed54564e38c597720909e5		537f1d9c3c4708f44ed270db963c7d72cf11b1
	13ae8bb149060d1c6612e506e13d78e087c2cbb39e88c22cf73315c598dbd0ddf1276743ed04a943		e = 010001
	644c84949ef32d5e4702c80581e54a7fb18879be28b21008dc63182b45f2c190f1b748cd322efc39		d = 1efd8dd524282b4deb04592f83cd226d353e53b5156d37d15652321ce16f28
	f2807c64b4d06023cb49583418e7b6ac0f447eb2abf48e2ad335583cbc8dff2760c2cce146234632		1fc258487105b1f9a81054ef937bc89243bd7a01e56624d078d5a9021514c77a7b
	6708336f7e374253ed213e990044927c52d29591f414571e509afc2396a6af9843303a19673bcdec		7eceb230dd45fc9a36e4c1b9a4f347b9b29af3e3d14466fcb5242c398b389f70f9
	1e3fc7c0d6c3f43b4bf88ce83e2bdcfb5e39069fe32800cf3f6f6d9917b8083a66ce23a9ab5b0c95		e7cf33ed54564e38c597720909e513ae8bb149060d1c6612e506e13d78e087c2cb
	bbcc6dfc21d38dadecc20725b13ce2954ba1bd45ec151a8877fed317cac60b2afaa96c826df6d1c4		b39e88c22cf73315c598dbd0ddf1276743ed04a943644c84949ef32d5e4702c805
	8e7c10649dccc75bdf905c362c6934da06c3ce30f5befc1cf776d7fda673625147b1108ecb5473f7		81e54a7fb18879be28b21008dc63182b45f2c190f1b748cd322efc39f2807c64b4
	f588279533eb184d748230443694b9761b01532ba707563ffa4962321e44fdb710025e8a6e00d29b		d06023cb49583418e7b6ac0f447eb2abf48e2ad335583cbc8dff2760c2cce14623
	f01ea040618ee111b5d79ac860083f91aa614777cc99d739458f7c53d63cea7155b118068e0b30b3		46326708336f7e374253ed213e990044927c52d29591f414571e509afc2396a6af
	5ed6d0cfc75672f18d075157a3ed31bfa1ce2cea234357ec76117cc687c274636077abc437cb70a0		9843303a19673bcdec1e3fc7c0d6c3f43b4bf88ce83e2bdcfb5e39069fe32800cf
	29</li>		3f6f6d9917b8083a66ce23a9ab5b0c95bbcc6dfc21d38dadecc20725b13ce2954b
	</ul>		a1bd45ec151a8877fed317cac60b2afaa96c826df6d1c48e7c10649dccc75bdf90
			5c362c6934da06c3ce30f5befc1cf776d7fda673625147b1108ecb5473f7f58827
			9533eb184d748230443694b9761b01532ba707563ffa4962321e44fdb710025e8a
			6e00d29bf01ea040618ee111b5d79ac860083f91aa614777cc99d739458f7c53d6
			3cea7155b118068e0b30b35ed6d0cfc75672f18d075157a3ed31bfa1ce2cea2343
			57ec76117cc687c274636077abc437cb70a029
			]]></sourcecode>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>RSA-FDH-VRF-SHA256</name>		<name>RSA-FDH-VRF-SHA256</name>
	<t>Example 1, using the 2048-bit key above:</t>		<t>Example 1, using the 2048-bit key above:</t>
	<ul empty="true" spacing="compact">		<sourcecode type="test-vectors"><![CDATA[alpha = (the empty string)
	<li>alpha = (the empty string)</li>		EM = 092ea69ca4f5630d4bd1012805ad23528a5f44c040829b4a0208491913ee3
	<li>EM = 092ea69ca4f5630d4bd1012805ad23528a5f44c040829b4a0208491913ee		9711889bce5347765072efb0b7f8ad9798c830085d9babe10c29f1a649dbb9a64c
	39711889bce5347765072efb0b7f8ad9798c830085d9babe10c29f1a649dbb9a64c93a8cdaa325d3		93a8cdaa325d37814faa15a1071ba81c39275f3cd66ce70fd21ee3acc7ac127c5d
	7814faa15a1071ba81c39275f3cd66ce70fd21ee3acc7ac127c5de8f2a816b05aff19e4e63451cfe		e8f2a816b05aff19e4e63451cfe51fef059b2547302387449b4df1ab8eaa5bfc84
	51fef059b2547302387449b4df1ab8eaa5bfc84dbbc5edf3b07eb8fe3fe2a93858bd0d55d6f0686f		dbbc5edf3b07eb8fe3fe2a93858bd0d55d6f0686f2eb449ed4c609b3083de04b49
	2eb449ed4c609b3083de04b49d409a425509d89d282de806a6ce66892edc30337f780b15c7695b26		d409a425509d89d282de806a6ce66892edc30337f780b15c7695b26383516f1fc1
	383516f1fc18f7eab52557c654467600e2e272ef41e7e4a060b42f7533bae603a7fa50f497a64a15		8f7eab52557c654467600e2e272ef41e7e4a060b42f7533bae603a7fa50f497a64
	08b93826d99643a2001d1c958a7a06da0370668634d678a5de</li>		a1508b93826d99643a2001d1c958a7a06da0370668634d678a5de
	<li>pi = 14234ff8a9487e1b36a23086e258135b8a8a7ff2e23f19c0dfeca0c0a943		pi = 14234ff8a9487e1b36a23086e258135b8a8a7ff2e23f19c0dfeca0c0a943f
	f119ebd336fdc292ef67b56e32ba06f9941893754a8b97c82f68974b2b34c17f6d43bfd55eb110cd		119ebd336fdc292ef67b56e32ba06f9941893754a8b97c82f68974b2b34c17f6d4
	7ea3452d59a24e4ddb8d4cdf040c814e22e3537ca09c2e2dc5dd8ea281e6492ad335378f9f437eed		3bfd55eb110cd7ea3452d59a24e4ddb8d4cdf040c814e22e3537ca09c2e2dc5dd8
	30c51eeeee66ef14efb4000c75c802e9c5a6bb8039c0258d4347981159d0ef6990b5e9c8ac2fb039		ea281e6492ad335378f9f437eed30c51eeeee66ef14efb4000c75c802e9c5a6bb8
	15d7ff1ffa0626e2e11714a63342e59124c1fcea8e2816c1d9a7751feaaa66cf6c82cd3c58ffde66		039c0258d4347981159d0ef6990b5e9c8ac2fb03915d7ff1ffa0626e2e11714a63
	460d98246ab358cc33baefae4dfb0d191e9b6d6c0e3f92c35200408925dc8bef39b78d1259f8163a		342e59124c1fcea8e2816c1d9a7751feaaa66cf6c82cd3c58ffde66460d98246ab
	5003a693555f05290ef2e68345f27c6e2a8847c5c919d92e7505</li>		358cc33baefae4dfb0d191e9b6d6c0e3f92c35200408925dc8bef39b78d1259f81
	<li>beta = 79f0615d4677fb72571889453644013f1a31b08d222e3cee349d64ce1c		63a5003a693555f05290ef2e68345f27c6e2a8847c5c919d92e7505
	41045a</li>		beta =
	</ul>		79f0615d4677fb72571889453644013f1a31b08d222e3cee349d64ce1c41045a
			]]></sourcecode>
	<t>Example 2, using the 3072-bit key above:</t>		<t>Example 2, using the 3072-bit key above:</t>
	<ul empty="true" spacing="compact">		<sourcecode type="test-vectors"><![CDATA[alpha = 74657374 (4 bytes; ASCII "test"
	<li>alpha = 74657374 (4 bytes; ASCII "test")</li>		)
	<li>EM = 20a059b7f7034d0d7696c63328cbbd4b40f7c656a632b4129915018fe6c5		EM = 20a059b7f7034d0d7696c63328cbbd4b40f7c656a632b4129915018fe6c5d
	dee8b5bde68ec2a5a78b1ca8483386e3a1a0fa07b4d329ea55facc3145c663ca90df5ae46c903211		ee8b5bde68ec2a5a78b1ca8483386e3a1a0fa07b4d329ea55facc3145c663ca90d
	a21bf908dc9a33bd09410cc09c7b4de5fbc79de3413bc80bccf2d3aca2fc9c60c776619849ed3e70		f5ae46c903211a21bf908dc9a33bd09410cc09c7b4de5fbc79de3413bc80bccf2d
	4057ac3d5deacff845d5bc8084ac730c19a14668e53b5b8b90446b2272eaf59cdf985a7804c7b91c		3aca2fc9c60c776619849ed3e704057ac3d5deacff845d5bc8084ac730c19a1466
	ea1ce2582099b7b0f20163b11d23110939dd62081b5aa46c62db76b2ac28473d2488970d480bdd8b		8e53b5b8b90446b2272eaf59cdf985a7804c7b91cea1ce2582099b7b0f20163b11
	ef8cae9e81274fe3f9925b012c1b55cba8c4291ec7433223cb872e422bb9e0d3775670d587e40366		d23110939dd62081b5aa46c62db76b2ac28473d2488970d480bdd8bef8cae9e812
	0ff440a9c11a18a488abc716ae36840b2ef5b0db4a90d88f91d79536cef378bf8e76d173288e2624		74fe3f9925b012c1b55cba8c4291ec7433223cb872e422bb9e0d3775670d587e40
	1df522a3cf6bece49c960e43a2d93e7bed10b90580c5b3aff056507b4ef27368579832cb4aeecc99		3660ff440a9c11a18a488abc716ae36840b2ef5b0db4a90d88f91d79536cef378b
	c2d8ba402117457df5ae0ed28068ef8b2e0d4582f8edacfcad02c83bfab778460b979e9e984827bb		f8e76d173288e26241df522a3cf6bece49c960e43a2d93e7bed10b90580c5b3aff
	efe2b544c0f3ed715dde6dc1d7fc7c0f1f87d78aed8e148004b9f62e0321214c7c</li>		056507b4ef27368579832cb4aeecc99c2d8ba402117457df5ae0ed28068ef8b2e0
	<li>pi = 69f6042d400dfad4bdb9974fb73d12ec7823c6632df6b0a97ebc14d8a443		d4582f8edacfcad02c83bfab778460b979e9e984827bbefe2b544c0f3ed715dde6
	f74e1eb1a99b37204ba5c7e53bdaf7e3e3fae9efe47cc01d0b061585c8d757ecf00663b3e1bd447d		dc1d7fc7c0f1f87d78aed8e148004b9f62e0321214c7c
	55b6ebd066b814a8d9c4434b224e9cb053a1fd038a58f3bf6b0c75b6f48f3c8d1ca398a730c133f8		pi = 69f6042d400dfad4bdb9974fb73d12ec7823c6632df6b0a97ebc14d8a443f
	6f244655f24c445324fdacd291d6d907f93efb24b59e509f2f370392f5e262fc106292792352d938		74e1eb1a99b37204ba5c7e53bdaf7e3e3fae9efe47cc01d0b061585c8d757ecf00
	00f0a1e3a389786619a622f6005cab78ea5f0b5b7ca91ad2a9c6c34fc4a3f9b0332b99e907ffa7f7		663b3e1bd447d55b6ebd066b814a8d9c4434b224e9cb053a1fd038a58f3bf6b0c7
	50cdc8342e12da78f13ad49953bae1751c983ce3cd3335288ac856f85057a7f05acba6465a1c6901		5b6f48f3c8d1ca398a730c133f86f244655f24c445324fdacd291d6d907f93efb2
	ba30bc65b79fb7a847c42a5b4942d600ef316030f2ccafbc6f2e1ff0b46fb5c8517cd98c93f81acf		4b59e509f2f370392f5e262fc106292792352d93800f0a1e3a389786619a622f60
	370cfdab559bb4270d07db5466e2342d56c476089f473840434cbcdbd1853b487a6df346208d12c1		05cab78ea5f0b5b7ca91ad2a9c6c34fc4a3f9b0332b99e907ffa7f750cdc8342e1
	7a48fe50b73b96f640a9761f570a516f6157432b83dd18a1d05cc27b6f283a02fcfda147cf147177		2da78f13ad49953bae1751c983ce3cd3335288ac856f85057a7f05acba6465a1c6
	2e469961004bde7fa15857e7bf97b5a83c33fddbd9f4b2e2488f4ed5f7463c93f30b</li>		901ba30bc65b79fb7a847c42a5b4942d600ef316030f2ccafbc6f2e1ff0b46fb5c
	<li>beta = bfe966f3fabde6f38a2792ad59bc836bbca39de6eff64f15a42886deff		8517cd98c93f81acf370cfdab559bb4270d07db5466e2342d56c476089f4738404
	6dfcc5</li>		34cbcdbd1853b487a6df346208d12c17a48fe50b73b96f640a9761f570a516f615
	</ul>		7432b83dd18a1d05cc27b6f283a02fcfda147cf1471772e469961004bde7fa1585
			7e7bf97b5a83c33fddbd9f4b2e2488f4ed5f7463c93f30b
			beta =
			bfe966f3fabde6f38a2792ad59bc836bbca39de6eff64f15a42886deff6dfcc5
			]]></sourcecode>
	<t>Example 3, using the 4096-bit key above:</t>		<t>Example 3, using the 4096-bit key above:</t>
	<ul empty="true" spacing="compact">		<sourcecode type="test-vectors"><![CDATA[alpha = 73616d706c65 (6 bytes; ASCII "s
	<li>alpha = 73616d706c65 (6 bytes; ASCII "sample")</li>		ample")
	<li>EM = 17524fa1710b2f8a04e55da403b9b287b99a47afe9b81d3421482e3959b7		EM = 17524fa1710b2f8a04e55da403b9b287b99a47afe9b81d3421482e3959b73
	3b4d4d4f4b52243ff2bfd2d29b1f030b521d0699065faa2b8903cca2b24cff429561234fcbd7bccc		b4d4d4f4b52243ff2bfd2d29b1f030b521d0699065faa2b8903cca2b24cff42956
	dac61b7dcb7bc61cd857287b4b42357adbd2fc83ecfc0d5bc199e1f6e298b5e470bfc540bc85e933		1234fcbd7bcccdac61b7dcb7bc61cd857287b4b42357adbd2fc83ecfc0d5bc199e
	b02035792d65d861096dc03f048cae51c9adc6c1ec09e7f5e595681b3d3976d94ba1a65c83c7e825		1f6e298b5e470bfc540bc85e933b02035792d65d861096dc03f048cae51c9adc6c
	03db5478d3d91b2e00a0f24e7ffee1faed68aa62ad7ba4b2912ceb636064766f0535d3ca1369760d		1ec09e7f5e595681b3d3976d94ba1a65c83c7e82503db5478d3d91b2e00a0f24e7
	8edebc3c8d7f5b4de784b644b59e44e24e436298cc33a3cd0f676d6fa0b76ca3b9b11aa68e0789e8		ffee1faed68aa62ad7ba4b2912ceb636064766f0535d3ca1369760d8edebc3c8d7
	3bd27b3af08518b9a5eb5f34f4953a79dc25c1285b20fa73e558dd99638eb51bf89c80d7989f6e92		f5b4de784b644b59e44e24e436298cc33a3cd0f676d6fa0b76ca3b9b11aa68e078
	5d8ca5ed1d3f29cc1e1065400e4abbdbcf898791be12c5ae25661bf7de58a4cb6608c9a4dcc18150		9e83bd27b3af08518b9a5eb5f34f4953a79dc25c1285b20fa73e558dd99638eb51
	638068bb6452b25589ae0a943a67f024dd4b5d9e7940c01886f798316156e5771c19457f9104618e		bf89c80d7989f6e925d8ca5ed1d3f29cc1e1065400e4abbdbcf898791be12c5ae2
	271ae7863b65fd07f87fcd7862690115ce2d963eeac60f78b47c037d6ed3000b43d8149cee08df10		5661bf7de58a4cb6608c9a4dcc18150638068bb6452b25589ae0a943a67f024dd4
	a97158ee1daaf0a3963d23fb6ab0615891734e3039417d8ce03bfc18920c832a40385de95d99b546		b5d9e7940c01886f798316156e5771c19457f9104618e271ae7863b65fd07f87fc
	b4bd24ecbfb2e75e9158ae1769bcff444990f54aa40e6a14e0aca52df00062afbf81f6ce8193c53f		d7862690115ce2d963eeac60f78b47c037d6ed3000b43d8149cee08df10a97158e
	8d26ac71324fc1db878379178abd695cf04a0fae3432d1efffa73bba15b4e81fbaf598146a0c3eda		e1daaf0a3963d23fb6ab0615891734e3039417d8ce03bfc18920c832a40385de95
	fc</li>		d99b546b4bd24ecbfb2e75e9158ae1769bcff444990f54aa40e6a14e0aca52df00
	<li>pi = 745cc4b6cb75b925194374cdf91b498e8d687c5d9cae1eb5352446c554c2		062afbf81f6ce8193c53f8d26ac71324fc1db878379178abd695cf04a0fae3432d
	c43ac4aa3e2db5cf5e366df635ce156a277ebdbe78c5598588c98257069253127e57c9735b498f29		1efffa73bba15b4e81fbaf598146a0c3edafc
	39f14e1d019795cbd74cee2693acda2666624f174e8f666494aa12641bce0677acd20e5552d26901		pi = 745cc4b6cb75b925194374cdf91b498e8d687c5d9cae1eb5352446c554c2c
	17bddb38678a18acdc380bd9d93f3b10960f9be0c141fc14f5f30da324ff14020cb5b8aed9fbca3f		43ac4aa3e2db5cf5e366df635ce156a277ebdbe78c5598588c98257069253127e5
	c44b4973d8e5527bd81f5ae5da67e5cc995abd1f7f9cdd3fa89b243fd4d5d5086ddb4eed77a2851f		7c9735b498f2939f14e1d019795cbd74cee2693acda2666624f174e8f666494aa1
	da1d4463f5ee037a4015aa40c420c2e609d5d0da4ef4a1622131022bdd9c9dc26d177b392663ea42		2641bce0677acd20e5552d2690117bddb38678a18acdc380bd9d93f3b10960f9be
	050ef485fe9d53a8d28d84b82a21101bed5b213c82b578ce7c9c6f7c1bf9eca3c248ace9f8835f38		0c141fc14f5f30da324ff14020cb5b8aed9fbca3fc44b4973d8e5527bd81f5ae5d
	50158749111ce1a3bdf5766add72a95a47c8866a4817c42c5cbd85d7bef52afab567e564f6625be9		a67e5cc995abd1f7f9cdd3fa89b243fd4d5d5086ddb4eed77a2851fda1d4463f5e
	e04be6f7da012af68e6623ce4f29c692ba0b5f7665bb435a2168bd3b88aae0c6168bb87ea6977f35		e037a4015aa40c420c2e609d5d0da4ef4a1622131022bdd9c9dc26d177b392663e
	bb5ad833d96dd14d340f2a67b241b01fd8caf415842fd0a9dd5f4ccf4e70f15efdb85332e1df2bb1		a42050ef485fe9d53a8d28d84b82a21101bed5b213c82b578ce7c9c6f7c1bf9eca
	86be15f7195176435e01bfd00592710023c3a88ac0eea7189b32296f865a310375111a5f11b74d0c		3c248ace9f8835f3850158749111ce1a3bdf5766add72a95a47c8866a4817c42c5
	74b98dfe4c41ccbe695ea801ba47f37b878c1ed0fff8302705b63c891209ea63defa892969e015a8		cbd85d7bef52afab567e564f6625be9e04be6f7da012af68e6623ce4f29c692ba0
	6d97945189444524e5fb660f2b9d1dce337a12e0d003ea6262ca3194515cc3aa10b1a03ac9dd6995		b5f7665bb435a2168bd3b88aae0c6168bb87ea6977f35bb5ad833d96dd14d340f2
	b54d</li>		a67b241b01fd8caf415842fd0a9dd5f4ccf4e70f15efdb85332e1df2bb186be15f
	<li>beta = b663c5f90da1c12cd5d0e6d049679459e6f79f9fe16bc8b8e7e4d64d66		7195176435e01bfd00592710023c3a88ac0eea7189b32296f865a310375111a5f1
	500bd9</li>		1b74d0c74b98dfe4c41ccbe695ea801ba47f37b878c1ed0fff8302705b63c89120
	</ul>		9ea63defa892969e015a86d97945189444524e5fb660f2b9d1dce337a12e0d003e
			a6262ca3194515cc3aa10b1a03ac9dd6995b54d
			beta =
			b663c5f90da1c12cd5d0e6d049679459e6f79f9fe16bc8b8e7e4d64d66500bd9
			]]></sourcecode>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>RSA-FDH-VRF-SHA384</name>		<name>RSA-FDH-VRF-SHA384</name>
	<t>Example 4, using the 2048-bit key above:</t>		<t>Example 4, using the 2048-bit key above:</t>
	<ul empty="true" spacing="compact">		<sourcecode type="test-vectors"><![CDATA[alpha = (the empty string)
	<li>alpha = (the empty string)</li>		EM = 1fa5c0079423d46edb63a833abb2e6ecfd5f39d1f2bd68fc666274d9e8ed8
	<li>EM = 1fa5c0079423d46edb63a833abb2e6ecfd5f39d1f2bd68fc666274d9e8ed		ea8a13411126861167a4ba1d014d5ae213372de6bb4227b12e68e16e13ce108536
	8ea8a13411126861167a4ba1d014d5ae213372de6bb4227b12e68e16e13ce108536acb25f7219c49		acb25f7219c49388f757219716fcb74eb0245b826c7e47ca793864885684b7673e
	388f757219716fcb74eb0245b826c7e47ca793864885684b7673e2f8579f26e78d63a940eacb23bf		2f8579f26e78d63a940eacb23bf7619290cb5cd20859482c410fbd6d83a61f8940
	7619290cb5cd20859482c410fbd6d83a61f8940866f512be7ac041fc23c3ee71d918ec994f3efa62		866f512be7ac041fc23c3ee71d918ec994f3efa62f4f1f44eaa29f5b37a1e93e24
	f4f1f44eaa29f5b37a1e93e2473d8677fcbec312838379a3e05899ce44227c0c428fbd7d4f2d0b46		73d8677fcbec312838379a3e05899ce44227c0c428fbd7d4f2d0b46cfde7254e39
	cfde7254e3967b220f8661f5dfbce7a3bf19364f522914478cead3eff0f0e02d166c251319bcf867		67b220f8661f5dfbce7a3bf19364f522914478cead3eff0f0e02d166c251319bcf
	01af1c48436f49ceac990f52940f7da6ac6f5fdafa5c55dc77</li>		86701af1c48436f49ceac990f52940f7da6ac6f5fdafa5c55dc77
	<li>pi = cffe6067bd9a1285dc1e8e543e8582c1250407cbfbcb2d01c4ddbc0d4ecb		pi = cffe6067bd9a1285dc1e8e543e8582c1250407cbfbcb2d01c4ddbc0d4ecb5
	5edeb721fb33147cf95f3084f7ce611f9877814770b14b8a671abc7ff085cf5cbe91e72d17f076d6		edeb721fb33147cf95f3084f7ce611f9877814770b14b8a671abc7ff085cf5cbe9
	2db478d4758412a4e4b77a5591dc32b764a501d27e34e56189ba7347a96f141ed1290f8ef7c4ce40		1e72d17f076d62db478d4758412a4e4b77a5591dc32b764a501d27e34e56189ba7
	09a9aba0715cbd0148721ea72bce00a22e59460421a21e4d121fc0b4eda62479d93724afae7556ab		347a96f141ed1290f8ef7c4ce4009a9aba0715cbd0148721ea72bce00a22e59460
	e66326487be38cfb795ac1968c33a3890f2d8c0f7dfbe88bc76f16cbfd2b0f7ee8663abfd7b789ca		421a21e4d121fc0b4eda62479d93724afae7556abe66326487be38cfb795ac1968
	a5f6c77dd1ca991c9a9cc532f7550ad6184c8ece12ca4bea7e67f32405416a1f83245b09d06e7b42		c33a3890f2d8c0f7dfbe88bc76f16cbfd2b0f7ee8663abfd7b789caa5f6c77dd1c
	14157fb444be12a2eddc4381678f2b862fb240fcedd2da7ffcb3</li>		a991c9a9cc532f7550ad6184c8ece12ca4bea7e67f32405416a1f83245b09d06e7
	<li>beta = dc37e83f8de0e990abada5096a05ca74754cfe7fe8e46b831e24100919		b4214157fb444be12a2eddc4381678f2b862fb240fcedd2da7ffcb3
	415415dcd5a305f5fb8195713cebc78649c8d1</li>		beta = dc37e83f8de0e990abada5096a05ca74754cfe7fe8e46b831e241009194
	</ul>		15415dcd5a305f5fb8195713cebc78649c8d1
			]]></sourcecode>
	<t>Example 5, using the 3072-bit key above:</t>		<t>Example 5, using the 3072-bit key above:</t>
	<ul empty="true" spacing="compact">		<sourcecode type="test-vectors"><![CDATA[alpha = 74657374 (4 bytes; ASCII "test"
	<li>alpha = 74657374 (4 bytes; ASCII "test")</li>		)
	<li>EM = fa2fd7c735c961b43b01c005faefc4e39505ede3914076d4dee40d52acf7		EM = fa2fd7c735c961b43b01c005faefc4e39505ede3914076d4dee40d52acf72
	27de1782386ad6e9e07faf7666c8f45fde93b024d97c40651b957cfcccc42b8596a68a5495c02313		7de1782386ad6e9e07faf7666c8f45fde93b024d97c40651b957cfcccc42b8596a
	ed9ecbb705ab0689c38b9e57af035189e377ad50b4704004c2a973d9f7554204b03e8b925a973d41		68a5495c02313ed9ecbb705ab0689c38b9e57af035189e377ad50b4704004c2a97
	a9c3432246eb2eab2f729f03d3a63c9c38c0cc2baa440ed5e2d61644405e4b5c1acaac85d8de75a4		3d9f7554204b03e8b925a973d41a9c3432246eb2eab2f729f03d3a63c9c38c0cc2
	de00419a478e6c44a97b3e89875c318400ce8d75b84c416ffd501ba78dd3203f21c6610fcaa4d8fc		baa440ed5e2d61644405e4b5c1acaac85d8de75a4de00419a478e6c44a97b3e898
	94f45e80dc65b7e48967199e7acdb18d82413b7018192a6fa2da5d6838adb8e6139f8d12abcce7d5		75c318400ce8d75b84c416ffd501ba78dd3203f21c6610fcaa4d8fc94f45e80dc6
	fd20cfa031c4971e563d4863d498591dc652a937db5e0bfd68535e3c9db96118874287c2291a5d3b		5b7e48967199e7acdb18d82413b7018192a6fa2da5d6838adb8e6139f8d12abcce
	29aa142795e60f1ade2c8c4d627ee678b652f5fded61f9a60d2fa9cf5fb5e6a7fd63d81c91ea2269		7d5fd20cfa031c4971e563d4863d498591dc652a937db5e0bfd68535e3c9db9611
	388f0a96fae77da0957695779385c75748956972ab1cb5e19ad3cc6a357b9ffd368ca985dd9c0e53		8874287c2291a5d3b29aa142795e60f1ade2c8c4d627ee678b652f5fded61f9a60
	dd42aff5985f7a234af96ad9e34e459a958b808e858f6d7be2e964c33cefad9660</li>		d2fa9cf5fb5e6a7fd63d81c91ea2269388f0a96fae77da0957695779385c757489
	<li>pi = 22c9278e7171183cf6a3ce108f0400e308a9177c39a171f77777c106c966		56972ab1cb5e19ad3cc6a357b9ffd368ca985dd9c0e53dd42aff5985f7a234af96
	eb041824ce43fa56c5c77576646dd110e0b5d7f838bd5b1d1bf2c1feb1520397dd52d3cea6dbb49d		ad9e34e459a958b808e858f6d7be2e964c33cefad9660
	786aa3bf3f5235e7692e583d290c7192102a6e0cb64f5229a326d4d00267fd75aae9687167ea0d3d		pi = 22c9278e7171183cf6a3ce108f0400e308a9177c39a171f77777c106c966e
	450b2d63519ad605e64c77438728a190a129b1163939a5b7b0721b8d81efbf99a96944f63bf80ecc		b041824ce43fa56c5c77576646dd110e0b5d7f838bd5b1d1bf2c1feb1520397dd5
	932fe40402d67c3e099a317cd1d13ac6947096308050ea6dad18fdb0958ae565d07d29e619673798		2d3cea6dbb49d786aa3bf3f5235e7692e583d290c7192102a6e0cb64f5229a326d
	f52b8d1dfdbf29b4641324ea6db5b9f35870acde7bf68e0829534d1c1f43ca9a16861efd82fb883e		4d00267fd75aae9687167ea0d3d450b2d63519ad605e64c77438728a190a129b11
	35d581f613d2dfbc89d01a84fdf081a3a850f2e865188cd995857222160c54780dc310a6ec100b9b		63939a5b7b0721b8d81efbf99a96944f63bf80ecc932fe40402d67c3e099a317cd
	ac30f3af92e641360cad8dc255b56fa28e88ffcbef8ebe6ba8557e4ec44a7d0ebef882ade36db0d8		1d13ac6947096308050ea6dad18fdb0958ae565d07d29e619673798f52b8d1dfdb
	9be71ecaa2b35026c9d328d2384b54ae68de2ea70160ddde9aced5a8d896590fc185b408732cc04a		f29b4641324ea6db5b9f35870acde7bf68e0829534d1c1f43ca9a16861efd82fb8
	249eff27501594902bf3af4a3743c4da50c5d62a74746007dedb8358ecfef78c75ab</li>		83e35d581f613d2dfbc89d01a84fdf081a3a850f2e865188cd995857222160c547
	<li>beta = 5bdf742667ad10080f4ca573ec66f751e82e4077d0db1b281df421af68		80dc310a6ec100b9bac30f3af92e641360cad8dc255b56fa28e88ffcbef8ebe6ba
	d39412e70362dc5101b4b46e1e453eea7e0989</li>		8557e4ec44a7d0ebef882ade36db0d89be71ecaa2b35026c9d328d2384b54ae68d
	</ul>		e2ea70160ddde9aced5a8d896590fc185b408732cc04a249eff27501594902bf3a
			f4a3743c4da50c5d62a74746007dedb8358ecfef78c75ab
			beta = 5bdf742667ad10080f4ca573ec66f751e82e4077d0db1b281df421af68d
			39412e70362dc5101b4b46e1e453eea7e0989
			]]></sourcecode>
	<t>Example 6, using the 4096-bit key above:</t>		<t>Example 6, using the 4096-bit key above:</t>
	<ul empty="true" spacing="compact">		<sourcecode type="test-vectors"><![CDATA[alpha = 73616d706c65 (6 bytes; ASCII "s
	<li>alpha = 73616d706c65 (6 bytes; ASCII "sample")</li>		ample")
	<li>EM = 1b1d2f330ee20b9b1754f5e6ee4126cf03ea2c7f4e8c52d96111da7f9950		EM = 1b1d2f330ee20b9b1754f5e6ee4126cf03ea2c7f4e8c52d96111da7f99509
	9042428ec2f2eafdf41716c04a9976a26df77b3d4cea8b10b216e7786fb49e923d984a2ee13ad82b		042428ec2f2eafdf41716c04a9976a26df77b3d4cea8b10b216e7786fb49e923d9
	95783b68fcf3444b65d1353619602ae06e392dc030be105d4cebc6ff8a647b79115357833bd5312b		84a2ee13ad82b95783b68fcf3444b65d1353619602ae06e392dc030be105d4cebc
	9d3f0df1a307e782ff4db8de0eb16259d6bff2f57b3dd60a57693d607c42013cbcfc140a77d4a651		6ff8a647b79115357833bd5312b9d3f0df1a307e782ff4db8de0eb16259d6bff2f
	492854afbacca377ed6729d1cbe72999a62a96190fb630e5abc54d5cbe93254426df4e2315dbc777		57b3dd60a57693d607c42013cbcfc140a77d4a651492854afbacca377ed6729d1c
	360ffb2401b3dedbed1acacf4b3a63b5ff8e5ab6c0f8ffd9e2a34fffd68a8a593c64de2660dcedaa		be72999a62a96190fb630e5abc54d5cbe93254426df4e2315dbc777360ffb2401b
	ab13cd42ebf5720d49f3120b01f45f29d1f465e995b148c9266aa97793a9da2f38831d00f95f9688		3dedbed1acacf4b3a63b5ff8e5ab6c0f8ffd9e2a34fffd68a8a593c64de2660dce
	b1c50b52a4cbcc14f8287db822381cdddf609c9c178286b1bc2f94d7ef4d5ceb1293dd7b0fac16d1		daaab13cd42ebf5720d49f3120b01f45f29d1f465e995b148c9266aa97793a9da2
	b3a8b2a7fcc454e52efd2de5a799397fd55a909641fa775463f4808b520c3ebe0f94e2765f8538d9		f38831d00f95f9688b1c50b52a4cbcc14f8287db822381cdddf609c9c178286b1b
	1a4f53bb746e7d5eaf55b3876503760f5c015f9e52bc54bdfc9632028db5e88b7dc0b1e9f1661d0a		c2f94d7ef4d5ceb1293dd7b0fac16d1b3a8b2a7fcc454e52efd2de5a799397fd55
	9b3574e46311de8ef6278c4c14f68375763e5df0d4cf221a4c3e84493ed0c36984c172d87b513857		a909641fa775463f4808b520c3ebe0f94e2765f8538d91a4f53bb746e7d5eaf55b
	af4b6c10174dea9db6464e2bab210aa492987f0255d2c5588b1c79769da03b62f691d5c4e5fac655		3876503760f5c015f9e52bc54bdfc9632028db5e88b7dc0b1e9f1661d0a9b3574e
	05c317bf96b4f70e97c002aa0a032b02e48ee3aead5703bde3186ce138f29ba36219fd3558af4179		46311de8ef6278c4c14f68375763e5df0d4cf221a4c3e84493ed0c36984c172d87
	45</li>		b513857af4b6c10174dea9db6464e2bab210aa492987f0255d2c5588b1c79769da
	<li>pi = 89d801e364fd48c3b8672e7d7abd8a2a1e5bd36bb1e38af5aaefa2f01cde		03b62f691d5c4e5fac65505c317bf96b4f70e97c002aa0a032b02e48ee3aead570
	686fa2e33f88fdcc8eb3babcf1c66cbbf7dcddb614041813990787be5feabe86bbec373d2cbf7c08		3bde3186ce138f29ba36219fd3558af417945
	0caa0e37a339d5de1d1455de28f9bef76cd72500c669e9cab4599b55dc155d9dd5810174c170f646		pi = 89d801e364fd48c3b8672e7d7abd8a2a1e5bd36bb1e38af5aaefa2f01cde6
	d3b0b459347c17347c0281eecf5055cf887d6bd0a2c962c77d5ff9355a53cea64c34ea0888110ec4		86fa2e33f88fdcc8eb3babcf1c66cbbf7dcddb614041813990787be5feabe86bbe
	eb32da69022e293a8843d4c06c9d6e020c594335720467a8337c6a939fb2c5d710f7bdab48a52f4e		c373d2cbf7c080caa0e37a339d5de1d1455de28f9bef76cd72500c669e9cab4599
	7483dae062c1b9f66f7c9038ba9ceef3d61cb4cc004319c94a267a2425b5f042cd7f1a17922d6596		b55dc155d9dd5810174c170f646d3b0b459347c17347c0281eecf5055cf887d6bd
	a88a6fefaef41fc87742f2badee7d7613179589b4d02611ac8fd7895d926f484f79542cdf7f034dd		0a2c962c77d5ff9355a53cea64c34ea0888110ec4eb32da69022e293a8843d4c06
	536c9596da2f588ac9840f6bb05875bd17107e7458cc5ea368a7699fd60c35b54253a718c26cf518		c9d6e020c594335720467a8337c6a939fb2c5d710f7bdab48a52f4e7483dae062c
	712be9d86213b2c6bddd0b7dd169f9240e77bfc44223675454f9c5596ad2e6e607ea65011a721ecb		1b9f66f7c9038ba9ceef3d61cb4cc004319c94a267a2425b5f042cd7f1a17922d6
	fa993172ae372ae8743779b33278d25e11ced77b14bc481fce60e4fc10a8a211d8b359906509d683		596a88a6fefaef41fc87742f2badee7d7613179589b4d02611ac8fd7895d926f48
	0c653d91c1a86865219db43f62c70ac6780644d2bd73c5c256527a3eaefaebaf1f220732417e17db		4f79542cdf7f034dd536c9596da2f588ac9840f6bb05875bd17107e7458cc5ea36
	f598636616f70f2088969ac796a853dc8a5f270a1c505797e83d1675e4f40b59c150ca06c49bb096		8a7699fd60c35b54253a718c26cf518712be9d86213b2c6bddd0b7dd169f9240e7
	7a2e0c7e74eff9e182d0f7bb6f54f68fe788b89d2191c87bbf7f3927978449c2174baa581dc64a9c		7bfc44223675454f9c5596ad2e6e607ea65011a721ecbfa993172ae372ae874377
	58ed</li>		9b33278d25e11ced77b14bc481fce60e4fc10a8a211d8b359906509d6830c653d9
	<li>beta = 8ec4d150788513c85eea3490d1a1ee1b7a397602d3f9c8b467527f09fa		1c1a86865219db43f62c70ac6780644d2bd73c5c256527a3eaefaebaf1f2207324
	b5252e539f82e8002825608295ebbba19644dd</li>		17e17dbf598636616f70f2088969ac796a853dc8a5f270a1c505797e83d1675e4f
	</ul>		40b59c150ca06c49bb0967a2e0c7e74eff9e182d0f7bb6f54f68fe788b89d2191c
			87bbf7f3927978449c2174baa581dc64a9c58ed
			beta = 8ec4d150788513c85eea3490d1a1ee1b7a397602d3f9c8b467527f09fab
			5252e539f82e8002825608295ebbba19644dd
			]]></sourcecode>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>RSA-FDH-VRF-SHA512</name>		<name>RSA-FDH-VRF-SHA512</name>
	<t>Example 7, using the 2048-bit key above:</t>		<t>Example 7, using the 2048-bit key above:</t>
	<ul empty="true" spacing="compact">		<sourcecode type="test-vectors"><![CDATA[alpha = (the empty string)
	<li>alpha = (the empty string)</li>		EM = 7b08a7fff4e5d8fd4978ac5a0ddf48537a2bb3f952dcdc00affb25d747b40
	<li>EM = 7b08a7fff4e5d8fd4978ac5a0ddf48537a2bb3f952dcdc00affb25d747b4		85c29c68dddaa87378db32396219ce784acebe70699286318f42794927f546de5d
	085c29c68dddaa87378db32396219ce784acebe70699286318f42794927f546de5d85bbefd80a02c		85bbefd80a02c3aa714fc17090baa0d0f7fb504e1af0b79ea02d41dc0bf576b8f2
	3aa714fc17090baa0d0f7fb504e1af0b79ea02d41dc0bf576b8f21472dd4c55f96bd64772d3ebd03		1472dd4c55f96bd64772d3ebd0347abe74b9fdf35b754d0405e42ceb0e290fdd91
	47abe74b9fdf35b754d0405e42ceb0e290fdd91ef766a3e27ff59cd86572d15274f6fd49400ec4d1		ef766a3e27ff59cd86572d15274f6fd49400ec4d126145f3cae200d67d5d108999
	26145f3cae200d67d5d10899961658ece7dcbf41f1cca63f8b50399955416a1f55e0af116fac2a9f		61658ece7dcbf41f1cca63f8b50399955416a1f55e0af116fac2a9fd1f2dc0085e
	d1f2dc0085e6ad6c1c4bc12d9308d9a030c3e2ea7f037d1c98beb23d43d67a97e5bf52382b8e890c		6ad6c1c4bc12d9308d9a030c3e2ea7f037d1c98beb23d43d67a97e5bf52382b8e8
	5967ab42f2010cac985d3a52fe726045746d4ffef901127646</li>		90c5967ab42f2010cac985d3a52fe726045746d4ffef901127646
	<li>pi = a280db108df5ad6ac1bed67efbc5c6fc6da0d301b9c0b41d26e379cd223c		pi = a280db108df5ad6ac1bed67efbc5c6fc6da0d301b9c0b41d26e379cd223c6
	613c59d52c987e4baaa6de4de2103284ddd56aa0b662dfe8faa8f6a503b83b7c81f481e23a08761d		13c59d52c987e4baaa6de4de2103284ddd56aa0b662dfe8faa8f6a503b83b7c81f
	49a151ada1d9daa132138bbd6f80204c7fa87716b120df957224f92b32a3a0f96c3b209080c40861		481e23a08761d49a151ada1d9daa132138bbd6f80204c7fa87716b120df957224f
	8a92382ab5575f10a57c24ee0ffd01d6b822dc36b27600bf36aafadf0a01e65aa6a0f2fc1a9dcd20		92b32a3a0f96c3b209080c408618a92382ab5575f10a57c24ee0ffd01d6b822dc3
	7d9bf5181a9ca69120e15410800a26efd3ce619349592eeff7b1851737bd033a83f88744ddd3d3e7		6b27600bf36aafadf0a01e65aa6a0f2fc1a9dcd207d9bf5181a9ca69120e154108
	82efb6d2438ffda22ddcaa32c821c6730a05d5bdab88c354809d615884744ff10276496bee70b62f		00a26efd3ce619349592eeff7b1851737bd033a83f88744ddd3d3e782efb6d2438
	eb6ed07a3948823e9ee2a453dbcd4450192c9de0128adfc7e147</li>		ffda22ddcaa32c821c6730a05d5bdab88c354809d615884744ff10276496bee70b
	<li>beta = 808ca1f8f66a48118aacb011394bd4e5f0011c89ca913943d467b81cc5		62feb6ed07a3948823e9ee2a453dbcd4450192c9de0128adfc7e147
	c43086e588abdde061c3ee30f4c15b2a6b51ad0ada42c0737fd7b2206fb43d35c8ed22</li>		beta = 808ca1f8f66a48118aacb011394bd4e5f0011c89ca913943d467b81cc5c
	</ul>		43086e588abdde061c3ee30f4c15b2a6b51ad0ada42c0737fd7b2206fb43d35c8e
			d22
			]]></sourcecode>
	<t>Example 8, using the 3072-bit key above:</t>		<t>Example 8, using the 3072-bit key above:</t>
	<ul empty="true" spacing="compact">		<sourcecode type="test-vectors"><![CDATA[alpha = 74657374 (4 bytes; ASCII "test"
	<li>alpha = 74657374 (4 bytes; ASCII "test")</li>		)
	<li>EM = 803b6618f0ad47da2db309b1f57807a286500020c9e2b1427ebd9fff1104		EM = 803b6618f0ad47da2db309b1f57807a286500020c9e2b1427ebd9fff1104e
	e3aa8a69210441cd58344bd810c4900825c84b1e5e36825f1e397df54c4419f8525d9a09a49e7fed		3aa8a69210441cd58344bd810c4900825c84b1e5e36825f1e397df54c4419f8525
	c18b8d906cbd9ea831c55f2aaa0461e19ddd6ec9d14dafa1fcf49b77458a65427b7f060bc7425538		d9a09a49e7fedc18b8d906cbd9ea831c55f2aaa0461e19ddd6ec9d14dafa1fcf49
	e5d3af1813752cb452d0b098514110399734d1f55870c65ea3e799e6d9024a9e2fb95883e5805788		b77458a65427b7f060bc7425538e5d3af1813752cb452d0b098514110399734d1f
	11a8c7d34b18f8fabc6c05fb9697335fcf2cb1b7576ee7a39dcff129e1f142106c45f30a8ae62370		55870c65ea3e799e6d9024a9e2fb95883e580578811a8c7d34b18f8fabc6c05fb9
	f576d1d1d8c6307fccfe25cb431f348dea81b6b7e6307bbefda2a0b23036653a612226392a573b7d		697335fcf2cb1b7576ee7a39dcff129e1f142106c45f30a8ae62370f576d1d1d8c
	62e28f9fecc7f4be0bf0a3049ce8ed276b34130faa943aeeedf962b42a3fc6c881bbf9a62039e9c0		6307fccfe25cb431f348dea81b6b7e6307bbefda2a0b23036653a612226392a573
	850f1393a2a02c6848d06c3520e086541d8af99ea3ef9f9da2e3b2bd3172682a47e5965899bc576b		b7d62e28f9fecc7f4be0bf0a3049ce8ed276b34130faa943aeeedf962b42a3fc6c
	66e29a0b8dcf06871202a1a4e7f2ff19bdd9eac2241129a73d7d01303b80372ac62a0d5b6bfd1d71		881bbf9a62039e9c0850f1393a2a02c6848d06c3520e086541d8af99ea3ef9f9da
	19e561ace229cd53d2c9963d6127b9ade16dce4b07d1cd89247ffc438811dc8b3c</li>		2e3b2bd3172682a47e5965899bc576b66e29a0b8dcf06871202a1a4e7f2ff19bdd
	<li>pi = 1aa828e0a751074fed2fa776fd29336a84987c064eeebcd3a8129fb688b4		9eac2241129a73d7d01303b80372ac62a0d5b6bfd1d7119e561ace229cd53d2c99
	7eb7109987d01db0c3624ba7cc75e2f1ad60f5e204a250a329048bc34df34d41bfeea6651774d249		63d6127b9ade16dce4b07d1cd89247ffc438811dc8b3c
	ff9fc29aeabdf524400527aa1c4100b1af86b2dcc2e7aecc77f386b80f29ccd807cb705b50574318		pi = 1aa828e0a751074fed2fa776fd29336a84987c064eeebcd3a8129fb688b47
	32dafe56733a1e7bfcba1d052a26d1a8512f297b5abad5afd64fbcf21b57531a9b2c8217c0d9f1c8		eb7109987d01db0c3624ba7cc75e2f1ad60f5e204a250a329048bc34df34d41bfe
	75c196d998f61e8017f6b6ebe7317545ed390e18305bc96abb1514ec271963d02bed91ccf029d022		ea6651774d249ff9fc29aeabdf524400527aa1c4100b1af86b2dcc2e7aecc77f38
	189f84bac8cfa216da54e39919118348dfea6f4f6532b49da7820ee2a21f42b762e107722ad0abf6		6b80f29ccd807cb705b5057431832dafe56733a1e7bfcba1d052a26d1a8512f297
	2271e0640d6b1c4d1a39b94ebd74b4283de2d6550cbdb1f29cac51671e9c8fc0ea0fdbb082a14a22		b5abad5afd64fbcf21b57531a9b2c8217c0d9f1c875c196d998f61e8017f6b6ebe
	1e0531615f2bcfba0d70e99e4997cb00f81fcab2b955663220234a5e90f29bd08e6fa50dd92770d9		7317545ed390e18305bc96abb1514ec271963d02bed91ccf029d022189f84bac8c
	e514e0f9eb27aee634877bcea681ffd7da2b5be2f80c1dde1243b17ac726401cf961c5ce06640eb9		fa216da54e39919118348dfea6f4f6532b49da7820ee2a21f42b762e107722ad0a
	3352402c1ebc59c92188c511b375d63124846b46017fe36dc13fc2d34dbd80b312e0</li>		bf62271e0640d6b1c4d1a39b94ebd74b4283de2d6550cbdb1f29cac51671e9c8fc
	<li>beta = 9202b6715b7921c5eb35572ed9ebb85848d3345efadd665049ce889be4		0ea0fdbb082a14a221e0531615f2bcfba0d70e99e4997cb00f81fcab2b95566322
	6322586d4177864c9179468473518c6b6ac2e9c85ae5ee5fcd3c0d8e6d4d8f18be6238</li>		0234a5e90f29bd08e6fa50dd92770d9e514e0f9eb27aee634877bcea681ffd7da2
	</ul>		b5be2f80c1dde1243b17ac726401cf961c5ce06640eb93352402c1ebc59c92188c
			511b375d63124846b46017fe36dc13fc2d34dbd80b312e0
			beta = 9202b6715b7921c5eb35572ed9ebb85848d3345efadd665049ce889be46
			322586d4177864c9179468473518c6b6ac2e9c85ae5ee5fcd3c0d8e6d4d8f18be6
			238
			]]></sourcecode>
	<t>Example 9, using the 4096-bit key above:</t>		<t>Example 9, using the 4096-bit key above:</t>
	<ul empty="true" spacing="compact">		<sourcecode type="test-vectors"><![CDATA[alpha = 73616d706c65 (6 bytes; ASCII "s
	<li>alpha = 73616d706c65 (6 bytes; ASCII "sample")</li>		ample")
	<li>EM = 289607894786ccf223b1e758232f3402aa50cd48bca3d2bd64b2ea9b4a69		EM = 289607894786ccf223b1e758232f3402aa50cd48bca3d2bd64b2ea9b4a69d
	dc91756a42b2c1feaaa777763b9b7c91888c580433ac85f5fbb360f129ecee739f69b560657687d3		c91756a42b2c1feaaa777763b9b7c91888c580433ac85f5fbb360f129ecee739f6
	8f7d43c84f6605005c38f56c91310eff27bae49b14d8a36542d69b70efca8637b845be0f029c085a		9b560657687d38f7d43c84f6605005c38f56c91310eff27bae49b14d8a36542d69
	7b6aad6ca0eb65fffdf8d55d9538d3b54044ebbc26e092b2f3ddaece7aa5b4b234ec848bfdc72a4e		b70efca8637b845be0f029c085a7b6aad6ca0eb65fffdf8d55d9538d3b54044ebb
	cdc10c66fb845cfc5ad39756e7f26007cea0ebf1e878636f4e39308fe7a317a9b7e90051536ac028		c26e092b2f3ddaece7aa5b4b234ec848bfdc72a4ecdc10c66fb845cfc5ad39756e
	bc1a2ec200a5dad0e3b74717bd9e7ea620919e315799e0fea7b0895fcbc0b95686b2495dc23e3cd5		7f26007cea0ebf1e878636f4e39308fe7a317a9b7e90051536ac028bc1a2ec200a
	6a16652b0df0dbd3ca8a6c96b13973a0c31a5541e211229da8a56e588a616c721baab8e2d3031300		5dad0e3b74717bd9e7ea620919e315799e0fea7b0895fcbc0b95686b2495dc23e3
	8c2374887f147598468b378bf8949ab1165b9348245d0a6a5f795918fce05f0d072f81f78c7224e7		cd56a16652b0df0dbd3ca8a6c96b13973a0c31a5541e211229da8a56e588a616c7
	f1c4684877d714f231d5775c887590861212eae2d174761158ac7d653b18f0d4b71362c0eb8a67be		21baab8e2d30313008c2374887f147598468b378bf8949ab1165b9348245d0a6a5
	d1a48a4e7dc739b2b44694514cae7f192d236afb1ab2409f24dfa94a2d705d0087860d844ba04564		f795918fce05f0d072f81f78c7224e7f1c4684877d714f231d5775c88759086121
	bb6733ca20089417d74eaed86d7e68ced681e9d88a9c3d7e6a33927592820cb9a38d4539332e5092		2eae2d174761158ac7d653b18f0d4b71362c0eb8a67bed1a48a4e7dc739b2b4469
	96489e54cd6b8495f100c36debe1f719578b15e8a99cc8febc3212e81478aeca616a5230ae84e707		4514cae7f192d236afb1ab2409f24dfa94a2d705d0087860d844ba04564bb6733c
	9f52aefb2ec2a97157fb5d60e1ddcf03b134be2c93ffba41d5d068750adc8df07e5a264640f7e586		a20089417d74eaed86d7e68ced681e9d88a9c3d7e6a33927592820cb9a38d45393
	bd</li>		32e509296489e54cd6b8495f100c36debe1f719578b15e8a99cc8febc3212e8147
	<li>pi = 17d7635cac33b0b72ea1c0afb1f681d1a96c5073ed9f88ed8bb54eb428d7		8aeca616a5230ae84e7079f52aefb2ec2a97157fb5d60e1ddcf03b134be2c93ffb
	b2db4ee3355eee512ddc7af50694b37fd389f990278e22095b2582c78c4ed6070b0c7382b0308b6d		a41d5d068750adc8df07e5a264640f7e586bd
	546141a9b0d6ebb3af97abd93c16a5d34a2d805d8aa444fed2297d017571a693d221fda094d40500		pi = 17d7635cac33b0b72ea1c0afb1f681d1a96c5073ed9f88ed8bb54eb428d7b
	ab9b203d397a7543e72b26b06e561d49696e01deebfed58b46611dd5a346e227d7519f8ffd1dc76a		2db4ee3355eee512ddc7af50694b37fd389f990278e22095b2582c78c4ed6070b0
	172c9f7f355c3e7e5ee7773edab00a22af5c39367f3779da68ce6da9f8a594f5f614901250118165		c7382b0308b6d546141a9b0d6ebb3af97abd93c16a5d34a2d805d8aa444fed2297
	3572fe5549a9c2bf36148b3bdc94feaedd600727fe5c11b7dcbfd73002ae08061cb4b84ba47f1bf8		d017571a693d221fda094d40500ab9b203d397a7543e72b26b06e561d49696e01d
	c5d46bc2acb7cb4964a6dca7eedc396e663a64121d93dade8b83cea09d76653cca1a8d20d6b7323a		eebfed58b46611dd5a346e227d7519f8ffd1dc76a172c9f7f355c3e7e5ee7773ed
	890651dc575025ba1be02d08c5946f50cde438339b06e8633198da0d467d2cac7d98ae62dd71353f		ab00a22af5c39367f3779da68ce6da9f8a594f5f6149012501181653572fe5549a
	6fb19aa9daac851d0ce237b21db93b91e518d5c1ac36cdf874975deb7aab3942acc3980f221f33ad		9c2bf36148b3bdc94feaedd600727fe5c11b7dcbfd73002ae08061cb4b84ba47f1
	1254eb8ac3138e087d045c4746e0b7eedcaf2a1a173559783eba8691555c1b0e468f8efe6501679b		bf8c5d46bc2acb7cb4964a6dca7eedc396e663a64121d93dade8b83cea09d76653
	760038ed6fc9ce6aa5ae24b3f1178713793c8e5ee96035a2f0ee02e2d10ac098613358d3cff10f4d		cca1a8d20d6b7323a890651dc575025ba1be02d08c5946f50cde438339b06e8633
	ff3437f2a48252c5d6805288fbd7ee05356f80db12aaeabf6638677abf5b8eb2376fb76861cf1b81		198da0d467d2cac7d98ae62dd71353f6fb19aa9daac851d0ce237b21db93b91e51
	7d5a0b878dae6beac44f078f37d982d941a77582a77784fabd632e28d664d9f705f31e24d1ca623d		8d5c1ac36cdf874975deb7aab3942acc3980f221f33ad1254eb8ac3138e087d045
	fac7</li>		c4746e0b7eedcaf2a1a173559783eba8691555c1b0e468f8efe6501679b760038e
	<li>beta = 6026f6defaf534cc79ce7c1b0370fb53e4825d2d44f549f696e06d693c		d6fc9ce6aa5ae24b3f1178713793c8e5ee96035a2f0ee02e2d10ac098613358d3c
	39e852e21a5e3b6ff093618dd277b40678957e1b90e8e6ca742efed30dc309b3b242b8</li>		ff10f4dff3437f2a48252c5d6805288fbd7ee05356f80db12aaeabf6638677abf5
	</ul>		b8eb2376fb76861cf1b817d5a0b878dae6beac44f078f37d982d941a77582a7778
			4fabd632e28d664d9f705f31e24d1ca623dfac7
			beta = 6026f6defaf534cc79ce7c1b0370fb53e4825d2d44f549f696e06d693c3
			9e852e21a5e3b6ff093618dd277b40678957e1b90e8e6ca742efed30dc309b3b24
			2b8
			]]></sourcecode>
	</section>		</section>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Test Vectors for the ECVRF ciphersuites</name>		<name>Test Vectors for the ECVRF Ciphersuites</name>
	<t>The test vectors in this section were generated using code at <eref tar		<t>The test vectors in this section were generated using code provided at
	get="https://github.com/reyzin/ecvrf"/>.</t>		<eref target="https://github.com/reyzin/ecvrf" brackets="angle"/>.</t>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>ECVRF-P256-SHA256-TAI</name>		<name>ECVRF-P256-SHA256-TAI</name>
	<t>The example secret keys and messages in Examples 10 and 11 are taken from Appendix A.2.5 of <xref target="RFC6979" format="default"/>.</t>		<t>The example secret keys and messages in Examples 10 and 11 are taken from <xref target="RFC6979" sectionFormat="of" section="A.2.5"/>.</t>
	<t>Example 10:</t>		<t>Example 10:</t>
	<ul empty="true" spacing="compact">		<sourcecode type="test-vectors"><![CDATA[SK = x =
	<li>SK = x = c9afa9d845ba75166b5c215767b1d6934e50c3db36e89b127b8a622b1		c9afa9d845ba75166b5c215767b1d6934e50c3db36e89b127b8a622b120f6721
	20f6721</li>		PK =
	<li>PK = 0360fed4ba255a9d31c961eb74c6356d68c049b8923b61fa6ce669622e60f		0360fed4ba255a9d31c961eb74c6356d68c049b8923b61fa6ce669622e60f29fb6
	29fb6</li>		alpha = 73616d706c65 (6 bytes; ASCII "sample")
	<li>alpha = 73616d706c65 (6 bytes; ASCII "sample")</li>		try_and_increment succeeded on ctr = 1
	<li>try_and_increment succeeded on ctr = 1</li>		H =
	<li>H = 0272a877532e9ac193aff4401234266f59900a4a9e3fc3cfc6a4b7e467a15d		0272a877532e9ac193aff4401234266f59900a4a9e3fc3cfc6a4b7e467a15d06d4
	06d4</li>		k =
	<li>k = 0d90591273453d2dc67312d39914e3a93e194ab47a58cd598886897076986f		0d90591273453d2dc67312d39914e3a93e194ab47a58cd598886897076986f77
	77</li>		U = k*B =
	<li>U = k*B = 02bb6a034f67643c6183c10f8b41dc4babf88bff154b674e377d90bd		02bb6a034f67643c6183c10f8b41dc4babf88bff154b674e377d90bde009c21672
	e009c21672</li>		V = k*H =
	<li>V = k*H = 02893ebee7af9a0faa6da810da8a91f9d50e1dc071240c9706726820		02893ebee7af9a0faa6da810da8a91f9d50e1dc071240c9706726820ff919e8394
	ff919e8394</li>		pi = 035b5c726e8c0e2c488a107c600578ee75cb702343c153cb1eb8dec77f4b5
	<li>pi = 035b5c726e8c0e2c488a107c600578ee75cb702343c153cb1eb8dec77f4b5		071b4a53f0a46f018bc2c56e58d383f2305e0975972c26feea0eb122fe7893c15a
	071b4a53f0a46f018bc2c56e58d383f2305e0975972c26feea0eb122fe7893c15af376b33edf7de1		f376b33edf7de17c6ea056d4d82de6bc02f
	7c6ea056d4d82de6bc02f</li>		beta =
	<li>beta = a3ad7b0ef73d8fc6655053ea22f9bede8c743f08bbed3d38821f0e16474		a3ad7b0ef73d8fc6655053ea22f9bede8c743f08bbed3d38821f0e16474b505e
	b505e</li>		]]></sourcecode>
	</ul>
	<t>Example 11:</t>		<t>Example 11:</t>
	<ul empty="true" spacing="compact">		<sourcecode type="test-vectors"><![CDATA[SK = x =
	<li>SK = x = c9afa9d845ba75166b5c215767b1d6934e50c3db36e89b127b8a622		c9afa9d845ba75166b5c215767b1d6934e50c3db36e89b127b8a622b120f6721
	b120f6721</li>		PK =
	<li>PK = 0360fed4ba255a9d31c961eb74c6356d68c049b8923b61fa6ce669622e6		0360fed4ba255a9d31c961eb74c6356d68c049b8923b61fa6ce669622e60f29fb6
	0f29fb6</li>		alpha = 74657374 (4 bytes; ASCII "test")
	<li>alpha = 74657374 (4 bytes; ASCII "test")</li>		try_and_increment succeeded on ctr = 3
	<li>try_and_increment succeeded on ctr = 3</li>		H =
	<li>H = 02173119b4fff5e6f8afed4868a29fe8920f1b54c2cf89cc7b301d0d473d		02173119b4fff5e6f8afed4868a29fe8920f1b54c2cf89cc7b301d0d473de6b974
	e6b974</li>		k =
	<li>k = 5852353a868bdce26938cde1826723e58bf8cb06dd2fed475213ea6f3b12		5852353a868bdce26938cde1826723e58bf8cb06dd2fed475213ea6f3b12e961
	e961</li>		U = k*B =
	<li>U = k*B = 022779a2cafcb65414c4a04a4b4d2adf4c50395f57995e89e6de82		022779a2cafcb65414c4a04a4b4d2adf4c50395f57995e89e6de823250d91bc48e
	3250d91bc48e</li>		V = k*H =
	<li>V = k*H = 033b4a14731672e82339f03b45ff6b5b13dee7ada38c9bf1d6f8f6		033b4a14731672e82339f03b45ff6b5b13dee7ada38c9bf1d6f8f61e2ce5921119
	1e2ce5921119</li>		pi = 034dac60aba508ba0c01aa9be80377ebd7562c4a52d74722e0abae7dc3080
	<li>pi = 034dac60aba508ba0c01aa9be80377ebd7562c4a52d74722e0abae7dc30		ddb56c19e067b15a8a8174905b13617804534214f935b94c2287f797e393eb0816
	80ddb56c19e067b15a8a8174905b13617804534214f935b94c2287f797e393eb0816969d864f3762		969d864f37625b443f30f1a5a33f2b3c854
	5b443f30f1a5a33f2b3c854</li>		beta =
	<li>beta = a284f94ceec2ff4b3794629da7cbafa49121972671b466cab4ce170aa		a284f94ceec2ff4b3794629da7cbafa49121972671b466cab4ce170aa365f26d
	365f26d</li>		]]></sourcecode>
	</ul>
	<t>The example secret key in Example 12 is taken from Appendix L.4.2 of <xref target="ANSI.X9-62-2005" format="default"/>.</t>		<t>The example secret key in Example 12 is taken from Appendix L.4.2 of <xref target="ANSI.X9-62-2005" format="default"/>.</t>
	<t>Example 12:</t>		<t>Example 12:</t>
	<ul empty="true" spacing="compact">		<sourcecode type="test-vectors"><![CDATA[SK = x =
	<li>SK = x = 2ca1411a41b17b24cc8c3b089cfd033f1920202a6c0de8abb97df14		2ca1411a41b17b24cc8c3b089cfd033f1920202a6c0de8abb97df1498d50d2c8
	98d50d2c8</li>		PK =
	<li>PK = 03596375e6ce57e0f20294fc46bdfcfd19a39f8161b58695b3ec5b3d164		03596375e6ce57e0f20294fc46bdfcfd19a39f8161b58695b3ec5b3d16427c274d
	27c274d</li>		alpha = 4578616d706c65207573696e67204543445341206b65792066726f6d20
	<li>alpha = 4578616d706c65207573696e67204543445341206b65792066726f6d		417070656e646978204c2e342e32206f6620414e53492e58392d36322d32303035
	20417070656e646978204c2e342e32206f6620414e53492e58392d36322d32303035 (62 bytes;		(62 bytes; ASCII "Example using ECDSA key from Appendix L.4.2 of
	ASCII "Example using ECDSA key from Appendix L.4.2 of ANSI.X9-62-2005")</li>		ANSI.X9-62-2005")
	<li>try_and_increment succeeded on ctr = 1</li>		try_and_increment succeeded on ctr = 1
	<li>H = 0258055c26c4b01d01c00fb57567955f7d39cd6f6e85fd37c58f696cc6b7		H =
	aa761d</li>		0258055c26c4b01d01c00fb57567955f7d39cd6f6e85fd37c58f696cc6b7aa761d
	<li>k = 5689e2e08e1110b4dda293ac21667eac6db5de4a46a519c73d533f69be2f		k =
	4da3</li>		5689e2e08e1110b4dda293ac21667eac6db5de4a46a519c73d533f69be2f4da3
	<li>U = k*B = 020f465cd0ec74d2e23af0abde4c07e866ae4e5138bded5dd1196b		U = k*B =
	8843f380db84</li>		020f465cd0ec74d2e23af0abde4c07e866ae4e5138bded5dd1196b8843f380db84
	<li>V = k*H = 036cb6f811428fc4904370b86c488f60c280fa5b496d2f34ff8772		V = k*H =
	f60ed24b2d1d</li>		036cb6f811428fc4904370b86c488f60c280fa5b496d2f34ff8772f60ed24b2d1d
	<li>pi = 03d03398bf53aa23831d7d1b2937e005fb0062cbefa06796579f2a1fc7e		pi = 03d03398bf53aa23831d7d1b2937e005fb0062cbefa06796579f2a1fc7e7b
	7b8c667d091c00b0f5c3619d10ecea44363b5a599cadc5b2957e223fec62e81f7b4825fc799a771a		8c667d091c00b0f5c3619d10ecea44363b5a599cadc5b2957e223fec62e81f7b48
	3d7334b9186bdbee87316b1</li>		25fc799a771a3d7334b9186bdbee87316b1
	<li>beta = 90871e06da5caa39a3c61578ebb844de8635e27ac0b13e829997d0d95		beta =
	dd98c19</li>		90871e06da5caa39a3c61578ebb844de8635e27ac0b13e829997d0d95dd98c19
	</ul>		]]></sourcecode>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>ECVRF-P256-SHA256-SSWU</name>		<name>ECVRF-P256-SHA256-SSWU</name>
	<t>The example secret keys and messages in Examples 13 and 14 are taken from Appendix A.2.5 of <xref target="RFC6979" format="default"/>.</t>		<t>The example secret keys and messages in Examples 13 and 14 are taken from <xref target="RFC6979" sectionFormat="of" section="A.2.5"/>.</t>
	<t>Example 13:</t>		<t>Example 13:</t>
	<ul empty="true" spacing="compact">		<sourcecode type="test-vectors"><![CDATA[SK = x =
	<li>SK = x = c9afa9d845ba75166b5c215767b1d6934e50c3db36e89b127b8a622		c9afa9d845ba75166b5c215767b1d6934e50c3db36e89b127b8a622b120f6721
	b120f6721</li>		PK =
	<li>PK = 0360fed4ba255a9d31c961eb74c6356d68c049b8923b61fa6ce669622e6		0360fed4ba255a9d31c961eb74c6356d68c049b8923b61fa6ce669622e60f29fb6
	0f29fb6</li>		alpha = 73616d706c65 (6 bytes; ASCII "sample")
	<li>alpha = 73616d706c65 (6 bytes; ASCII "sample")</li>		In SSWU: uniform_bytes = 5024e98d6067dec313af09ff0cbe78218324a645c
	<li>In SSWU: uniform_bytes = 5024e98d6067dec313af09ff0cbe78218324a64		2a4b0aae2453f6fe91aa3bd9471f7b4a5fbf128e4b53f0c59603f7e
	5c2a4b0aae2453f6fe91aa3bd9471f7b4a5fbf128e4b53f0c59603f7e</li>		In SSWU: u =
	<li>In SSWU: u = df565615a2372e8b31b8771f7503bafc144e48b05688b97958c		df565615a2372e8b31b8771f7503bafc144e48b05688b97958cc27ce29a8d810
	c27ce29a8d810</li>		In SSWU: x1 =
	<li>In SSWU: x1 = e7e39eb8a4c982426fcff629e55a3e13516cfeb62c02c369b1		e7e39eb8a4c982426fcff629e55a3e13516cfeb62c02c369b1e750316f5e94eb
	e750316f5e94eb</li>		In SSWU: gx1 is a nonsquare
	<li>In SSWU: gx1 is a nonsquare</li>		H =
	<li>H = 02b31973e872d4a097e2cfae9f37af9f9d73428fde74ac537dda93b5f18d		02b31973e872d4a097e2cfae9f37af9f9d73428fde74ac537dda93b5f18dbc5842
	bc5842</li>		k =
	<li>k = e92820035a0a8afe132826c6312662b6ea733fc1a0d33737945016de54d0		e92820035a0a8afe132826c6312662b6ea733fc1a0d33737945016de54d02dd8
	2dd8</li>		U = k*B =
	<li>U = k*B = 031490f49d0355ffcdf66e40df788bee93861917ee713acff79be4		031490f49d0355ffcdf66e40df788bee93861917ee713acff79be40d20cc91a30a
	0d20cc91a30a</li>		V = k*H =
	<li>V = k*H = 03701df0228138fa3d16612c0d720389326b3265151bc7ac696ea4		03701df0228138fa3d16612c0d720389326b3265151bc7ac696ea4d0591cd053e3
	d0591cd053e3</li>		pi = 0331d984ca8fece9cbb9a144c0d53df3c4c7a33080c1e02ddb1a96a365394
	<li>pi = 0331d984ca8fece9cbb9a144c0d53df3c4c7a33080c1e02ddb1a96a3653		c7888782fffde7b842c38c20c08de6ec6c2e7027a97000f2c9fa4425d5c03e639f
	94c7888782fffde7b842c38c20c08de6ec6c2e7027a97000f2c9fa4425d5c03e639fb48fde58114d		b48fde58114d755985498d7eb234cf4aed9
	755985498d7eb234cf4aed9</li>		beta =
	<li>beta = 21e66dc9747430f17ed9efeda054cf4a264b097b9e8956a1787526ed0		21e66dc9747430f17ed9efeda054cf4a264b097b9e8956a1787526ed00dc664b
	0dc664b</li>		]]></sourcecode>
	</ul>
	<t>Example 14:</t>		<t>Example 14:</t>
	<ul empty="true" spacing="compact">		<sourcecode type="test-vectors"><![CDATA[SK = x =
	<li>SK = x = c9afa9d845ba75166b5c215767b1d6934e50c3db36e89b127b8a622		c9afa9d845ba75166b5c215767b1d6934e50c3db36e89b127b8a622b120f6721
	b120f6721</li>		PK =
	<li>PK = 0360fed4ba255a9d31c961eb74c6356d68c049b8923b61fa6ce669622e6		0360fed4ba255a9d31c961eb74c6356d68c049b8923b61fa6ce669622e60f29fb6
	0f29fb6</li>		alpha = 74657374 (4 bytes; ASCII "test")
	<li>alpha = 74657374 (4 bytes; ASCII "test")</li>		In SSWU: uniform_bytes = 910cc66d84a57985a1d15843dad83fd9138a109af
	<li>In SSWU: uniform_bytes = 910cc66d84a57985a1d15843dad83fd9138a109		b243b7fa5d64d766ec9ca3894fdcf46ebeb21a3972eb452a4232fd3
	afb243b7fa5d64d766ec9ca3894fdcf46ebeb21a3972eb452a4232fd3</li>		In SSWU: u =
	<li>In SSWU: u = d8b0107f7e7aa36390240d834852f8703a6dc407019d6196bda		d8b0107f7e7aa36390240d834852f8703a6dc407019d6196bda5861b8fc00181
	5861b8fc00181</li>		In SSWU: x1 =
	<li>In SSWU: x1 = ccc747fa7318b9486ce4044adbbecaa084c27be6eda88eb7b7		ccc747fa7318b9486ce4044adbbecaa084c27be6eda88eb7b7f3d688fd0968c7
	f3d688fd0968c7</li>		In SSWU: gx1 is a square
	<li>In SSWU: gx1 is a square</li>		H =
	<li>H = 03ccc747fa7318b9486ce4044adbbecaa084c27be6eda88eb7b7f3d688fd		03ccc747fa7318b9486ce4044adbbecaa084c27be6eda88eb7b7f3d688fd0968c7
	0968c7</li>		k =
	<li>k = febc3451ea7639fde2cf41ffd03f463124ecb3b5a79913db1ed069147c8a		febc3451ea7639fde2cf41ffd03f463124ecb3b5a79913db1ed069147c8a7dea
	7dea</li>		U = k*B =
	<li>U = k*B = 031200f9900e96f811d1247d353573f47e0d9da601fc992566234f		031200f9900e96f811d1247d353573f47e0d9da601fc992566234fc1a5b37749ae
	c1a5b37749ae</li>		V = k*H =
	<li>V = k*H = 02d3715dcfee136c7ae50e95ffca76f4ca6c29ddfb92a39c31a0d4		02d3715dcfee136c7ae50e95ffca76f4ca6c29ddfb92a39c31a0d48e75c6605cd1
	8e75c6605cd1</li>		pi = 03f814c0455d32dbc75ad3aea08c7e2db31748e12802db23640203aebf1fa
	<li>pi = 03f814c0455d32dbc75ad3aea08c7e2db31748e12802db23640203aebf1		8db2743aad348a3006dc1caad7da28687320740bf7dd78fe13c298867321ce3b36
	fa8db2743aad348a3006dc1caad7da28687320740bf7dd78fe13c298867321ce3b36b79ec3093b70		b79ec3093b7083ac5e4daf3465f9f43c627
	83ac5e4daf3465f9f43c627</li>		beta =
	<li>beta = 8e7185d2b420e4f4681f44ce313a26d05613323837da09a69f00491a8		8e7185d2b420e4f4681f44ce313a26d05613323837da09a69f00491a83ad25dd
	3ad25dd</li>		]]></sourcecode>
	</ul>
	<t>The example secret key in Example 15 is taken from Appendix L.4.2 of <xref target="ANSI.X9-62-2005" format="default"/>.</t>		<t>The example secret key in Example 15 is taken from Appendix L.4.2 of <xref target="ANSI.X9-62-2005" format="default"/>.</t>
	<t>Example 15:</t>		<t>Example 15:</t>
	<ul empty="true" spacing="compact">		<sourcecode type="test-vectors"><![CDATA[SK = x =
	<li>SK = x = 2ca1411a41b17b24cc8c3b089cfd033f1920202a6c0de8abb97df14		2ca1411a41b17b24cc8c3b089cfd033f1920202a6c0de8abb97df1498d50d2c8
	98d50d2c8</li>		PK =
	<li>PK = 03596375e6ce57e0f20294fc46bdfcfd19a39f8161b58695b3ec5b3d164		03596375e6ce57e0f20294fc46bdfcfd19a39f8161b58695b3ec5b3d16427c274d
	27c274d</li>		alpha = 4578616d706c65207573696e67204543445341206b65792066726f6d20
	<li>alpha = 4578616d706c65207573696e67204543445341206b65792066726f6d		417070656e646978204c2e342e32206f6620414e53492e58392d36322d32303035
	20417070656e646978204c2e342e32206f6620414e53492e58392d36322d32303035 (62 bytes;		(62 bytes; ASCII "Example using ECDSA key from Appendix L.4.2 of
	ASCII "Example using ECDSA key from Appendix L.4.2 of ANSI.X9-62-2005")</li>		ANSI.X9-62-2005")
	<li>In SSWU: uniform_bytes = 9b81d55a242d3e8438d3bcfb1bee985a87fd144		In SSWU: uniform_bytes = 9b81d55a242d3e8438d3bcfb1bee985a87fd14480
	802c9268cf9adeee160e6e9ff765569797a0f701cb4316018de2e7dd4</li>		2c9268cf9adeee160e6e9ff765569797a0f701cb4316018de2e7dd4
	<li>In SSWU: u = e43c98c2ae06d13839fedb0303e5ee815896beda39be83fb113		In SSWU: u =
	25b97976efdce</li>		e43c98c2ae06d13839fedb0303e5ee815896beda39be83fb11325b97976efdce
	<li>In SSWU: x1 = be9e195a50f175d3563aed8dc2d9f513a5536c1e9aee1757d8		In SSWU: x1 =
	6c08d32d582a86</li>		be9e195a50f175d3563aed8dc2d9f513a5536c1e9aee1757d86c08d32d582a86
	<li>In SSWU: gx1 is a nonsquare</li>		In SSWU: gx1 is a nonsquare
	<li>H = 022dd5150e5a2a24c66feab2f68532be1486e28e07f1b9a055cf38ccc16f		H =
	6595ff</li>		022dd5150e5a2a24c66feab2f68532be1486e28e07f1b9a055cf38ccc16f6595ff
	<li>k = 8e29221f33564f3f66f858ba2b0c14766e1057adbd422c3e7d0d99d5e142		k =
	b613</li>		8e29221f33564f3f66f858ba2b0c14766e1057adbd422c3e7d0d99d5e142b613
	<li>U = k*B = 03a8823ff9fd16bf879261c740b9c7792b77fee0830f21314117e4		U = k*B =
	41784667958d</li>		03a8823ff9fd16bf879261c740b9c7792b77fee0830f21314117e441784667958d
	<li>V = k*H = 02d48fbb45921c755b73b25be2f23379e3ce69294f6cee9279815f		V = k*H =
	57f4b422659d</li>		02d48fbb45921c755b73b25be2f23379e3ce69294f6cee9279815f57f4b422659d
	<li>pi = 039f8d9cdc162c89be2871cbcb1435144739431db7fab437ab7bc4e2651		pi = 039f8d9cdc162c89be2871cbcb1435144739431db7fab437ab7bc4e2651a9
	a9e99d5488405a11a6c7fc8defddd9e1573a563b7333aab4effe73ae9803274174c659269fd39b53		e99d5488405a11a6c7fc8defddd9e1573a563b7333aab4effe73ae9803274174c6
	e133dcd9e0d24f01288de9a</li>		59269fd39b53e133dcd9e0d24f01288de9a
	<li>beta = 4fbadf33b42a5f42f23a6f89952d2e634a6e3810f15878b46ef1bb85a		beta =
	04fe95a</li>		4fbadf33b42a5f42f23a6f89952d2e634a6e3810f15878b46ef1bb85a04fe95a
	</ul>		]]></sourcecode>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>ECVRF-EDWARDS25519-SHA512-TAI</name>		<name>ECVRF-EDWARDS25519-SHA512-TAI</name>
	<t>The example secret keys and messages in Examples 16, 17, and 18 are t aken from Section 7.1 of <xref target="RFC8032" format="default"/>.</t>		<t>The example secret keys and messages in Examples 16, 17, and 18 are t aken from <xref target="RFC8032" sectionFormat="of" section="7.1"/>.</t>
	<t>Example 16:</t>		<t>Example 16:</t>
	<ul empty="true" spacing="compact">		<sourcecode type="test-vectors"><![CDATA[SK =
	<li>SK = 9d61b19deffd5a60ba844af492ec2cc44449c5697b326919703bac031ca		9d61b19deffd5a60ba844af492ec2cc44449c5697b326919703bac031cae7f60
	e7f60</li>		PK =
	<li>PK = d75a980182b10ab7d54bfed3c964073a0ee172f3daa62325af021a68f70		d75a980182b10ab7d54bfed3c964073a0ee172f3daa62325af021a68f707511a
	7511a</li>		alpha = (the empty string)
	<li>alpha = (the empty string)</li>		x =
	<li>x = 307c83864f2833cb427a2ef1c00a013cfdff2768d980c0a3a520f006904d		307c83864f2833cb427a2ef1c00a013cfdff2768d980c0a3a520f006904de94f
	e94f</li>		try_and_increment succeeded on ctr = 0
	<li>try_and_increment succeeded on ctr = 0</li>		H =
	<li>H = 91bbed02a99461df1ad4c6564a5f5d829d0b90cfc7903e7a5797bd658abf		91bbed02a99461df1ad4c6564a5f5d829d0b90cfc7903e7a5797bd658abf3318
	3318</li>		k_string = 7100f3d9eadb6dc4743b029736ff283f5be494128df128df2817106
	<li>k_string = 7100f3d9eadb6dc4743b029736ff283f5be494128df128df28171		f345b8594b6d6da2d6fb0b4c0257eb337675d96eab49cf39e66cc2c9547c2bf8b2
	06f345b8594b6d6da2d6fb0b4c0257eb337675d96eab49cf39e66cc2c9547c2bf8b2a6afae4</li>		a6afae4
	<li>k = 8a49edbd1492a8ee09766befe50a7d563051bf3406cbffc20a88def03073		k =
	0f0f</li>		8a49edbd1492a8ee09766befe50a7d563051bf3406cbffc20a88def030730f0f
	<li>U = k*B = aef27c725be964c6a9bf4c45ca8e35df258c1878b838f37d997552		U = k*B =
	3f09034071</li>		aef27c725be964c6a9bf4c45ca8e35df258c1878b838f37d9975523f09034071
	<li>V = k*H = 5016572f71466c646c119443455d6cb9b952f07d060ec8286d6786		V = k*H =
	15d55f954f</li>		5016572f71466c646c119443455d6cb9b952f07d060ec8286d678615d55f954f
	<li>pi = 8657106690b5526245a92b003bb079ccd1a92130477671f6fc01ad16f26		pi = 8657106690b5526245a92b003bb079ccd1a92130477671f6fc01ad16f26f7
	f723f26f8a57ccaed74ee1b190bed1f479d9727d2d0f9b005a6e456a35d4fb0daab1268a1b0db108		23f26f8a57ccaed74ee1b190bed1f479d9727d2d0f9b005a6e456a35d4fb0daab1
	36d9826a528ca76567805</li>		268a1b0db10836d9826a528ca76567805
	<li>beta = 90cf1df3b703cce59e2a35b925d411164068269d7b2d29f3301c03dd7		beta = 90cf1df3b703cce59e2a35b925d411164068269d7b2d29f3301c03dd757
	57876ff66b71dda49d2de59d03450451af026798e8f81cd2e333de5cdf4f3e140fdd8ae</li>		876ff66b71dda49d2de59d03450451af026798e8f81cd2e333de5cdf4f3e140fdd
	</ul>		8ae
			]]></sourcecode>
	<t>Example 17:</t>		<t>Example 17:</t>
	<ul empty="true" spacing="compact">		<sourcecode type="test-vectors"><![CDATA[SK =
	<li>SK = 4ccd089b28ff96da9db6c346ec114e0f5b8a319f35aba624da8cf6ed4fb		4ccd089b28ff96da9db6c346ec114e0f5b8a319f35aba624da8cf6ed4fb8a6fb
	8a6fb</li>		PK =
	<li>PK = 3d4017c3e843895a92b70aa74d1b7ebc9c982ccf2ec4968cc0cd55f12af		3d4017c3e843895a92b70aa74d1b7ebc9c982ccf2ec4968cc0cd55f12af4660c
	4660c</li>		alpha = 72 (1 byte)
	<li>alpha = 72 (1 byte)</li>		x =
	<li>x = 68bd9ed75882d52815a97585caf4790a7f6c6b3b7f821c5e259a24b02e50		68bd9ed75882d52815a97585caf4790a7f6c6b3b7f821c5e259a24b02e502e51
	2e51</li>		try_and_increment succeeded on ctr = 1
	<li>try_and_increment succeeded on ctr = 1</li>		H =
	<li>H = 5b659fc3d4e9263fd9a4ed1d022d75eaacc20df5e09f9ea937502396598d		5b659fc3d4e9263fd9a4ed1d022d75eaacc20df5e09f9ea937502396598dc551
	c551</li>		k_string = 42589bbf0c485c3c91c1621bb4bfe04aed7be76ee48f9b00793b234
	<li>k_string = 42589bbf0c485c3c91c1621bb4bfe04aed7be76ee48f9b00793b2		2acb9c167cab856f9f9d4febc311330c20b0a8afd3743d05433e8be8d32522ecdc
	342acb9c167cab856f9f9d4febc311330c20b0a8afd3743d05433e8be8d32522ecdc16cc5ce</li>		16cc5ce
	<li>k = d8c3a66921444cb3427d5d989f9b315aa8ca3375e9ec4d52207711a1fdb4		k =
	4107</li>		d8c3a66921444cb3427d5d989f9b315aa8ca3375e9ec4d52207711a1fdb44107
	<li>U = k*B = 1dcb0a4821a2c48bf53548228b7f170962988f6d12f5439f31987e		U = k*B =
	f41f034ab3</li>		1dcb0a4821a2c48bf53548228b7f170962988f6d12f5439f31987ef41f034ab3
	<li>V = k*H = fd03c0bf498c752161bae4719105a074630a2aa5f200ff7b3995f7		V = k*H =
	bfb1513423</li>		fd03c0bf498c752161bae4719105a074630a2aa5f200ff7b3995f7bfb1513423
	<li>pi = f3141cd382dc42909d19ec5110469e4feae18300e94f304590abdced48a		pi = f3141cd382dc42909d19ec5110469e4feae18300e94f304590abdced48aed
	ed5933bf0864a62558b3ed7f2fea45c92a465301b3bbf5e3e54ddf2d935be3b67926da3ef39226bb		5933bf0864a62558b3ed7f2fea45c92a465301b3bbf5e3e54ddf2d935be3b67926
	c355bdc9850112c8f4b02</li>		da3ef39226bbc355bdc9850112c8f4b02
	<li>beta = eb4440665d3891d668e7e0fcaf587f1b4bd7fbfe99d0eb2211ccec904		beta = eb4440665d3891d668e7e0fcaf587f1b4bd7fbfe99d0eb2211ccec90496
	96310eb5e33821bc613efb94db5e5b54c70a848a0bef4553a41befc57663b56373a5031</li>		310eb5e33821bc613efb94db5e5b54c70a848a0bef4553a41befc57663b56373a5
	</ul>		031
			]]></sourcecode>
	<t>Example 18:</t>		<t>Example 18:</t>
	<ul empty="true" spacing="compact">		<sourcecode type="test-vectors"><![CDATA[SK =
	<li>SK = c5aa8df43f9f837bedb7442f31dcb7b166d38535076f094b85ce3a2e0b4		c5aa8df43f9f837bedb7442f31dcb7b166d38535076f094b85ce3a2e0b4458f7
	458f7</li>		PK =
	<li>PK = fc51cd8e6218a1a38da47ed00230f0580816ed13ba3303ac5deb9115489		fc51cd8e6218a1a38da47ed00230f0580816ed13ba3303ac5deb911548908025
	08025</li>		alpha = af82 (2 bytes)
	<li>alpha = af82 (2 bytes)</li>		x =
	<li>x = 909a8b755ed902849023a55b15c23d11ba4d7f4ec5c2f51b1325a181991e		909a8b755ed902849023a55b15c23d11ba4d7f4ec5c2f51b1325a181991ea95c
	a95c</li>		try_and_increment succeeded on ctr = 0
	<li>try_and_increment succeeded on ctr = 0</li>		H =
	<li>H = bf4339376f5542811de615e3313d2b36f6f53c0acfebb482159711201192		bf4339376f5542811de615e3313d2b36f6f53c0acfebb482159711201192576a
	576a</li>		k_string = 38b868c335ccda94a088428cbf3ec8bc7955bfaffe1f3bd2aa2c59f
	<li>k_string = 38b868c335ccda94a088428cbf3ec8bc7955bfaffe1f3bd2aa2c5		c31a0febc59d0e1af3715773ce11b3bbdd7aba8e3505d4b9de6f7e4a96e67e0d6b
	9fc31a0febc59d0e1af3715773ce11b3bbdd7aba8e3505d4b9de6f7e4a96e67e0d6bb6d6c3a</li>		b6d6c3a
	<li>k = 5ffdbc72135d936014e8ab708585fda379405542b07e3bd2c0bd48437fba		k =
	c60a</li>		5ffdbc72135d936014e8ab708585fda379405542b07e3bd2c0bd48437fbac60a
	<li>U = k*B = 2bae73e15a64042fcebf062abe7e432b2eca6744f3e8265bc38e00		U = k*B =
	9cd577ecd5</li>		2bae73e15a64042fcebf062abe7e432b2eca6744f3e8265bc38e009cd577ecd5
	<li>V = k*H = 88cba1cb0d4f9b649d9a86026b69de076724a93a65c349c988954f		V = k*H =
	0961c5d506</li>		88cba1cb0d4f9b649d9a86026b69de076724a93a65c349c988954f0961c5d506
	<li>pi = 9bc0f79119cc5604bf02d23b4caede71393cedfbb191434dd016d30177c		pi = 9bc0f79119cc5604bf02d23b4caede71393cedfbb191434dd016d30177ccb
	cbf8096bb474e53895c362d8628ee9f9ea3c0e52c7a5c691b6c18c9979866568add7a2d41b00b050		f8096bb474e53895c362d8628ee9f9ea3c0e52c7a5c691b6c18c9979866568add7
	81ed0f58ee5e31b3a970e</li>		a2d41b00b05081ed0f58ee5e31b3a970e
	<li>beta = 645427e5d00c62a23fb703732fa5d892940935942101e456ecca7bb21		beta = 645427e5d00c62a23fb703732fa5d892940935942101e456ecca7bb217c
	7c61c452118fec1219202a0edcf038bb6373241578be7217ba85a2687f7a0310b2df19f</li>		61c452118fec1219202a0edcf038bb6373241578be7217ba85a2687f7a0310b2df
	</ul>		19f
			]]></sourcecode>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>ECVRF-EDWARDS25519-SHA512-ELL2</name>		<name>ECVRF-EDWARDS25519-SHA512-ELL2</name>
	<t>The example secret keys and messages in Examples 19, 20, and 21 are t aken from Section 7.1 of <xref target="RFC8032" format="default"/>.</t>		<t>The example secret keys and messages in Examples 19, 20, and 21 are t aken from <xref target="RFC8032" sectionFormat="of" section="7.1"/>.</t>
	<t>Example 19:</t>		<t>Example 19:</t>
	<ul empty="true" spacing="compact">		<sourcecode type="test-vectors"><![CDATA[SK =
	<li>SK = 9d61b19deffd5a60ba844af492ec2cc44449c5697b326919703bac031ca		9d61b19deffd5a60ba844af492ec2cc44449c5697b326919703bac031cae7f60
	e7f60</li>		PK =
	<li>PK = d75a980182b10ab7d54bfed3c964073a0ee172f3daa62325af021a68f70		d75a980182b10ab7d54bfed3c964073a0ee172f3daa62325af021a68f707511a
	7511a</li>		alpha = (the empty string)
	<li>alpha = (the empty string)</li>		x =
	<li>x = 307c83864f2833cb427a2ef1c00a013cfdff2768d980c0a3a520f006904d		307c83864f2833cb427a2ef1c00a013cfdff2768d980c0a3a520f006904de94f
	e94f</li>		In Elligator2: uniform_bytes = d620782a206d9de584b74e23ae5ee1db5ca
	<li>In Elligator2: uniform_bytes = d620782a206d9de584b74e23ae5ee1db5		5298b3fc527c4867f049dee6dd419b3674967bd614890f621c128d72269ae
	ca5298b3fc527c4867f049dee6dd419b3674967bd614890f621c128d72269ae</li>		In Elligator2: u =
	<li>In Elligator2: u = 30f037b9745a57a9a2b8a68da81f397c39d46dee9d047		30f037b9745a57a9a2b8a68da81f397c39d46dee9d047f86c427c53f8b29a55c
	f86c427c53f8b29a55c</li>		In Elligator2: gx1 =
	<li>In Elligator2: gx1 = 8cb66318fb2cea01672d6c27a5ab662ae3322096160		8cb66318fb2cea01672d6c27a5ab662ae33220961607f69276080a56477b4a08
	7f69276080a56477b4a08</li>		In Elligator2: gx1 is a square
	<li>In Elligator2: gx1 is a square</li>		H =
	<li>H = b8066ebbb706c72b64390324e4a3276f129569eab100c26b9f05011200c1		b8066ebbb706c72b64390324e4a3276f129569eab100c26b9f05011200c1bad9
	bad9</li>		k_string = b5682049fee54fe2d519c9afff73bbfad724e69a82d5051496a4245
	<li>k_string = b5682049fee54fe2d519c9afff73bbfad724e69a82d5051496a42		8f817bed7a386f96b1a78e5736756192aeb1818a20efb336a205ffede351cfe88d
	458f817bed7a386f96b1a78e5736756192aeb1818a20efb336a205ffede351cfe88dab8d41c</li>		ab8d41c
	<li>k = 55cbb247af9b8372259a97b2cfec656d78868deb33b203d51b9961c36452		k =
	2400</li>		55cbb247af9b8372259a97b2cfec656d78868deb33b203d51b9961c364522400
	<li>U = k*B = 762f5c178b68f0cddcc1157918edf45ec334ac8e8286601a3256c3		U = k*B =
	bbf858edd9</li>		762f5c178b68f0cddcc1157918edf45ec334ac8e8286601a3256c3bbf858edd9
	<li>V = k*H = 4652eba1c4612e6fce762977a59420b451e12964adbe4fbecd58a7		V = k*H =
	aeff5860af</li>		4652eba1c4612e6fce762977a59420b451e12964adbe4fbecd58a7aeff5860af
	<li>pi = 7d9c633ffeee27349264cf5c667579fc583b4bda63ab71d001f89c10003		pi = 7d9c633ffeee27349264cf5c667579fc583b4bda63ab71d001f89c10003ab
	ab46f14adf9a3cd8b8412d9038531e865c341cafa73589b023d14311c331a9ad15ff2fb37831e00f		46f14adf9a3cd8b8412d9038531e865c341cafa73589b023d14311c331a9ad15ff
	0acaa6d73bc9997b06501</li>		2fb37831e00f0acaa6d73bc9997b06501
	<li>beta = 9d574bf9b8302ec0fc1e21c3ec5368269527b87b462ce36dab2d14ccf		beta = 9d574bf9b8302ec0fc1e21c3ec5368269527b87b462ce36dab2d14ccf80
	80c53cccf6758f058c5b1c856b116388152bbe509ee3b9ecfe63d93c3b4346c1fbc6c54</li>		c53cccf6758f058c5b1c856b116388152bbe509ee3b9ecfe63d93c3b4346c1fbc6
	</ul>		c54
			]]></sourcecode>
	<t>Example 20:</t>		<t>Example 20:</t>
	<ul empty="true" spacing="compact">		<sourcecode type="test-vectors"><![CDATA[SK =
	<li>SK = 4ccd089b28ff96da9db6c346ec114e0f5b8a319f35aba624da8cf6ed4fb		4ccd089b28ff96da9db6c346ec114e0f5b8a319f35aba624da8cf6ed4fb8a6fb
	8a6fb</li>		PK =
	<li>PK = 3d4017c3e843895a92b70aa74d1b7ebc9c982ccf2ec4968cc0cd55f12af		3d4017c3e843895a92b70aa74d1b7ebc9c982ccf2ec4968cc0cd55f12af4660c
	4660c</li>		alpha = 72 (1 byte)
	<li>alpha = 72 (1 byte)</li>		x =
	<li>x = 68bd9ed75882d52815a97585caf4790a7f6c6b3b7f821c5e259a24b02e50		68bd9ed75882d52815a97585caf4790a7f6c6b3b7f821c5e259a24b02e502e51
	2e51</li>		In Elligator2: uniform_bytes = 04ae20a9ad2a2330fb33318e376a2448bd7
	<li>In Elligator2: uniform_bytes = 04ae20a9ad2a2330fb33318e376a2448b		7bb99e81d126f47952b156590444a9225b84128b66a2f15b41294fa2f2f6d
	d77bb99e81d126f47952b156590444a9225b84128b66a2f15b41294fa2f2f6d</li>		In Elligator2: u =
	<li>In Elligator2: u = 3092f033b16d4d5f74a3f7dc7091fe434b449065152b9		3092f033b16d4d5f74a3f7dc7091fe434b449065152b95476f121de899bb773d
	5476f121de899bb773d</li>		In Elligator2: gx1 =
	<li>In Elligator2: gx1 = 25d7fe7f82456e7078e99fdb24ef2582b4608357cdb		25d7fe7f82456e7078e99fdb24ef2582b4608357cdba9c39a8d535a3fd98464d
	a9c39a8d535a3fd98464d</li>		In Elligator2: gx1 is a nonsquare
	<li>In Elligator2: gx1 is a nonsquare</li>		H =
	<li>H = 76ac3ccb86158a9104dff819b1ca293426d305fd76b39b13c9356d9b58c0		76ac3ccb86158a9104dff819b1ca293426d305fd76b39b13c9356d9b58c08e57
	8e57</li>		k_string = 88bf479281fd29a6cbdffd67e2c5ec0024d92f14eaed58f43f22f37
	<li>k_string = 88bf479281fd29a6cbdffd67e2c5ec0024d92f14eaed58f43f22f		c4c37f1d41e65c036fbf01f9fba11d554c07494d0c02e7e5c9d64be88ef78cab75
	37c4c37f1d41e65c036fbf01f9fba11d554c07494d0c02e7e5c9d64be88ef78cab7544e444d</li>		44e444d
	<li>k = 9565956daeedf376cad61b829b2a4d21ba1b52e9b3e2457477a64630a971		k =
	1003</li>		9565956daeedf376cad61b829b2a4d21ba1b52e9b3e2457477a64630a9711003
	<li>U = k*B = 8ec26e77b8cb3114dd2265fe1564a4efb40d109aa3312536d93dfe		U = k*B =
	3d8d80a061</li>		8ec26e77b8cb3114dd2265fe1564a4efb40d109aa3312536d93dfe3d8d80a061
	<li>V = k*H = fe799eb5770b4e3a5a27d22518bb631db183c8316bb552155f442c		V = k*H =
	62a47d1c8b</li>		fe799eb5770b4e3a5a27d22518bb631db183c8316bb552155f442c62a47d1c8b
	<li>pi = 47b327393ff2dd81336f8a2ef10339112401253b3c714eeda879f12c509		pi = 47b327393ff2dd81336f8a2ef10339112401253b3c714eeda879f12c50907
	072ef055b48372bb82efbdce8e10c8cb9a2f9d60e93908f93df1623ad78a86a028d6bc064dbfc75a		2ef055b48372bb82efbdce8e10c8cb9a2f9d60e93908f93df1623ad78a86a028d6
	6a57379ef855dc6733801</li>		bc064dbfc75a6a57379ef855dc6733801
	<li>beta = 38561d6b77b71d30eb97a062168ae12b667ce5c28caccdf76bc88e093		beta = 38561d6b77b71d30eb97a062168ae12b667ce5c28caccdf76bc88e093e4
	e4635987cd96814ce55b4689b3dd2947f80e59aac7b7675f8083865b46c89b2ce9cc735</li>		635987cd96814ce55b4689b3dd2947f80e59aac7b7675f8083865b46c89b2ce9cc
	</ul>		735
			]]></sourcecode>
	<t>Example 21:</t>		<t>Example 21:</t>
	<ul empty="true" spacing="compact">		<sourcecode type="test-vectors"><![CDATA[SK =
	<li>SK = c5aa8df43f9f837bedb7442f31dcb7b166d38535076f094b85ce3a2e0b4		c5aa8df43f9f837bedb7442f31dcb7b166d38535076f094b85ce3a2e0b4458f7
	458f7</li>		PK =
	<li>PK = fc51cd8e6218a1a38da47ed00230f0580816ed13ba3303ac5deb9115489		fc51cd8e6218a1a38da47ed00230f0580816ed13ba3303ac5deb911548908025
	08025</li>		alpha = af82 (2 bytes)
	<li>alpha = af82 (2 bytes)</li>		x =
	<li>x = 909a8b755ed902849023a55b15c23d11ba4d7f4ec5c2f51b1325a181991e		909a8b755ed902849023a55b15c23d11ba4d7f4ec5c2f51b1325a181991ea95c
	a95c</li>		In Elligator2: uniform_bytes = be0aed556e36cdfddf8f1eeddbb7356a24f
	<li>In Elligator2: uniform_bytes = be0aed556e36cdfddf8f1eeddbb7356a2		ad64cf95a922a098038f215588b216beabbfe6acf20256188e883292b7a3a
	4fad64cf95a922a098038f215588b216beabbfe6acf20256188e883292b7a3a</li>		In Elligator2: u =
	<li>In Elligator2: u = f6675dc6d17fc790d4b3f1c6acf689a13d8b5815f2388		f6675dc6d17fc790d4b3f1c6acf689a13d8b5815f23880092a925af94cd6fa24
	0092a925af94cd6fa24</li>		In Elligator2: gx1 =
	<li>In Elligator2: gx1 = a63d48e3247c903e22fdfb88fd9295e396712a5fe57		a63d48e3247c903e22fdfb88fd9295e396712a5fe576af335dbe16f99f0af26c
	6af335dbe16f99f0af26c</li>		In Elligator2: gx1 is a square
	<li>In Elligator2: gx1 is a square</li>		H = 13d2a8b5ca32db7e98094a61f656a08c6c964344e058879a386a947a4e189ed1
	<li>H = 13d2a8b5ca32db7e98094a61f656a08c6c964344e058879a386a947a4e18		k_string = a7ddd74a3a7d165d511b02fa268710ddbb3b939282d276fa2efcfa5
	9ed1</li>		aaf79cf576087299ca9234aacd7cd674d912deba00f4e291733ef189a51e36c861
	<li>k_string = a7ddd74a3a7d165d511b02fa268710ddbb3b939282d276fa2efcf		b3d683b
	a5aaf79cf576087299ca9234aacd7cd674d912deba00f4e291733ef189a51e36c861b3d683b</li>		k =
	<li>k = 1fda4077f737098b3f361c33a36cccafd7e9e9b720e1f84011254e25f37e		1fda4077f737098b3f361c33a36cccafd7e9e9b720e1f84011254e25f37eed02
	ed02</li>		U = k*B =
	<li>U = k*B = a012f35433df219a88ab0f9481f4e0065d00422c3285f3d34a8b02		a012f35433df219a88ab0f9481f4e0065d00422c3285f3d34a8b0202f20bac60
	02f20bac60</li>		V = k*H =
	<li>V = k*H = fb613986d171b3e98319c7ca4dc44c5dd8314a6e5616c1a4f16ce7		fb613986d171b3e98319c7ca4dc44c5dd8314a6e5616c1a4f16ce72bd7a0c25a
	2bd7a0c25a</li>		pi = 926e895d308f5e328e7aa159c06eddbe56d06846abf5d98c2512235eaa57f
	<li>pi = 926e895d308f5e328e7aa159c06eddbe56d06846abf5d98c2512235eaa5		dce35b46edfc655bc828d44ad09d1150f31374e7ef73027e14760d42e77341fe05
	7fdce35b46edfc655bc828d44ad09d1150f31374e7ef73027e14760d42e77341fe05467bb286cc2c		467bb286cc2c9d7fde29120a0b2320d04
	9d7fde29120a0b2320d04</li>		beta = 121b7f9b9aaaa29099fc04a94ba52784d44eac976dd1a3cca458733be5c
	<li>beta = 121b7f9b9aaaa29099fc04a94ba52784d44eac976dd1a3cca458733be		d090a7b5fbd148444f17f8daf1fb55cb04b1ae85a626e30a54b4b0f8abf4a43314
	5cd090a7b5fbd148444f17f8daf1fb55cb04b1ae85a626e30a54b4b0f8abf4a43314a58</li>		a58
	</ul>		]]></sourcecode>
	</section>		</section>
	</section>		</section>
	<!--		<section numbered="false" toc="default">
	<section title="Open Issues">		<name>Contributors</name>
	<t>		<t>
	Note to RFC Editor: please remove this appendix before publication a		This document would not be possible without the work of <contact
	s an RFC.		fullname="Moni Naor"/>, <contact fullname="Sachin Vasant"/>, and
	</t>		<contact fullname="Asaf Ziv"/>. &nbsp;<contact fullname="Chloe
			Martindale"/> provided a thorough cryptographer's review.
	<t>		<contact fullname="Liliya Akhmetzyanova"/>, <contact
	<list style="numbers">		fullname="Tony Arcieri"/>, <contact fullname="Gary Belvin"/>,
	<t>Open issue.</t>		<contact fullname= "Mario Cao Cueto"/>, <contact fullname="Brian
	</list>		Chen"/>, <contact fullname="Sergey Gorbunov"/>, <contact
	</t>		fullname="Shumon Huque"/>, <contact fullname="Gorka Irazoqui
			Apecechea"/>, <contact fullname="Marek Jankowski"/>, <contact
			fullname="Burt Kaliski"/>, <contact fullname="Mallory Knodel"/>,
			<contact fullname="David C.&nbsp;Lawrence"/>, <contact fullname="Der
			ek
			Ting-Haye Leung"/>, <contact fullname="Antonio Marcedone"/>,
			<contact fullname="Piotr Nojszewski"/>, <contact fullname="Chris
			Peikert"/>, <contact fullname="Colin Perkins"/>, <contact
			fullname="Trevor Perrin"/>, <contact fullname="Sam Scott"/>,
			<contact fullname="Stanislav Smyshlyaev"/>, <contact
			fullname="Adam Suhl"/>, <contact fullname="Nick Sullivan"/>,
			<contact fullname="Christopher Wood"/>, <contact fullname="Jiayu
			Xu"/>, and <contact fullname="Annie Yousar"/> provided valuable
			input to this document. <contact fullname="Christopher Wood"/>,
			<contact fullname="Malte Thomsen"/>, <contact fullname="Marcus
			Rasmussen"/>, and <contact fullname="Tobias Vestergaard"/>
			provided independent verification of the test vectors. <contact full
			name="Riad Wahby"/>
			helped this document align with <xref target="RFC9380"/>.
			</t>
	</section>		</section>
	-->
	</back>		</back>
	</rfc>		</rfc>
End of changes. 280 change blocks.
	1813 lines changed or deleted		1655 lines changed or added
This html diff was produced by rfcdiff 1.48.