From 91b83b6d68d84b04963dd89e8afa42424ecaae98 Mon Sep 17 00:00:00 2001 From: Leonid Reyzin Date: Tue, 9 Nov 2021 10:39:55 -0500 Subject: [PATCH] tighter integration of Sections 3 and 7 --- draft-irtf-cfrg-vrf.html | 43 +-- draft-irtf-cfrg-vrf.txt | 550 +++++++++++++++++++-------------------- draft-irtf-cfrg-vrf.xml | 50 +++- 3 files changed, 336 insertions(+), 307 deletions(-) diff --git a/draft-irtf-cfrg-vrf.html b/draft-irtf-cfrg-vrf.html index 56d3450..98a437c 100644 --- a/draft-irtf-cfrg-vrf.html +++ b/draft-irtf-cfrg-vrf.html @@ -405,7 +405,7 @@ - + @@ -429,7 +429,7 @@ - + @@ -453,7 +453,7 @@ L. Reyzin -Expires: May 12, 2022 +Expires: May 13, 2022 Boston University and Algorand @@ -474,7 +474,7 @@ -November 8, 2021 +November 9, 2021 @@ -490,7 +490,7 @@

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

-

This Internet-Draft will expire on May 12, 2022.

+

This Internet-Draft will expire on May 13, 2022.

Copyright Notice

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

@@ -562,7 +562,7 @@

