rfc9381v3.txt		rfc9381.txt
	Internet Research Task Force (IRTF) S. Goldberg		Internet Research Task Force (IRTF) S. Goldberg
	Request for Comments: 9381 Boston University		Request for Comments: 9381 Boston University
	Category: Informational L. Reyzin		Category: Informational L. Reyzin
	ISSN: 2070-1721 Boston University and Algorand		ISSN: 2070-1721 Boston University and Algorand
	D. Papadopoulos		D. Papadopoulos
	Hong Kong University of Science and Technology		Hong Kong University of Science and Technology
	J. Včelák		J. Včelák
	NS1		NS1
	May 2023		August 2023
	Verifiable Random Functions (VRFs)		Verifiable Random Functions (VRFs)
	Abstract		Abstract
	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 can		keyed cryptographic hash. Only the holder of the secret key can
	compute the hash, but anyone with the public key can verify the		compute the hash, but anyone with the public key can verify the
	correctness of the hash. VRFs are useful for preventing enumeration		correctness of the hash. VRFs are useful for preventing enumeration
	of hash-based data structures. This document specifies VRF		of hash-based data structures. This document specifies VRF
	skipping to change at line 188 ¶		skipping to change at line 188 ¶
	Adversary: Potential attacker; often used to define a security		Adversary: Potential attacker; often used to define a security
	property.		property.
	Malicious (or adversarial): Performed by an adversary.		Malicious (or adversarial): Performed by an adversary.
	2. VRF Algorithms		2. VRF Algorithms
	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.
	The prover hashes an input alpha using the VRF secret key SK to		The Prover hashes an input alpha using the VRF secret key SK to
	obtain a VRF hash output beta:		obtain a VRF hash output beta:
	beta = VRF_hash(SK, alpha)		beta = VRF_hash(SK, alpha)
	The VRF_hash algorithm is deterministic, in the sense that it always		The VRF_hash algorithm is deterministic, in the sense that it always
	produces the same output beta, given the same pair of inputs (SK,		produces the same output beta, given the same pair of inputs (SK,
	alpha).		alpha).
	The prover also uses the secret key SK to construct a proof pi that		The Prover also uses the secret key SK to construct a proof pi that
	beta is the correct hash output:		beta is the correct hash output:
	pi = VRF_prove(SK, alpha)		pi = VRF_prove(SK, alpha)
	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		obtain the VRF hash output beta directly from the proof value pi by
	using the function VRF_proof_to_hash:		using the function VRF_proof_to_hash:
	beta = VRF_proof_to_hash(pi)		beta = VRF_proof_to_hash(pi)
	skipping to change at line 1186 ¶		skipping to change at line 1186 ¶
	their y-coordinates would exceed 2^255, and the algorithm ensures		their y-coordinates would exceed 2^255, and the algorithm ensures
	that y_string corresponds to an integer less than 2^255 in Step 3.)		that y_string corresponds to an integer less than 2^255 in Step 3.)
	5.5. ECVRF Ciphersuites		5.5. ECVRF Ciphersuites
	This document defines ECVRF-P256-SHA256-TAI as follows:		This document defines ECVRF-P256-SHA256-TAI as follows:
	* suite_string = 0x01.		* suite_string = 0x01.
	* The EC group G is the NIST P-256 elliptic curve, with the finite		* The EC group G is the NIST P-256 elliptic curve, with the finite
	field and curve parameters as specified in Section 3.1.2.3 of		field and curve parameters as specified in Section 3.2.1.3 of
	[SP-800-186] and Section 2.6 of [RFC5114]. For this group, fLen =		[SP-800-186] and Section 2.6 of [RFC5114]. For this group, fLen =
	qLen = 32 and cofactor = 1.		qLen = 32 and cofactor = 1.
	* cLen = 16.		* cLen = 16.
	* The key pair generation primitive is specified in Section 3.2.1 of		* The key pair generation primitive is specified in Section 3.2.1 of
	[SECG1] (q, B, SK, and Y in this document correspond to n, G, d,		[SECG1] (q, B, SK, and Y in this document correspond to n, G, d,
	and Q in Section 3.2.1 of [SECG1]). In this ciphersuite, the		and Q in Section 3.2.1 of [SECG1]). In this ciphersuite, the
	secret scalar x is equal to the secret key SK.		secret scalar x is equal to the secret key SK.
	skipping to change at line 1328 ¶		skipping to change at line 1328 ¶
	are chosen without complying with [RFC8017]); thus, the RSA-FDH-VRF		are chosen without complying with [RFC8017]); thus, the RSA-FDH-VRF
	as defined in this document does not have "full uniqueness" and "full		as defined in this document does not have "full uniqueness" and "full
	collision resistance". Therefore, if malicious key generation is a		collision resistance". Therefore, if malicious key generation is a
	concern, the RSA-FDH-VRF has to be enhanced by additional		concern, the RSA-FDH-VRF has to be enhanced by additional
	cryptographic checks (such as zero-knowledge proofs) to ensure that		cryptographic checks (such as zero-knowledge proofs) to ensure that
	its public key has the right form. These enhancements are left for		its public key has the right form. These enhancements are left for
	future specifications.		future specifications.
	For the ECVRF, the Verifier MUST obtain E and B from a trusted		For the ECVRF, the Verifier MUST obtain E and B from a trusted
	source, such as a ciphersuite specification, rather than from the		source, such as a ciphersuite specification, rather than from the
	prover. If the verifier does so, then the ECVRF satisfies "full		Prover. If the Verifier does so, then the ECVRF satisfies "full
	uniqueness", ensuring uniqueness even under malicious key generation.		uniqueness", ensuring uniqueness even under malicious key generation.
	The ECVRF also satisfies "trusted collision resistance". It		The ECVRF also satisfies "trusted collision resistance". It
	additionally satisfies "full collision resistance" if the		additionally satisfies "full collision resistance" if the
	validate_key parameter given to ECVRF_verify is TRUE. This setting		validate_key parameter given to ECVRF_verify is TRUE. This setting
	of ECVRF_verify ensures collision resistance under malicious key		of ECVRF_verify ensures collision resistance under malicious key
	generation.		generation.
	7.1.2. Pseudorandomness under Malicious Key Generation		7.1.2. Pseudorandomness under Malicious Key Generation
	Without good randomness, the "pseudorandomness" properties of the VRF		Without good randomness, the "pseudorandomness" properties of the VRF
	skipping to change at line 1561 ¶		skipping to change at line 1561 ¶
	a VRF output under one variant and then claim it was obtained under		a VRF output under one variant and then claim it was obtained under
	another variant, they should specify a different suite_string		another variant, they should specify a different suite_string
	constant. The suite_string constants discussed in this document are		constant. The suite_string constants discussed in this document are
	all single octets; if a future suite_string constant is longer than		all single octets; if a future suite_string constant is longer than
	one octet, then it should start with a different octet than the		one octet, then it should start with a different octet than the
	suite_string constants discussed in this document. Then, for the		suite_string constants discussed in this document. Then, for the
	RSA-FDH-VRF, the inputs to the hash function used in MGF1 and		RSA-FDH-VRF, the inputs to the hash function used in MGF1 and
	proof_to_hash will be different from other ciphersuites. For the		proof_to_hash will be different from other ciphersuites. For the
	ECVRF, the inputs to the ECVRF_encode_to_curve hash function used in		ECVRF, the inputs to the ECVRF_encode_to_curve hash function used in
	producing H are then guaranteed to be different from other		producing H are then guaranteed to be different from other
	ciphersuites; since all the other hashing done by the prover depends		ciphersuites; since all the other hashing done by the Prover depends
	on H, inputs to all the hash functions used by the prover will also		on H, inputs to all the hash functions used by the Prover will also
	be different from other ciphersuites as long as ECVRF_encode_to_curve		be different from other ciphersuites as long as ECVRF_encode_to_curve
	is collision resistant.		is collision resistant.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	skipping to change at line 1606 ¶		skipping to change at line 1606 ¶
	Signature Algorithm (EdDSA)", RFC 8032,		Signature Algorithm (EdDSA)", RFC 8032,
	DOI 10.17487/RFC8032, January 2017,		DOI 10.17487/RFC8032, January 2017,
	<https://www.rfc-editor.org/info/rfc8032>.		<https://www.rfc-editor.org/info/rfc8032>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC9380] Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R. S.,		[RFC9380] Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R. S.,
	and C. A. Wood, "Hashing to Elliptic Curves", RFC 9380,		and C. A. Wood, "Hashing to Elliptic Curves", RFC 9380,
	DOI 10.17487/RFC9380, April 2023,		DOI 10.17487/RFC9380, August 2023,
	<https://www.rfc-editor.org/info/rfc9380>.		<https://www.rfc-editor.org/info/rfc9380>.
	[SECG1] Standards for Efficient Cryptography Group (SECG), "SEC 1:		[SECG1] Standards for Efficient Cryptography Group (SECG), "SEC 1:
	Elliptic Curve Cryptography", Version 2.0, May 2009,		Elliptic Curve Cryptography", Version 2.0, May 2009,
	<http://www.secg.org/sec1-v2.pdf>.		<https://www.secg.org/sec1-v2.pdf>.
	[SP-800-186]		[SP-800-186]
	National Institute for Standards and Technology (NIST),		National Institute for Standards and Technology (NIST),
	"Recommendations for Discrete Logarithm-based		"Recommendations for Discrete Logarithm-based
	Cryptography: Elliptic Curve Domain Parameters", NIST SP		Cryptography: Elliptic Curve Domain Parameters", NIST SP
	800-186, DOI 10.6028/NIST.SP.800-186, February 2023,		800-186, DOI 10.6028/NIST.SP.800-186, February 2023,
	<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/		<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
	NIST.SP.800-186.pdf>.		NIST.SP.800-186.pdf>.
	8.2. Informative References		8.2. Informative References
	skipping to change at line 1639 ¶		skipping to change at line 1639 ¶
	ANSI%20X9.62>.		ANSI%20X9.62>.
	[BreHen19] Breitner, J. and N. Heninger, "Biased Nonce Sense: Lattice		[BreHen19] Breitner, J. and N. Heninger, "Biased Nonce Sense: Lattice
	Attacks against Weak ECDSA Signatures in		Attacks against Weak ECDSA Signatures in
	Cryptocurrencies", Cryptology ePrint Archive, Paper		Cryptocurrencies", Cryptology ePrint Archive, Paper
	2019/023, April 2019, <https://eprint.iacr.org/2019/023>.		2019/023, April 2019, <https://eprint.iacr.org/2019/023>.
	[DGKR18] David, B., Gaži, P., Kiayias, A., and A. Russell,		[DGKR18] David, B., Gaži, P., Kiayias, A., and A. Russell,
	"Ouroboros Praos: An adaptively-secure, semi-synchronous		"Ouroboros Praos: An adaptively-secure, semi-synchronous
	proof-of-stake blockchain", Cryptology ePrint Archive,		proof-of-stake blockchain", Cryptology ePrint Archive,
	Paper 2017/573, November 2017,		Paper 2017/573, April 2023,
	<https://eprint.iacr.org/2017/573>.		<https://eprint.iacr.org/2017/573>.
	[GHMVZ17] Gilad, Y., Hemo, R., Micali, S., Vlachos, G., and N.		[GHMVZ17] Gilad, Y., Hemo, R., Micali, S., Vlachos, G., and N.
	Zeldovich, "Algorand: Scaling Byzantine Agreements for		Zeldovich, "Algorand: Scaling Byzantine Agreements for
	Cryptocurrencies", Cryptology ePrint Archive, Paper		Cryptocurrencies", Cryptology ePrint Archive, Paper
	2017/454, September 2017,		2017/454, September 2017,
	<https://eprint.iacr.org/2017/454>.		<https://eprint.iacr.org/2017/454>.
	[GNPRVZ15] Goldberg, S., Naor, M., Papadopoulos, D., Reyzin, L.,		[GNPRVZ15] Goldberg, S., Naor, M., Papadopoulos, D., Reyzin, L.,
	Vasant, S., and A. Ziv, "NSEC5: Provably Preventing DNSSEC		Vasant, S., and A. Ziv, "NSEC5: Provably Preventing DNSSEC
End of changes. 9 change blocks.
	10 lines changed or deleted		10 lines changed or added
This html diff was produced by rfcdiff 1.48.