Table of Contents

  • 7.1.2. Pseudorandomness with untrusted keys
    • -
  • 7.2. Selective vs Full Pseudorandomness +
  • 7.2. Selective vs. Full Pseudorandomness
  • 7.3. Proper pseudorandom nonce for ECVRF
    • @@ -663,15 +663,19 @@

    VRFs are designed to ensure the following security properties.

    -3.1. Full Uniqueness or Trusted Uniqueness

    +3.1. Full Uniqueness or Trusted Uniqueness +

    Uniqueness means that, for any fixed public VRF key and for any input alpha, there is a unique VRF output beta that can be proved to be valid. Uniqueness must hold even for an adversarial Prover that knows the VRF private key SK.

    More precisely, "full uniqueness" states that a computationally-bounded adversary cannot choose a VRF public key PK, a VRF input alpha, and two proofs pi1 and pi2 such that VRF_verify(PK, alpha, pi1) outputs (VALID, beta1), VRF_verify(PK, alpha, pi2) outputs (VALID, beta2), and beta1 is not equal to beta2.

    -

    A slightly weaker security property called "trusted uniqueness" suffices for many applications. Trusted uniqueness is the same as full uniqueness, but it must hold only if the VRF keys PK and SK were generated in a trustworthy manner. In other words, uniqueness might not hold if keys were generated in an invalid manner or with bad randomness.

    +

    For many applications, a slightly weaker security property called "trusted uniqueness" suffices. Trusted uniqueness is the same as full uniqueness, but it is guaranteed to hold only if the VRF keys PK and SK were generated in a trustworthy manner.

    +

    As further discussed in Section 7.1.1, some VRFs specified in this document satisfy only trusted uniqueness, while others satisfy full uniqueness. VRFs in this document that satisfy only trusted uniqueness but not full uniqueness MUST NOT be used if the key generation process cannot be trusted.

    -3.2. Full Collison Resistance or Trusted Collision Resistance

    +3.2. Full Collison Resistance or Trusted Collision Resistance +

    Like any cryptographic hash function, VRFs need to be collision resistant. Collison resistance must hold even for an adversarial Prover that knows the VRF private key SK.

    More precisely, "full collision resistance" states that it should be computationally infeasible for an adversary to find two distinct VRF inputs alpha1 and alpha2 that have the same VRF hash beta, even if that adversary knows the private VRF key SK.

    -

    For most applications, a slightly weaker security property called "trusted collision resistance" suffices. Trusted collision resistance is the same as collision resistance, but it holds only if PK and SK were generated in a trustworthy manner.

    +

    For many applications, a slightly weaker security property called "trusted collision resistance" suffices. Trusted collision resistance is the same as collision resistance, but it is guaranteed to hold only if the VRF keys PK and SK were generated in a trustworthy manner.

    +

    As further discussed in Section 7.1.1, some VRFs specified in this document satisfy only trusted collision resistance, while others satisfy full collision resistance. VRFs in this document that satisfy only trusted collision resistance but not full collision resistance MUST NOT be used if the key generation process cannot be trusted.

    3.3. Full Pseudorandomness or Selective Pseudorandomness

    @@ -679,9 +683,10 @@

    More precisely, suppose the public and private VRF keys (PK, SK) were generated in a trustworthy manner. Pseudorandomness ensures that the VRF hash output beta (without its corresponding VRF proof pi) on any adversarially-chosen "target" VRF input alpha looks indistinguishable from random for any computationally bounded adversary who does not know the private VRF key SK. This holds even if the adversary also gets to choose other VRF inputs alpha' and observe their corresponding VRF hash outputs beta' and proofs pi'.

    With "full pseudorandomness", the adversary is allowed to choose the "target" VRF input alpha at any time, even after it observes VRF outputs beta' and proofs pi' on a variety of chosen inputs alpha'.

    "Selective pseudorandomness" is a weaker security property which suffices in many applications. Here, the adversary must choose the target VRF input alpha independently of the public VRF key PK, and before it observes VRF outputs beta' and proofs pi' on inputs alpha' of its choice.

    -

    It is important to remember that the VRF output beta does not look random to the Prover, or to any other party that knows the private VRF key SK! Such a party can easily distinguish beta from a random value by comparing beta to the result of VRF_hash(SK, alpha).

    -

    Also, the VRF output beta does not look random to any party that knows the valid VRF proof pi corresponding to the VRF input alpha, even if this party does not know the private VRF key SK. Such a party can easily distinguish beta from a random value by checking whether VRF_verify(PK, alpha, pi) returns (VALID, beta).

    -

    Also, the VRF output beta may not look random if VRF key generation was not done in a trustworthy fashion. (For example, if VRF keys were generated with bad randomness.)

    +

    As further discussed in Section 7.2, VRFs specified in this document satisfy both full pseudorandomness and selective pseudorandomness, but their quantitative security against the selective pseudorandomness attack is stronger.

    +

    It is important to remember that the VRF output beta does not look random to the Prover, or to any other party that knows the private VRF key SK! Such a party can easily distinguish beta from a random value by comparing beta to the result of VRF_hash(SK, alpha).

    +

    Also, the VRF output beta does not look random to any party that knows the valid VRF proof pi corresponding to the VRF input alpha, even if this party does not know the private VRF key SK. Such a party can easily distinguish beta from a random value by checking whether VRF_verify(PK, alpha, pi) returns (VALID, beta).

    +

    Also, the VRF output beta may not look random if VRF key generation was not done in a trustworthy fashion. (For example, if VRF keys were generated with bad randomness.)

    3.4. A random-oracle-like unpredictability property

    As explained in Section 3.3, pseudorandomness is guaranteed only if the VRF keys were generated in a trustworthy fashion. For instance, if an adversary outputs VRF keys that are deterministically generated (or hard-coded and publicly known), then the outputs are easily derived by anyone and are therefore not pseudorandom.

    @@ -1306,16 +1311,18 @@

    7.1. Key Generation

    Applications that use the VRFs defined in this document MUST ensure that that the VRF key is generated correctly, using good randomness.

    -7.1.1. Uniqueness and collision resistance with untrusted keys

    -

    The ECVRF as specified in Section 5.1-Section 5.5 satisfies the "trusted uniqueness" and "trusted collision resistance" properties as long as the VRF keys are generated correctly, with good randomness. If the Verifier trusts the VRF keys are generated correctly, it MAY use the public key Y as is.

    +7.1.1. Uniqueness and collision resistance with untrusted keys + +

    The ECVRF as specified in Section 5.1-Section 5.5 satisfies the "trusted uniqueness" (see Section 3.1) and "trusted collision resistance" (see Section 3.2) properties as long as the VRF keys are generated correctly, with good randomness. If the Verifier trusts the VRF keys are generated correctly, it MAY use the public key Y as is.

    However, if the ECVRF uses keys that could be generated adversarially, then the Verifier MUST first perform the validation procedure ECVRF_validate_key(PK) (specified in Section 5.6) upon receipt of the public key PK as an octet string. If the validation procedure outputs "INVALID", then the public key MUST not be used. Otherwise, the procedure will output a valid public key Y, and the ECVRF with public key Y satisfies the "full uniqueness" and "full collision resistance" properties.

    The RSA-FDH-VRF satisfies the "trusted uniqueness" and "trusted collision resistance" properties as long as the VRF keys are generated correctly, with good randomness. These properties may not hold if the keys are generated adversarially (e.g., if the RSA function specified in the public key is not bijective). Meanwhile, the "full uniqueness" and "full collision resistance" are properties that hold even if VRF keys are generated by an adversary. The RSA-FDH-VRF defined in this document does not have these properties. However, if adversarial key generation is a concern, the RSA-FDH-VRF may be modified to have these properties by adding additional cryptographic checks that its public key has the right form. These modifications are left for future specification.

    7.1.2. Pseudorandomness with untrusted keys

    Without good randomness, the "pseudorandomness" properties of the VRF may not hold. Note that it is not possible to guarantee pseudorandomness in the face of adversarially generated VRF keys. This is because an adversary can always use bad randomness to generate the VRF keys, and thus, the VRF output may not be pseudorandom.

    -7.2. Selective vs Full Pseudorandomness

    -

    [PWHVNRG17] presents cryptographic reductions to an underlying hard problem (e.g. Decisional Diffie-Hellman for the ECVRF, or the standard RSA assumption for RSA-FDH-VRF) that prove the VRFs specified in this document possess full pseudorandomness as well as selective pseudorandomness. However, the cryptographic reductions are tighter for selective pseudorandomness than for full pseudorandomness. This means that the VRFs have quantitively stronger security guarantees for selective pseudorandomness.

    +7.2. Selective vs. Full Pseudorandomness + +

    [PWHVNRG17] presents cryptographic reductions to an underlying hard problem (e.g. Decisional Diffie-Hellman for the ECVRF, or the standard RSA assumption for RSA-FDH-VRF) that prove the VRFs specified in this document possess full pseudorandomness as well as selective pseudorandomness (see Section 3.3 for an explanation of these notions). However, the cryptographic reductions are tighter for selective pseudorandomness than for full pseudorandomness. This means that the VRFs have quantitively stronger security guarantees for selective pseudorandomness.

    Applications that are concerned about tightness of cryptographic reductions therefore have two options.

    diff --git a/draft-irtf-cfrg-vrf.txt b/draft-irtf-cfrg-vrf.txt index 5cb3ed1..9b45368 100644 --- a/draft-irtf-cfrg-vrf.txt +++ b/draft-irtf-cfrg-vrf.txt @@ -5,12 +5,12 @@ CFRG S. Goldberg Internet-Draft Boston University Intended status: Standards Track L. Reyzin -Expires: May 12, 2022 Boston University and Algorand +Expires: May 13, 2022 Boston University and Algorand D. Papadopoulos Hong Kong University of Science and Technology J. Vcelak NS1 - November 8, 2021 + November 9, 2021 Verifiable Random Functions (VRFs) @@ -41,7 +41,7 @@ Status of This Memo time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on May 12, 2022. + This Internet-Draft will expire on May 13, 2022. Copyright Notice @@ -53,7 +53,7 @@ Copyright Notice -Goldberg, et al. Expires May 12, 2022 [Page 1] +Goldberg, et al. Expires May 13, 2022 [Page 1] Internet-Draft VRF November 2021 @@ -76,8 +76,8 @@ Table of Contents 3. VRF Security Properties . . . . . . . . . . . . . . . . . . . 5 3.1. Full Uniqueness or Trusted Uniqueness . . . . . . . . . . 5 3.2. Full Collison Resistance or Trusted Collision Resistance 5 - 3.3. Full Pseudorandomness or Selective Pseudorandomness . . . 5 - 3.4. A random-oracle-like unpredictability property . . . . . 6 + 3.3. Full Pseudorandomness or Selective Pseudorandomness . . . 6 + 3.4. A random-oracle-like unpredictability property . . . . . 7 4. RSA Full Domain Hash VRF (RSA-FDH-VRF) . . . . . . . . . . . 7 4.1. RSA-FDH-VRF Proving . . . . . . . . . . . . . . . . . . . 8 4.2. RSA-FDH-VRF Proof to Hash . . . . . . . . . . . . . . . . 9 @@ -87,29 +87,29 @@ Table of Contents 5.2. ECVRF Proof to Hash . . . . . . . . . . . . . . . . . . . 13 5.3. ECVRF Verifying . . . . . . . . . . . . . . . . . . . . . 14 5.4. ECVRF Auxiliary Functions . . . . . . . . . . . . . . . . 14 - 5.4.1. ECVRF Hash to Curve . . . . . . . . . . . . . . . . . 14 + 5.4.1. ECVRF Hash to Curve . . . . . . . . . . . . . . . . . 15 5.4.2. ECVRF Nonce Generation . . . . . . . . . . . . . . . 17 5.4.3. ECVRF Hash Points . . . . . . . . . . . . . . . . . . 18 5.4.4. ECVRF Decode Proof . . . . . . . . . . . . . . . . . 19 5.5. ECVRF Ciphersuites . . . . . . . . . . . . . . . . . . . 20 5.6. When the ECVRF Keys are Untrusted . . . . . . . . . . . . 22 5.6.1. ECVRF Validate Key . . . . . . . . . . . . . . . . . 23 - 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 24 + 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7.1. Key Generation . . . . . . . . . . . . . . . . . . . . . 26 7.1.1. Uniqueness and collision resistance with untrusted keys . . . . . . . . . . . . . . . . . . . . . . . . 26 - 7.1.2. Pseudorandomness with untrusted keys . . . . . . . . 26 - 7.2. Selective vs Full Pseudorandomness . . . . . . . . . . . 27 + 7.1.2. Pseudorandomness with untrusted keys . . . . . . . . 27 + 7.2. Selective vs. Full Pseudorandomness . . . . . . . . . . . 27 7.3. Proper pseudorandom nonce for ECVRF . . . . . . . . . . . 27 - 7.4. Side-channel attacks . . . . . . . . . . . . . . . . . . 27 + 7.4. Side-channel attacks . . . . . . . . . . . . . . . . . . 28 7.5. Proofs provide no secrecy for the VRF input . . . . . . . 28 7.6. Prehashing . . . . . . . . . . . . . . . . . . . . . . . 28 - 7.7. Hash function domain separation and futureproofing . . . 28 + 7.7. Hash function domain separation and futureproofing . . . 29 -Goldberg, et al. Expires May 12, 2022 [Page 2] +Goldberg, et al. Expires May 13, 2022 [Page 2] Internet-Draft VRF November 2021 @@ -165,7 +165,7 @@ Internet-Draft VRF November 2021 -Goldberg, et al. Expires May 12, 2022 [Page 3] +Goldberg, et al. Expires May 13, 2022 [Page 3] Internet-Draft VRF November 2021 @@ -221,7 +221,7 @@ Internet-Draft VRF November 2021 -Goldberg, et al. Expires May 12, 2022 [Page 4] +Goldberg, et al. Expires May 13, 2022 [Page 4] Internet-Draft VRF November 2021 @@ -243,12 +243,16 @@ Internet-Draft VRF November 2021 pi1) outputs (VALID, beta1), VRF_verify(PK, alpha, pi2) outputs (VALID, beta2), and beta1 is not equal to beta2. - A slightly weaker security property called "trusted uniqueness" - suffices for many applications. Trusted uniqueness is the same as - full uniqueness, but it must hold only if the VRF keys PK and SK were - generated in a trustworthy manner. In other words, uniqueness might - not hold if keys were generated in an invalid manner or with bad - randomness. + For many applications, a slightly weaker security property called + "trusted uniqueness" suffices. Trusted uniqueness is the same as + full uniqueness, but it is guaranteed to hold only if the VRF keys PK + and SK were generated in a trustworthy manner. + + As further discussed in Section 7.1.1, some VRFs specified in this + document satisfy only trusted uniqueness, while others satisfy full + uniqueness. VRFs in this document that satisfy only trusted + uniqueness but not full uniqueness MUST NOT be used if the key + generation process cannot be trusted. 3.2. Full Collison Resistance or Trusted Collision Resistance @@ -261,10 +265,26 @@ Internet-Draft VRF November 2021 inputs alpha1 and alpha2 that have the same VRF hash beta, even if that adversary knows the private VRF key SK. - For most applications, a slightly weaker security property called + For many applications, a slightly weaker security property called "trusted collision resistance" suffices. Trusted collision - resistance is the same as collision resistance, but it holds only if - PK and SK were generated in a trustworthy manner. + resistance is the same as collision resistance, but it is guaranteed + to hold only if the VRF keys PK and SK were generated in a + trustworthy manner. + + As further discussed in Section 7.1.1, some VRFs specified in this + document satisfy only trusted collision resistance, while others + satisfy full collision resistance. VRFs in this document that + + + +Goldberg, et al. Expires May 13, 2022 [Page 5] + +Internet-Draft VRF November 2021 + + + satisfy only trusted collision resistance but not full collision + resistance MUST NOT be used if the key generation process cannot be + trusted. 3.3. Full Pseudorandomness or Selective Pseudorandomness @@ -274,14 +294,6 @@ Internet-Draft VRF November 2021 More precisely, suppose the public and private VRF keys (PK, SK) were generated in a trustworthy manner. Pseudorandomness ensures that the - - - -Goldberg, et al. Expires May 12, 2022 [Page 5] - -Internet-Draft VRF November 2021 - - VRF hash output beta (without its corresponding VRF proof pi) on any adversarially-chosen "target" VRF input alpha looks indistinguishable from random for any computationally bounded adversary who does not @@ -299,6 +311,11 @@ Internet-Draft VRF November 2021 before it observes VRF outputs beta' and proofs pi' on inputs alpha' of its choice. + As further discussed in Section 7.2, VRFs specified in this document + satisfy both full pseudorandomness and selective pseudorandomness, + but their quantitative security against the selective + pseudorandomness attack is stronger. + It is important to remember that the VRF output beta does not look random to the Prover, or to any other party that knows the private VRF key SK! Such a party can easily distinguish beta from a random @@ -314,6 +331,13 @@ Internet-Draft VRF November 2021 was not done in a trustworthy fashion. (For example, if VRF keys were generated with bad randomness.) + + +Goldberg, et al. Expires May 13, 2022 [Page 6] + +Internet-Draft VRF November 2021 + + 3.4. A random-oracle-like unpredictability property As explained in Section 3.3, pseudorandomness is guaranteed only if @@ -329,15 +353,6 @@ Internet-Draft VRF November 2021 has enough entropy (i.e., cannot be predicted), then the correct output is indistinguishable from uniform. - - - - -Goldberg, et al. Expires May 12, 2022 [Page 6] - -Internet-Draft VRF November 2021 - - A formal definition of this property appears in Section 3.2 of [DGKR18]. The VRF schemes presented in this specification are believed to satisfy this property if the public key was generated in @@ -372,6 +387,13 @@ Internet-Draft VRF November 2021 K - RSA private key + + +Goldberg, et al. Expires May 13, 2022 [Page 7] + +Internet-Draft VRF November 2021 + + k - length in octets of the RSA modulus n (k must be less than 2^32) @@ -385,15 +407,6 @@ Internet-Draft VRF November 2021 I2OSP - Conversion of a nonnegative integer to an octet string as defined in Section 4.1 of [RFC8017] (given an integer and a length - - - - -Goldberg, et al. Expires May 12, 2022 [Page 7] - -Internet-Draft VRF November 2021 - - in octets, produces a big-endian representation of the integer, zero-padded to the desired length) @@ -430,6 +443,13 @@ Internet-Draft VRF November 2021 Steps: + + +Goldberg, et al. Expires May 13, 2022 [Page 8] + +Internet-Draft VRF November 2021 + + 1. one_string = 0x01 = I2OSP(1, 1), a single octet with value 1 2. EM = MGF1(one_string || I2OSP(k, 4) || I2OSP(n, k) || @@ -443,13 +463,6 @@ Internet-Draft VRF November 2021 6. Output pi_string - - -Goldberg, et al. Expires May 12, 2022 [Page 8] - -Internet-Draft VRF November 2021 - - 4.2. RSA-FDH-VRF Proof to Hash RSAFDHVRF_proof_to_hash(pi_string) @@ -486,6 +499,13 @@ Internet-Draft VRF November 2021 alpha_string - VRF hash input, an octet string + + +Goldberg, et al. Expires May 13, 2022 [Page 9] + +Internet-Draft VRF November 2021 + + pi_string - proof to be verified, an octet string of length n Output: @@ -498,14 +518,6 @@ Internet-Draft VRF November 2021 1. s = OS2IP(pi_string) - - - -Goldberg, et al. Expires May 12, 2022 [Page 9] - -Internet-Draft VRF November 2021 - - 2. m = RSAVP1((n, e), s) 3. EM = I2OSP(m, k - 1) @@ -542,6 +554,14 @@ Internet-Draft VRF November 2021 x*y - x multiplied by y + + + +Goldberg, et al. Expires May 13, 2022 [Page 10] + +Internet-Draft VRF November 2021 + + s || t - concatenation of octet strings s and t Fixed options (specified in Section 5.5): @@ -553,15 +573,6 @@ Internet-Draft VRF November 2021 E - elliptic curve (EC) defined over F - - - - -Goldberg, et al. Expires May 12, 2022 [Page 10] - -Internet-Draft VRF November 2021 - - ptLen - length, in octets, of an EC point encoded as an octet string @@ -599,6 +610,14 @@ Internet-Draft VRF November 2021 string_to_int(a_string) - conversion of an octet string a_string to a nonnegative integer + + + +Goldberg, et al. Expires May 13, 2022 [Page 11] + +Internet-Draft VRF November 2021 + + point_to_string - conversion of EC point to an ptLen-octet string string_to_point - conversion of an ptLen-octet string to EC point. @@ -609,15 +628,6 @@ Internet-Draft VRF November 2021 elliptic curve arithmetic), the int_to_string and point_to_string conversions are not needed. For example, in some implementations, EC point operations will take octet strings as inputs and produce - - - - -Goldberg, et al. Expires May 12, 2022 [Page 11] - -Internet-Draft VRF November 2021 - - octet strings as outputs, without introducing a separate elliptic curve point type. @@ -657,6 +667,13 @@ Internet-Draft VRF November 2021 2. H = ECVRF_hash_to_curve(Y, alpha_string) + + +Goldberg, et al. Expires May 13, 2022 [Page 12] + +Internet-Draft VRF November 2021 + + 3. h_string = point_to_string(H) 4. Gamma = x*H @@ -667,13 +684,6 @@ Internet-Draft VRF November 2021 7. s = (k + c*x) mod q - - -Goldberg, et al. Expires May 12, 2022 [Page 12] - -Internet-Draft VRF November 2021 - - 8. pi_string = point_to_string(Gamma) || int_to_string(c, n) || int_to_string(s, qLen) @@ -713,23 +723,18 @@ Internet-Draft VRF November 2021 5. zero_string = 0x00 = int_to_string(0, 1), a single octet with value 0 - 6. beta_string = Hash(suite_string || three_string || - point_to_string(cofactor * Gamma) || zero_string) - - 7. Output beta_string - - - - - - -Goldberg, et al. Expires May 12, 2022 [Page 13] +Goldberg, et al. Expires May 13, 2022 [Page 13] Internet-Draft VRF November 2021 + 6. beta_string = Hash(suite_string || three_string || + point_to_string(cofactor * Gamma) || zero_string) + + 7. Output beta_string + 5.3. ECVRF Verifying ECVRF_verify(Y, pi_string, alpha_string) @@ -769,23 +774,25 @@ Internet-Draft VRF November 2021 5.4. ECVRF Auxiliary Functions -5.4.1. ECVRF Hash to Curve - The ECVRF_hash_to_curve algorithm takes in the VRF input alpha and - converts it to H, an EC point in G. This algorithm is the only place - the VRF input alpha is used for proving and verifying. See - Section 7.6 for further discussion. -Goldberg, et al. Expires May 12, 2022 [Page 14] +Goldberg, et al. Expires May 13, 2022 [Page 14] Internet-Draft VRF November 2021 +5.4.1. ECVRF Hash to Curve + + The ECVRF_hash_to_curve algorithm takes in the VRF input alpha and + converts it to H, an EC point in G. This algorithm is the only place + the VRF input alpha is used for proving and verifying. See + Section 7.6 for further discussion. + This section specifies a number of such algorithms, which are not compatible with each other. The choice of a particular algorithm from the options specified in this section is made in Section 5.5. @@ -828,20 +835,19 @@ Internet-Draft VRF November 2021 2. PK_string = point_to_string(Y) - 3. one_string = 0x01 = int_to_string(1, 1), a single octet with - value 1 - - 4. zero_string = 0x00 = int_to_string(0, 1), a single octet with - value 0 - - -Goldberg, et al. Expires May 12, 2022 [Page 15] +Goldberg, et al. Expires May 13, 2022 [Page 15] Internet-Draft VRF November 2021 + 3. one_string = 0x01 = int_to_string(1, 1), a single octet with + value 1 + + 4. zero_string = 0x00 = int_to_string(0, 1), a single octet with + value 0 + 5. H = "INVALID" 6. While H is "INVALID" or H is the identity element of the elliptic @@ -883,21 +889,22 @@ Internet-Draft VRF November 2021 Fixed option (specified in Section 5.5): - h2c_suite_ID_string - a hash-to-curve suite ID, encoded in ASCII - (see discussion below) - - Steps - - 1. PK_string = point_to_string(Y) -Goldberg, et al. Expires May 12, 2022 [Page 16] +Goldberg, et al. Expires May 13, 2022 [Page 16] Internet-Draft VRF November 2021 + h2c_suite_ID_string - a hash-to-curve suite ID, encoded in ASCII + (see discussion below) + + Steps + + 1. PK_string = point_to_string(Y) + 2. string_to_hash = PK_string || alpha_string 3. H = encode(string_to_hash) @@ -940,19 +947,19 @@ Internet-Draft VRF November 2021 The ECVRF_nonce_generation function is as specified in [RFC6979] Section 3.2 where - Input m is set equal to h_string - The "suitable for DSA or ECDSA" check in step h.3 is omitted - The hash function H is Hash and its output length hlen is set as - hLen*8 +Goldberg, et al. Expires May 13, 2022 [Page 17] + +Internet-Draft VRF November 2021 + Input m is set equal to h_string -Goldberg, et al. Expires May 12, 2022 [Page 17] - -Internet-Draft VRF November 2021 + The "suitable for DSA or ECDSA" check in step h.3 is omitted + The hash function H is Hash and its output length hlen is set as + hLen*8 The secret key x is set equal to the VRF secret scalar x @@ -996,19 +1003,18 @@ Internet-Draft VRF November 2021 Input: - P1...PM - EC points in G - - Output: - c - hash value, integer between 0 and 2^(8n)-1 +Goldberg, et al. Expires May 13, 2022 [Page 18] + +Internet-Draft VRF November 2021 + P1...PM - EC points in G -Goldberg, et al. Expires May 12, 2022 [Page 18] - -Internet-Draft VRF November 2021 + Output: + c - hash value, integer between 0 and 2^(8n)-1 Steps: @@ -1053,18 +1059,18 @@ Internet-Draft VRF November 2021 Steps: - 1. let gamma_string = pi_string[0]...pi_string[ptLen-1] - 2. let c_string = pi_string[ptLen]...pi_string[ptLen+n-1] - 3. let s_string =pi_string[ptLen+n]...pi_string[ptLen+n+qLen-1] +Goldberg, et al. Expires May 13, 2022 [Page 19] + +Internet-Draft VRF November 2021 + 1. let gamma_string = pi_string[0]...pi_string[ptLen-1] -Goldberg, et al. Expires May 12, 2022 [Page 19] - -Internet-Draft VRF November 2021 + 2. let c_string = pi_string[ptLen]...pi_string[ptLen+n-1] + 3. let s_string =pi_string[ptLen+n]...pi_string[ptLen+n+qLen-1] 4. Gamma = string_to_point(gamma_string) @@ -1108,20 +1114,19 @@ Internet-Draft VRF November 2021 string according to the encoding specified in Section 2.3.3 of [SECG1] with point compression on. This implies ptLen = 2n + 1 = 33. (Note that certain software implementations do not introduce - a separate elliptic curve point type and instead directly treat - the EC point as an octet string per above encoding. When using - such an implementation, the point_to_string function can be - treated as the identity function.) - - -Goldberg, et al. Expires May 12, 2022 [Page 20] +Goldberg, et al. Expires May 13, 2022 [Page 20] Internet-Draft VRF November 2021 + a separate elliptic curve point type and instead directly treat + the EC point as an octet string per above encoding. When using + such an implementation, the point_to_string function can be + treated as the identity function.) + o The string_to_point function converts an octet string to an EC point according to the encoding specified in Section 2.3.4 of [SECG1]. This function MUST output INVALID if the octet string @@ -1163,21 +1168,23 @@ Internet-Draft VRF November 2021 o The ECVRF_nonce_generation function is as specified in Section 5.4.2.2. - o The int_to_string function as specified in the first paragraph of - Section 5.1.2 of [RFC8032]. (This is little-endian - representation.) - o The string_to_int function interprets the string as an integer in - little-endian representation. -Goldberg, et al. Expires May 12, 2022 [Page 21] +Goldberg, et al. Expires May 13, 2022 [Page 21] Internet-Draft VRF November 2021 + o The int_to_string function as specified in the first paragraph of + Section 5.1.2 of [RFC8032]. (This is little-endian + representation.) + + o The string_to_int function interprets the string as an integer in + little-endian representation. + o The point_to_string function converts an EC point to an octet string according to the encoding specified in Section 5.1.2 of [RFC8032]. This implies ptLen = 2n = 32. (Note that certain @@ -1218,22 +1225,23 @@ Internet-Draft VRF November 2021 obtain "full uniqueness" and "full collision resistance" (which provide protection against a malicious VRF public key), the Verifier MUST perform the following additional validation procedure upon - receipt of the public VRF key. The public VRF key MUST NOT be used - if this procedure returns "INVALID". - - Note that this procedure is not sufficient if the elliptic curve E or - the point B, the generator of group G, is untrusted. If the prover - is untrusted, the Verifier MUST obtain E and B from a trusted source, - such as a ciphersuite specification, rather than from the prover. -Goldberg, et al. Expires May 12, 2022 [Page 22] +Goldberg, et al. Expires May 13, 2022 [Page 22] Internet-Draft VRF November 2021 + receipt of the public VRF key. The public VRF key MUST NOT be used + if this procedure returns "INVALID". + + Note that this procedure is not sufficient if the elliptic curve E or + the point B, the generator of group G, is untrusted. If the prover + is untrusted, the Verifier MUST obtain E and B from a trusted source, + such as a ciphersuite specification, rather than from the prover. + This procedure supposes that the public key provided to the Verifier is an octet string. The procedure returns "INVALID" if the public key in invalid. Otherwise, it returns Y, the public key as an EC @@ -1274,6 +1282,14 @@ Internet-Draft VRF November 2021 list of such points. For example, the following algorithm can be used for the edwards25519 curve: + + + +Goldberg, et al. Expires May 13, 2022 [Page 23] + +Internet-Draft VRF November 2021 + + 1. Y = string_to_point(PK_string) 2. If Y is "INVALID", output "INVALID" and stop @@ -1283,13 +1299,6 @@ Internet-Draft VRF November 2021 4. oneTwentySeven_string = 0x7F = int_to_string(127, 1) (a single octet with value 127) - - -Goldberg, et al. Expires May 12, 2022 [Page 23] - -Internet-Draft VRF November 2021 - - 5. y_string[31] = y_string[31] & oneTwentySeven_string (this step clears the high-order bit of octet 31) @@ -1327,6 +1336,16 @@ Internet-Draft VRF November 2021 have been obtained by converting the points specified in [X25519] to Edwards coordinates.) + + + + + +Goldberg, et al. Expires May 13, 2022 [Page 24] + +Internet-Draft VRF November 2021 + + 6. Implementation Status Note to RFC editor: Remove before publication @@ -1337,15 +1356,6 @@ Internet-Draft VRF November 2021 ecvrf>. This implementation is neither secure nor especially efficient, but can be used to generate test vectors. - - - - -Goldberg, et al. Expires May 12, 2022 [Page 24] - -Internet-Draft VRF November 2021 - - A Python implementation of an older version of ECVRF- EDWARDS25519-SHA512-ELL2 from the -05 version of this draft is available at . @@ -1394,14 +1413,6 @@ Internet-Draft VRF November 2021 and . - - - -Goldberg, et al. Expires May 12, 2022 [Page 25] - -Internet-Draft VRF November 2021 - - 7. Security Considerations 7.1. Key Generation @@ -1412,10 +1423,11 @@ Internet-Draft VRF November 2021 7.1.1. Uniqueness and collision resistance with untrusted keys The ECVRF as specified in Section 5.1-Section 5.5 satisfies the - "trusted uniqueness" and "trusted collision resistance" properties as - long as the VRF keys are generated correctly, with good randomness. - If the Verifier trusts the VRF keys are generated correctly, it MAY - use the public key Y as is. + "trusted uniqueness" (see Section 3.1) and "trusted collision + resistance" (see Section 3.2) properties as long as the VRF keys are + generated correctly, with good randomness. If the Verifier trusts + the VRF keys are generated correctly, it MAY use the public key Y as + is. However, if the ECVRF uses keys that could be generated adversarially, then the Verifier MUST first perform the validation @@ -1439,6 +1451,13 @@ Internet-Draft VRF November 2021 cryptographic checks that its public key has the right form. These modifications are left for future specification. + + +Goldberg, et al. Expires May 13, 2022 [Page 26] + +Internet-Draft VRF November 2021 + + 7.1.2. Pseudorandomness with untrusted keys Without good randomness, the "pseudorandomness" properties of the VRF @@ -1448,26 +1467,17 @@ Internet-Draft VRF November 2021 generate the VRF keys, and thus, the VRF output may not be pseudorandom. - - - - - -Goldberg, et al. Expires May 12, 2022 [Page 26] - -Internet-Draft VRF November 2021 - - -7.2. Selective vs Full Pseudorandomness +7.2. Selective vs. Full Pseudorandomness [PWHVNRG17] presents cryptographic reductions to an underlying hard problem (e.g. Decisional Diffie-Hellman for the ECVRF, or the standard RSA assumption for RSA-FDH-VRF) that prove the VRFs specified in this document possess full pseudorandomness as well as - selective pseudorandomness. However, the cryptographic reductions - are tighter for selective pseudorandomness than for full - pseudorandomness. This means that the VRFs have quantitively - stronger security guarantees for selective pseudorandomness. + selective pseudorandomness (see Section 3.3 for an explanation of + these notions). However, the cryptographic reductions are tighter + for selective pseudorandomness than for full pseudorandomness. This + means that the VRFs have quantitively stronger security guarantees + for selective pseudorandomness. Applications that are concerned about tightness of cryptographic reductions therefore have two options. @@ -1496,6 +1506,14 @@ Internet-Draft VRF November 2021 specified in the ECVRF ciphersuites of Section 5.5 are designed with this requirement in mind. + + + +Goldberg, et al. Expires May 13, 2022 [Page 27] + +Internet-Draft VRF November 2021 + + 7.4. Side-channel attacks Side channel attacks on cryptographic primitives are an important @@ -1505,15 +1523,6 @@ Internet-Draft VRF November 2021 information about the VRF private key SK (and the nonce k used in the ECVRF). - - - - -Goldberg, et al. Expires May 12, 2022 [Page 27] - -Internet-Draft VRF November 2021 - - The ECVRF_hash_to_curve_try_and_increment algorithm defined in Section 5.4.1.1 SHOULD NOT be used in applications where the VRF input alpha is secret and is hashed by the VRF on-the-fly. This is @@ -1553,6 +1562,14 @@ Internet-Draft VRF November 2021 point H becomes the representative of alpha thereafter. Note that the suite_string octet and the public key are hashed together with alpha in ECVRF_hash_to_curve, which ensures that the curve (including + + + +Goldberg, et al. Expires May 13, 2022 [Page 28] + +Internet-Draft VRF November 2021 + + the generator B) and the public key are included indirectly into subsequent hashes. @@ -1562,14 +1579,6 @@ Internet-Draft VRF November 2021 the RSA-FDH-VRF, in MGF1 and in proof_to_hash; in the ECVRF, in hash_to_curve, nonce_generation, hash_points, and proof_to_hash). The theoretical analysis assumes each of these functions is a - - - -Goldberg, et al. Expires May 12, 2022 [Page 28] - -Internet-Draft VRF November 2021 - - separate random oracle. This analysis still holds even if the same hash function is used, as long as the four queries made to the hash function for a given SK and alpha are overwhelmingly unlikely to @@ -1609,6 +1618,14 @@ Internet-Draft VRF November 2021 For the elliptic curve VRF, if future designs need to specify variants (e.g., additional ciphersuites) of the design in this + + + +Goldberg, et al. Expires May 13, 2022 [Page 29] + +Internet-Draft VRF November 2021 + + document, then, to avoid the possibility that an adversary can obtain a VRF output under one variant, and then claim it was obtained under another variant, they should specify a different suite_string @@ -1618,14 +1635,6 @@ Internet-Draft VRF November 2021 functions used by the prover will also be different as long as hash_to_curve is collision resistant. - - - -Goldberg, et al. Expires May 12, 2022 [Page 29] - -Internet-Draft VRF November 2021 - - 8. Change Log Note to RFC Editor: if this document does not obsolete an existing @@ -1665,6 +1674,14 @@ Internet-Draft VRF November 2021 RSAVRF; made Verify return beta so unverified proofs don't end up in proof_to_hash; added test vectors. + + + +Goldberg, et al. Expires May 13, 2022 [Page 30] + +Internet-Draft VRF November 2021 + + 04 - Clarified handling of optional arguments x and PK in ECVRF_prove. Edited implementation status to bring it up to date. @@ -1674,14 +1691,6 @@ Internet-Draft VRF November 2021 corresponding test vectors for the P256 suites. Added a reference to the Rust implementation. - - - -Goldberg, et al. Expires May 12, 2022 [Page 30] - -Internet-Draft VRF November 2021 - - 06 - Made some variable names more descriptive. Added a few implementation references. @@ -1697,7 +1706,8 @@ Internet-Draft VRF November 2021 publication. 10 - Added a check in ECVRF_decode_proof to ensure that s is - reduced mod q. + reduced mod q. Connected security properties (Section 3) and + security considerations (Section 7) with more cross-references. 9. Contributors @@ -1721,6 +1731,13 @@ Internet-Draft VRF November 2021 . + + +Goldberg, et al. Expires May 13, 2022 [Page 31] + +Internet-Draft VRF November 2021 + + [I-D.irtf-cfrg-hash-to-curve] Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R., and C. Wood, "Hashing to Elliptic Curves", draft-irtf-cfrg- @@ -1731,13 +1748,6 @@ Internet-Draft VRF November 2021 DOI 10.17487/RFC2119, March 1997, . - - -Goldberg, et al. Expires May 12, 2022 [Page 31] - -Internet-Draft VRF November 2021 - - [RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman Groups for Use with IETF Standards", RFC 5114, DOI 10.17487/RFC5114, January 2008, @@ -1774,6 +1784,16 @@ Internet-Draft VRF November 2021 Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI X9.62, 2005. + + + + + +Goldberg, et al. Expires May 13, 2022 [Page 32] + +Internet-Draft VRF November 2021 + + [DGKR18] David, B., Gazi, P., Kiayias, A., and A. Russell, "Ouroboros Praos: An adaptively-secure, semi-synchronous proof-of-stake protocol", in Advances in Cryptology - @@ -1785,15 +1805,6 @@ Internet-Draft VRF November 2021 Operating Systems Principles (SOSP), 2017, . - - - - -Goldberg, et al. Expires May 12, 2022 [Page 32] - -Internet-Draft VRF November 2021 - - [I-D.vcelak-nsec5] Vcelak, J., Goldberg, S., Papadopoulos, D., Huque, S., and D. Lawrence, "NSEC5, DNSSEC Authenticated Denial of @@ -1834,18 +1845,7 @@ Internet-Draft VRF November 2021 - - - - - - - - - - - -Goldberg, et al. Expires May 12, 2022 [Page 33] +Goldberg, et al. Expires May 13, 2022 [Page 33] Internet-Draft VRF November 2021 @@ -1901,7 +1901,7 @@ A.1. ECVRF-P256-SHA256-TAI -Goldberg, et al. Expires May 12, 2022 [Page 34] +Goldberg, et al. Expires May 13, 2022 [Page 34] Internet-Draft VRF November 2021 @@ -1957,7 +1957,7 @@ A.2. ECVRF-P256-SHA256-SSWU -Goldberg, et al. Expires May 12, 2022 [Page 35] +Goldberg, et al. Expires May 13, 2022 [Page 35] Internet-Draft VRF November 2021 @@ -2013,7 +2013,7 @@ Internet-Draft VRF November 2021 -Goldberg, et al. Expires May 12, 2022 [Page 36] +Goldberg, et al. Expires May 13, 2022 [Page 36] Internet-Draft VRF November 2021 @@ -2069,7 +2069,7 @@ A.3. ECVRF-EDWARDS25519-SHA512-TAI -Goldberg, et al. Expires May 12, 2022 [Page 37] +Goldberg, et al. Expires May 13, 2022 [Page 37] Internet-Draft VRF November 2021 @@ -2125,7 +2125,7 @@ A.4. ECVRF-EDWARDS25519-SHA512-ELL2 -Goldberg, et al. Expires May 12, 2022 [Page 38] +Goldberg, et al. Expires May 13, 2022 [Page 38] Internet-Draft VRF November 2021 @@ -2181,7 +2181,7 @@ Internet-Draft VRF November 2021 -Goldberg, et al. Expires May 12, 2022 [Page 39] +Goldberg, et al. Expires May 13, 2022 [Page 39] Internet-Draft VRF November 2021 @@ -2237,4 +2237,4 @@ Authors' Addresses -Goldberg, et al. Expires May 12, 2022 [Page 40] +Goldberg, et al. Expires May 13, 2022 [Page 40] diff --git a/draft-irtf-cfrg-vrf.xml b/draft-irtf-cfrg-vrf.xml index 8ccd8b2..bf31a4d 100644 --- a/draft-irtf-cfrg-vrf.xml +++ b/draft-irtf-cfrg-vrf.xml @@ -231,7 +231,7 @@ -
    +
    Uniqueness means that, for any fixed public VRF key and for any input alpha, there is a unique VRF @@ -251,16 +251,22 @@ - A slightly weaker security - property called "trusted uniqueness" suffices for many applications. - Trusted uniqueness is the same as full uniqueness, but it must hold + For many applications, a slightly weaker security + property called "trusted uniqueness" suffices. + Trusted uniqueness is the same as full uniqueness, but it is guaranteed to hold only if the VRF keys PK and SK were generated in a trustworthy - manner. In other words, uniqueness might not hold if keys were - generated in an invalid manner or with bad randomness. + manner. + + + As further discussed in , + some VRFs specified in this document satisfy only trusted uniqueness, while others satisfy full uniqueness. + VRFs in this document that satisfy only trusted uniqueness but not full uniqueness MUST NOT be used if the key generation + process cannot be trusted. +
    -
    +
    Like any cryptographic hash function, VRFs need to be collision resistant. Collison resistance must hold @@ -275,10 +281,17 @@ - For most applications, a slightly weaker security property + For many applications, a slightly weaker security property called "trusted collision resistance" suffices. Trusted collision resistance is the same as collision resistance, - but it holds only if PK and SK were generated in a trustworthy manner. + but it is guaranteed to hold only if the VRF keys PK and SK were generated in a trustworthy manner. + + + + As further discussed in , + some VRFs specified in this document satisfy only trusted collision resistance, while others satisfy full collision resistance. + VRFs in this document that satisfy only trusted collision resistance but not full collision resistance MUST NOT be used if the key generation + process cannot be trusted.
    @@ -316,6 +329,13 @@ and proofs pi' on inputs alpha' of its choice. + + As further discussed in , + VRFs specified in this document satisfy both full pseudorandomness and selective pseudorandomness, + but their quantitative security against the selective pseudorandomness attack is stronger. + + + It is important to remember that the VRF output beta does not look random to the Prover, or to any other party that knows the private @@ -1357,10 +1377,11 @@ using good randomness. -
    +
    The ECVRF as specified in - - satisfies the "trusted uniqueness" and "trusted collision resistance" properties + satisfies the "trusted uniqueness" (see ) + and "trusted collision resistance" (see ) properties as long as the VRF keys are generated correctly, with good randomness. If the Verifier trusts the VRF keys are generated correctly, it MAY use the public key Y as is. @@ -1406,13 +1427,14 @@ -
    +
    presents cryptographic reductions to an underlying hard problem (e.g. Decisional Diffie-Hellman for the ECVRF, or the standard RSA assumption for RSA-FDH-VRF) that prove the VRFs specified in this document possess full pseudorandomness - as well as selective pseudorandomness. + as well as selective pseudorandomness + (see for an explanation of these notions). However, the cryptographic reductions are tighter for selective pseudorandomness than for full pseudorandomness. This means that the VRFs have quantitively stronger security @@ -1625,7 +1647,7 @@ 07 - Incorporated hash-to-curve draft by reference to replace our own Elligator2 and Simple SWU. Clarified discussion of EC parameters and functions. Added a 0 octet to all hashing to enforce domain separation from hashing done inside hash-to-curve. 08 - Incorporated suggestions from crypto panel review by Chloe Martindale. Changed Reyzin's affiliation. Updated references. 09 - Added a note to remove the implementation page before publication. - 10 - Added a check in ECVRF_decode_proof to ensure that s is reduced mod q. + 10 - Added a check in ECVRF_decode_proof to ensure that s is reduced mod q. Connected security properties (Section 3) and security considerations (Section 7) with more cross-references.