idnits 2.17.1 draft-irtf-cfrg-voprf-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 21 instances of too long lines in the document, the longest one being 12 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 24, 2019) is 1736 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1184 == Outdated reference: A later version (-16) exists of draft-irtf-cfrg-hash-to-curve-04 == Outdated reference: A later version (-06) exists of draft-krawczyk-cfrg-opaque-02 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Davidson 3 Internet-Draft N. Sullivan 4 Intended status: Informational Cloudflare 5 Expires: January 25, 2020 C. Wood 6 Apple Inc. 7 July 24, 2019 9 Oblivious Pseudorandom Functions (OPRFs) using Prime-Order Groups 10 draft-irtf-cfrg-voprf-01 12 Abstract 14 An Oblivious Pseudorandom Function (OPRF) is a two-party protocol for 15 computing the output of a PRF. One party (the server) holds the PRF 16 secret key, and the other (the client) holds the PRF input. The 17 'obliviousness' property ensures that the server does not learn 18 anything about the client's input during the evaluation. The client 19 should also not learn anything about the server's secret PRF key. 20 Optionally, OPRFs can also satisfy a notion 'verifiability' (VOPRF). 21 In this setting, the client can verify that the server's output is 22 indeed the result of evaluating the underlying PRF with just a public 23 key. This document specifies OPRF and VOPRF constructions 24 instantiated within prime-order groups, including elliptic curves. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 25, 2020. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Change log . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 63 1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . 5 64 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Security Properties . . . . . . . . . . . . . . . . . . . . . 6 66 4. OPRF Protocol . . . . . . . . . . . . . . . . . . . . . . . . 7 67 4.1. Protocol correctness . . . . . . . . . . . . . . . . . . 9 68 4.2. Instantiations of GG . . . . . . . . . . . . . . . . . . 9 69 4.3. OPRF algorithms . . . . . . . . . . . . . . . . . . . . . 10 70 4.3.1. OPRF_Setup . . . . . . . . . . . . . . . . . . . . . 10 71 4.3.2. OPRF_Blind . . . . . . . . . . . . . . . . . . . . . 11 72 4.3.3. OPRF_Eval . . . . . . . . . . . . . . . . . . . . . . 11 73 4.3.4. OPRF_Unblind . . . . . . . . . . . . . . . . . . . . 11 74 4.3.5. OPRF_Finalize . . . . . . . . . . . . . . . . . . . . 12 75 4.4. VOPRF algorithms . . . . . . . . . . . . . . . . . . . . 12 76 4.4.1. VOPRF_Setup . . . . . . . . . . . . . . . . . . . . . 13 77 4.4.2. VOPRF_Blind . . . . . . . . . . . . . . . . . . . . . 13 78 4.4.3. VOPRF_Eval . . . . . . . . . . . . . . . . . . . . . 13 79 4.4.4. VOPRF_Unblind . . . . . . . . . . . . . . . . . . . . 14 80 4.4.5. VOPRF_Finalize . . . . . . . . . . . . . . . . . . . 14 81 4.5. Utility algorithms . . . . . . . . . . . . . . . . . . . 15 82 4.5.1. bin2scalar . . . . . . . . . . . . . . . . . . . . . 15 83 4.6. Efficiency gains with pre-processing and fixed-base 84 blinding . . . . . . . . . . . . . . . . . . . . . . . . 15 85 4.6.1. OPRF_Preprocess . . . . . . . . . . . . . . . . . . . 16 86 4.6.2. OPRF_Blind . . . . . . . . . . . . . . . . . . . . . 16 87 4.6.3. OPRF_Unblind . . . . . . . . . . . . . . . . . . . . 17 88 5. NIZK Discrete Logarithm Equality Proof . . . . . . . . . . . 17 89 5.1. DLEQ_Generate . . . . . . . . . . . . . . . . . . . . . . 18 90 5.2. DLEQ_Verify . . . . . . . . . . . . . . . . . . . . . . . 18 91 6. Batched VOPRF evaluation . . . . . . . . . . . . . . . . . . 19 92 6.1. Batched DLEQ algorithms . . . . . . . . . . . . . . . . . 20 93 6.1.1. Batched_DLEQ_Generate . . . . . . . . . . . . . . . . 20 94 6.1.2. Batched_DLEQ_Verify . . . . . . . . . . . . . . . . . 20 95 6.2. Modified protocol execution . . . . . . . . . . . . . . . 21 96 6.3. Random oracle instantiations for proofs . . . . . . . . . 21 97 7. Supported ciphersuites . . . . . . . . . . . . . . . . . . . 22 98 7.1. ECVOPRF-P256-HKDF-SHA256-SSWU: . . . . . . . . . . . . . 22 99 7.2. ECVOPRF-ed25519-HKDF-SHA256-Elligator2: . . . . . . . . . 22 100 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 101 8.1. Timing Leaks . . . . . . . . . . . . . . . . . . . . . . 23 102 8.2. Hashing to curves . . . . . . . . . . . . . . . . . . . . 23 103 8.3. Verifiability (key consistency) . . . . . . . . . . . . . 23 104 9. Applications . . . . . . . . . . . . . . . . . . . . . . . . 24 105 9.1. Privacy Pass . . . . . . . . . . . . . . . . . . . . . . 24 106 9.2. Private Password Checker . . . . . . . . . . . . . . . . 24 107 9.2.1. Parameter Commitments . . . . . . . . . . . . . . . . 25 108 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 109 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 110 11.1. Normative References . . . . . . . . . . . . . . . . . . 25 111 11.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 27 112 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 27 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 115 1. Introduction 117 A pseudorandom function (PRF) F(k, x) is an efficiently computable 118 function with secret key k on input x. Roughly, F is pseudorandom if 119 the output y = F(k, x) is indistinguishable from uniformly sampling 120 any element in F's range for random choice of k. An oblivious PRF 121 (OPRF) is a two-party protocol between a prover P and verifier V 122 where P holds a PRF key k and V holds some input x. The protocol 123 allows both parties to cooperate in computing F(k, x) with P's secret 124 key k and V's input x such that: V learns F(k, x) without learning 125 anything about k; and P does not learn anything about x. A 126 Verifiable OPRF (VOPRF) is an OPRF wherein P can prove to V that F(k, 127 x) was computed using key k, which is bound to a trusted public key Y 128 = kG. Informally, this is done by presenting a non-interactive zero- 129 knowledge (NIZK) proof of equality between (G, Y) and (Z, M), where Z 130 = kM for some point M. 132 OPRFs have been shown to be useful for constructing: password- 133 protected secret sharing schemes [JKK14]; privacy-preserving password 134 stores [SJKS17]; and password-authenticated key exchange or PAKE 135 [OPAQUE]. VOPRFs are useful for producing tokens that are verifiable 136 by V. This may be needed, for example, if V wants assurance that P 137 did not use a unique key in its computation, i.e., if V wants key 138 consistency from P. This property is necessary in some applications, 139 e.g., the Privacy Pass protocol [PrivacyPass], wherein this VOPRF is 140 used to generate one-time authentication tokens to bypass CAPTCHA 141 challenges. VOPRFs have also been used for password-protected secret 142 sharing schemes e.g. [JKKX16]. 144 This document introduces an OPRF protocol built in prime-order 145 groups, applying to finite fields of prime-order and also elliptic 146 curve (EC) settings. The protocol has the option of being extended 147 to a VOPRF with the addition of a NIZK proof for proving discrete log 148 equality relations. This proof demonstrates correctness of the 149 computation using a known public key that serves as a commitment to 150 the server's secret key. In the EC setting, we will refer to the 151 protocol as ECOPRF (or ECVOPRF if verifiability is concerned). The 152 document describes the protocol, its security properties, and 153 provides preliminary test vectors for experimentation. The rest of 154 the document is structured as follows: 156 o Section 2: Describe background, related work, and use cases of 157 OPRF/VOPRF protocols. 159 o Section 3: Discuss security properties of OPRFs/VOPRFs. 161 o Section 4: Specify an authentication protocol from OPRF 162 functionality, based in prime-order groups (with an optional 163 verifiable mode). Algorithms are stated formally for OPRFs in 164 Section 4.3 and for VOPRFs in Section 4.4. 166 o Section 5: Specify the NIZK discrete logarithm equality (DLEQ) 167 construction used for constructing the VOPRF protocol. 169 o Section 6: Specifies how the DLEQ proof mechanism can be batched 170 for multiple VOPRF invocations, and how this changes the protocol 171 execution. 173 o Section 7: Considers explicit instantiations of the protocol in 174 the elliptic curve setting. 176 o Section 8: Discusses the security considerations for the OPRF and 177 VOPRF protocol. 179 o Section 9: Discusses some existing applications of OPRF and VOPRF 180 protocols. 182 o Appendix A: Specifies test vectors for implementations in the 183 elliptic curve setting. 185 1.1. Change log 187 draft-01 [1]: 189 o Updated ciphersuites to be in line with 190 https://tools.ietf.org/html/draft-irtf-cfrg-hash-to-curve-04 192 o Made some necessary modular reductions more explicit 194 1.2. Terminology 196 The following terms are used throughout this document. 198 o PRF: Pseudorandom Function. 200 o OPRF: Oblivious PRF. 202 o VOPRF: Verifiable Oblivious Pseudorandom Function. 204 o ECVOPRF: A VOPRF built on Elliptic Curves. 206 o Verifier (V): Protocol initiator when computing F(k, x). 208 o Prover (P): Holder of secret key k. 210 o NIZK: Non-interactive zero knowledge. 212 o DLEQ: Discrete Logarithm Equality. 214 1.3. Requirements 216 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 217 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 218 document are to be interpreted as described in [RFC2119]. 220 2. Background 222 OPRFs are functionally related to blind signature schemes. In such a 223 scheme, a client can receive signatures on private data, under the 224 signing key of some server. The security properties of such a scheme 225 dictate that the client learns nothing about the signing key, and 226 that the server learns nothing about the data that is signed. One of 227 the more popular blind signature schemes is based on the RSA 228 cryptosystem and is known as Blind RSA [ChaumBlindSignature]. 230 OPRF protocols can thought of as symmetric alternatives to blind 231 signatures. Essentially the client learns y = PRF(k,x) for some 232 input x of their choice, from a server that holds k. Since the 233 security of an OPRF means that x is hidden in the interaction, then 234 the client can later reveal x to the server along with y. 236 The server can verify that y is computed correctly by recomputing the 237 PRF on x using k. In doing so, the client provides knowledge of a 238 'signature' y for their value x. The verification procedure is thus 239 symmetric as it requires knowledge of the key k. This is discussed 240 more in the following section. 242 3. Security Properties 244 The security properties of an OPRF protocol with functionality y = 245 F(k, x) include those of a standard PRF. Specifically: 247 o Pseudorandomness: F is pseudorandom if the output y = F(k,x) on 248 any input x is indistinguishable from uniformly sampling any 249 element in F's range, for a random sampling of k. 251 In other words, for an adversary that can pick inputs x from the 252 domain of F and can evaluate F on (k,x) (without knowledge of 253 randomly sampled k), then the output distribution F(k,x) is 254 indistinguishable from the uniform distribution in the range of F. 256 A consequence of showing that a function is pseudorandom, is that it 257 is necessarily non-malleable (i.e. we cannot compute a new evaluation 258 of F from an existing evaluation). A genuinely random function will 259 be non-malleable with high probability, and so a pseudorandom 260 function must be non-malleable to maintain indistinguishability. 262 An OPRF protocol must also satisfy the following property: 264 o Oblivious: P must learn nothing about V's input or the output of 265 the function. In addition, V must learn nothing about P's private 266 key. 268 Essentially, obliviousness tells us that, even if P learns V's input 269 x at some point in the future, then P will not be able to link any 270 particular OPRF evaluation to x. This property is also known as 271 unlinkability [DGSTV18]. 273 Optionally, for any protocol that satisfies the above properties, 274 there is an additional security property: 276 o Verifiable: V must only complete execution of the protocol if it 277 can successfully assert that the OPRF output computed by V is 278 correct, with respect to the OPRF key held by P. 280 Any OPRF that satisfies the 'verifiable' security property is known 281 as a verifiable OPRF, or VOPRF for short. In practice, the notion of 282 verifiability requires that P commits to the key k before the actual 283 protocol execution takes place. Then V verifies that P has used k in 284 the protocol using this commitment. In the following, we may also 285 refer to this commitment as a public key. 287 4. OPRF Protocol 289 In this section we describe the OPRF protocol. Let GG be an additive 290 group of prime-order p, let GF(p) be the Galois field defined by the 291 integers modulo p. Define distinct hash functions H_1 and H_2, where 292 H_1 maps arbitrary input onto GG and H_2 maps arbitrary input to a 293 fixed-length output, e.g., SHA256. All hash functions in the 294 protocol are modelled as random oracles. Let L be the security 295 parameter. Let k be the prover's (P) secret key, and Y = kG be its 296 corresponding 'public key' for some fixed generator G taken from the 297 description of the group GG. This public key Y is also referred to 298 as a commitment to the OPRF key k, and the pair (G,Y) as a commitment 299 pair. Let x be the verifier's (V) input to the OPRF protocol. 300 (Commonly, it is a random L-bit string, though this is not required.) 302 The OPRF protocol begins with V blinding its input for the OPRF 303 evaluator such that it appears uniformly distributed GG. The latter 304 then applies its secret key to the blinded value and returns the 305 result. To finish the computation, V then removes its blind and 306 hashes the result using H_2 to yield an output. This flow is 307 illustrated below. 309 Verifier Prover 310 ---------------------------------------------------------- 311 r <-$ GF(p) 312 M = rH_1(x) mod p 313 M 314 -------> 315 Z = kM mod p 316 [D = DLEQ_Generate(k,G,Y,M,Z)] 317 Z[,D] 318 <------- 319 [b = DLEQ_Verify(G,Y,M,Z,D)] 320 N = Zr^(-1) mod p 321 Output H_2(x, N) mod p [if b=1, else "error"] 323 Steps that are enclosed in square brackets (DLEQ_Generate and 324 DLEQ_Verify) are optional for achieving verifiability. These are 325 described in Section 5. In the verifiable mode, we assume that P has 326 previously committed to their choice of key k with some values 327 (G,Y=kG) and these are publicly known by V. Notice that revealing 328 (G,Y) does not reveal k by the well-known hardness of the discrete 329 log problem. 331 Strictly speaking, the actual PRF function that is computed is: 333 F(k, x) = N = kH_1(x) 334 It is clear that this is a PRF H_1(x) maps x to a random element in 335 GG, and GG is cyclic. This output is computed when the client 336 computes Zr^(-1) by the commutativity of the multiplication. The 337 client finishes the computation by outputting H_2(x,N). Note that 338 the output from P is not the PRF value because the actual input x is 339 blinded by r. 341 This protocol may be decomposed into a series of steps, as described 342 below: 344 o OPRF_Setup(l): Generate am integer k of sufficient bit-length l 345 and output k. 347 o OPRF_Blind(x): Compute and return a blind, r, and blinded 348 representation of x in GG, denoted M. 350 o OPRF_Eval(k,M,h?): Evaluates on input M using secret key k to 351 produce Z, the input h is optional and equal to the cofactor of an 352 elliptic curve. If h is not provided then it defaults to 1. 354 o OPRF_Unblind(r,Z): Unblind blinded OPRF evaluation Z with blind r, 355 yielding N and output N. 357 o OPRF_Finalize(x,N): Finalize N to produce the output H_2(x, N). 359 For verifiability we modify the algorithms of VOPRF_Setup, VOPRF_Eval 360 and VOPRF_Unblind to be the following: 362 o VOPRF_Setup(l): Generate an integer k of sufficient bit-length l 363 and output (k, (G,Y)) where Y = kG for the fixed generator G of 364 GG. 366 o VOPRF_Eval(k,(G,Y),M,h?): Evaluates on input M using secret key k 367 to produce Z. Generate a NIZK proof D = DLEQ_Generate(k,G,Y,M,Z), 368 and output (Z, D). The optional cofactor h can also be provided, 369 as in OPRF_Eval. 371 o VOPRF_Unblind(r,G,Y,M,(Z,D)): Unblind blinded OPRF evaluation Z 372 with blind r, yielding N. Output N if 1 = DLEQ_Verify(G,Y,M,Z,D). 373 Otherwise, output "error". 375 We leave the rest of the OPRF algorithms unmodified. When referring 376 explicitly to VOPRF execution, we replace 'OPRF' in all method names 377 with 'VOPRF'. 379 4.1. Protocol correctness 381 Protocol correctness requires that, for any key k, input x, and (r, 382 M) = OPRF_Blind(x), it must be true that: 384 OPRF_Finalize(x, OPRF_Unblind(r,M,OPRF_Eval(k,M))) = H_2(x, F(k,x)) 386 with overwhelming probability. Likewise, in the verifiable setting, 387 we require that: 389 VOPRF_Finalize(x, VOPRF_Unblind(r,(G,Y),M,(VOPRF_Eval(k,(G,Y),M)))) = H_2(x, F(k,x)) 391 with overwhelming probability, where (r, M) = VOPRF_Blind(x). 393 4.2. Instantiations of GG 395 As we remarked above, GG is a subgroup with associated prime-order p. 396 While we choose to write operations in the setting where GG comes 397 equipped with an additive operation, we could also define the 398 operations in the multiplicative setting. In the multiplicative 399 setting we can choose GG to be a prime-order subgroup of a finite 400 field FF_p. For example, let p be some large prime (e.g. > 2048 401 bits) where p = 2q+1 for some other prime q. Then the subgroup of 402 squares of FF_p (elements u^2 where u is an element of FF_p) is 403 cyclic, and we can pick a generator of this subgroup by picking G 404 from FF_p (ignoring the identity element). 406 For practicality of the protocol, it is preferable to focus on the 407 cases where GG is an additive subgroup so that we can instantiate the 408 OPRF in the elliptic curve setting. This amounts to choosing GG to 409 be a prime-order subgroup of an elliptic curve over base field GF(p) 410 for prime p. There are also other settings where GG is a prime-order 411 subgroup of an elliptic curve over a base field of non-prime order, 412 these include the work of Ristretto [RISTRETTO] and Decaf [DECAF]. 414 We will use p > 0 generally for constructing the base field GF(p), 415 not just those where p is prime. To reiterate, we focus only on the 416 additive case, and so we focus only on the cases where GF(p) is 417 indeed the base field. 419 Unless otherwise stated, we will always assume that the generator G 420 that we use for the group GG is a fixed generator. This generator 421 should be provided in the description of the group GG. 423 4.3. OPRF algorithms 425 This section provides algorithms for each step in the OPRF protocol. 426 We describe the VOPRF analogues in Section 4.4. We provide generic 427 utility algorithms in Section 4.5. 429 1. P samples a uniformly random key k <- {0,1}^l for sufficient 430 length l, and interprets it as an integer. 432 2. V computes X = H_1(x) and a random element r (blinding factor) 433 from GF(p), and computes M = rX. 435 3. V sends M to P. 437 4. P computes Z = kM = rkX. 439 5. In the elliptic curve setting, P multiplies Z by the cofactor 440 (denoted h) of the elliptic curve. 442 6. P sends Z to V. 444 7. V unblinds Z to compute N = r^(-1)Z = kX. 446 8. V outputs the pair H_2(x, N). 448 We note here that the blinding mechanism that we use can be modified 449 slightly with the opportunity for making performance gains in some 450 scenarios. We detail these modifications in Section Section 4.6. 452 4.3.1. OPRF_Setup 454 Input: 456 l: Some suitable choice of key-length (e.g. as described in [NIST]). 458 Output: 460 k: A key chosen from {0,1}^l and interpreted as an integer value. 462 Steps: 464 1. Sample k_bin <-$ {0,1}^l 465 2. Output k <- bin2scalar(k_bin, l) 467 4.3.2. OPRF_Blind 469 Input: 471 x: V's PRF input. 473 Output: 475 r: Random scalar in [1, p - 1]. 476 M: Blinded representation of x using blind r, an element in GG. 478 Steps: 480 1. r <-$ GF(p) 481 2. M := rH_1(x) 482 3. Output (r, M) 484 4.3.3. OPRF_Eval 486 Input: 488 k: Evaluator secret key. 489 M: An element in GG. 490 h: optional cofactor (defaults to 1). 492 Output: 494 Z: Scalar multiplication of the point M by k, element in GG. 496 Steps: 498 1. Z := kM 499 2. Z <- hZ 500 3. Output Z 502 4.3.4. OPRF_Unblind 503 Input: 505 r: Random scalar in [1, p - 1]. 506 Z: An element in GG. 508 Output: 510 N: Unblinded OPRF evaluation, element in GG. 512 Steps: 514 1. N := (r^(-1))Z 515 2. Output N 517 4.3.5. OPRF_Finalize 519 Input: 521 x: PRF input string. 522 N: An element in GG. 524 Output: 526 y: Random element in {0,1}^L. 528 Steps: 530 1. y := H_2(x, N) 531 2. Output y 533 4.4. VOPRF algorithms 535 The steps in the VOPRF setting are written as: 537 1. P samples a uniformly random key k <- {0,1}^l for sufficient 538 length l, and interprets it as an integer. 540 2. P commits to k by computing (G,Y) for Y=kG, where G is the fixed 541 generator of GG. P makes the pair (G,Y) publicly available. 543 3. V computes X = H_1(x) and a random element r (blinding factor) 544 from GF(p), and computes M = rX. 546 4. V sends M to P. 548 5. P computes Z = kM = rkX, and D = DLEQ_Generate(k,G,Y,M,Z). 550 6. P sends (Z, D) to V. 552 7. V ensures that 1 = DLEQ_Verify(G,Y,M,Z,D). If not, V outputs an 553 error. 555 8. V unblinds Z to compute N = r^(-1)Z = kX. 557 9. V outputs the pair H_2(x, N). 559 4.4.1. VOPRF_Setup 561 Input: 563 G: Public fixed generator of GG. 564 l: Some suitable choice of key-length (e.g. as described in [NIST]). 566 Output: 568 k: A key chosen from {0,1}^l and interpreted as an integer value. 569 (G,Y): A pair of curve points, where Y=kG. 571 Steps: 573 1. k <- OPRF_Setup(l) 574 2. Y := kG 575 3. Output (k, (G,Y)) 577 4.4.2. VOPRF_Blind 579 Input: 581 x: V's PRF input. 583 Output: 585 r: Random scalar in [1, p - 1]. 586 M: Blinded representation of x using blind r, an element in GG. 588 Steps: 590 1. r <-$ GF(p) 591 2. M := rH_1(x) 592 3. Output (r, M) 594 4.4.3. VOPRF_Eval 595 Input: 597 k: Evaluator secret key. 598 G: Public fixed generator of group GG. 599 Y: Evaluator public key (= kG). 600 M: An element in GG. 601 h: optional cofactor (defaults to 1). 603 Output: 605 Z: Scalar multiplication of the point M by k, element in GG. 606 D: DLEQ proof that log_G(Y) == log_M(Z). 608 Steps: 610 1. Z := kM 611 2. Z <- hZ 612 3. D = DLEQ_Generate(k,G,Y,M,Z) 613 4. Output (Z, D) 615 4.4.4. VOPRF_Unblind 617 Input: 619 r: Random scalar in [1, p - 1]. 620 G: Public fixed generator of group GG. 621 Y: Evaluator public key. 622 M: Blinded representation of x using blind r, an element in GG. 623 Z: An element in GG. 624 D: D = DLEQ_Generate(k,G,Y,M,Z). 626 Output: 628 N: Unblinded OPRF evaluation, element in GG. 630 Steps: 632 1. N := (r^(-1))Z 633 2. If 1 = DLEQ_Verify(G,Y,M,Z,D), output N 634 3. Output "error" 636 4.4.5. VOPRF_Finalize 637 Input: 639 x: PRF input string. 640 N: An element in GG, or "error". 642 Output: 644 y: Random element in {0,1}^L, or "error" 646 Steps: 648 1. If N == "error", output "error". 649 2. y := H_2(x, N) 650 3. Output y 652 4.5. Utility algorithms 654 4.5.1. bin2scalar 656 This algorithm converts a binary string to an integer modulo p. 658 Input: 660 s: binary string (little-endian) 661 l: length of binary string 662 p: modulus 664 Output: 666 z: An integer modulo p 668 Steps: 670 1. sVec <- vec(s) (converts s to a column vector of dimension l) 671 2. p2Vec <- (2^0, 2^1, ..., 2^{l-1}) (row vector of dimension l) 672 3. z <- p2Vec * sVec (mod p) 673 4. Output z 675 4.6. Efficiency gains with pre-processing and fixed-base blinding 677 In Section Section 4.3 we assume that the client-side blinding is 678 carried out directly on the output of H_1(x), i.e. computing rH_1(x) 679 for some r <-$ GF(p). In the [OPAQUE] draft, it is noted that it may 680 be more efficient to use additive blinding rather than multiplicative 681 if the client can preprocess some values. For example, a valid way 682 of computing additive blinding would be to instead compute H_1(x)+rG, 683 where G is the fixed generator for the group GG. 685 We refer to the 'multiplicative' blinding as variable-base blinding 686 (VBB), since the base of the blinding (H_1(x)) varies with each 687 instantiation. We refer to the additive blinding case as fixed-base 688 blinding (FBB) since the blinding is applied to the same generator 689 each time (when computing rG). 691 By pre-processing tables of blinded scalar multiplications for the 692 specific choice of G it is possible to gain a computational 693 advantage. Choosing one of these values rG (where r is the scalar 694 value that is used), then computing H_1(x)+rG is more efficient than 695 computing rH_1(x) (one addition against log_2(r)). Therefore, it may 696 be advantageous to define the OPRF and VOPRF protocols using additive 697 blinding rather than multiplicative blinding. In fact, the only 698 algorithms that need to change are OPRF_Blind and OPRF_Unblind (and 699 similarly for the VOPRF variants). 701 We define the FBB variants of the algorithms in Section 4.3 below 702 along with a new algorithm OPRF_Preprocess that defines how 703 preprocessing is carried out. The equivalent algorithms for VOPRF 704 are almost identical and so we do not redefine them here. Notice 705 that the only computation that changes is for V, the necessary 706 computation of P does not change. 708 4.6.1. OPRF_Preprocess 710 Input: 712 G: Public fixed generator of GG 714 Output: 716 r: Random scalar in [1, p-1] 717 rG: An element in GG. 718 rY: An element in GG. 720 Steps: 722 1. r <-$ GF(p) 723 2. Output (r, rG, rY) 725 4.6.2. OPRF_Blind 726 Input: 728 x: V's PRF input. 729 rG: Preprocessed element of GG. 731 Output: 733 M: Blinded representation of x using blind r, an element in GG. 735 Steps: 737 1. M := H_1(x)+rG 738 2. Output M 740 4.6.3. OPRF_Unblind 742 Input: 744 rY: Preprocessed element of GG. 745 M: Blinded representation of x using rG, an element in GG. 746 Z: An element in GG. 748 Output: 750 N: Unblinded OPRF evaluation, element in GG. 752 Steps: 754 1. N := Z-rY 755 2. Output N 757 Notice that OPRF_Unblind computes (Z-rY) = k(H_1(x)+rG) - rkG = 758 kH_1(x) by the commutativity of scalar multiplication in GG. This is 759 the same output as in the original OPRF_Unblind algorithm. 761 5. NIZK Discrete Logarithm Equality Proof 763 For the VOPRF protocol we require that V is able to verify that P has 764 used its private key k to evaluate the PRF. We can do this by 765 showing that the original commitment (G,Y) output by VOPRF_Setup(l) 766 satisfies log_G(Y) == log_M(Z) where Z is the output of 767 VOPRF_Eval(k,(G,Y),M). 769 This may be used, for example, to ensure that P uses the same private 770 key for computing the VOPRF output and does not attempt to "tag" 771 individual verifiers with select keys. This proof must not reveal 772 the P's long-term private key to V. 774 Consequently, this allows extending the OPRF protocol with a (non- 775 interactive) discrete logarithm equality (DLEQ) algorithm built on a 776 Chaum-Pedersen [ChaumPedersen] proof. This proof is divided into two 777 procedures: DLEQ_Generate and DLEQ_Verify. These are specified 778 below. 780 5.1. DLEQ_Generate 782 Input: 784 k: Evaluator secret key. 785 G: Public fixed generator of GG. 786 Y: Evaluator public key (= kG). 787 M: An element in GG. 788 Z: An element in GG. 789 H_3: A hash function from GG to {0,1}^L, modelled as a random oracle. 791 Output: 793 D: DLEQ proof (c, s). 795 Steps: 797 1. r <-$ GF(p) 798 2. A := rG and B := rM 799 3. c <- H_3(G,Y,M,Z,A,B) (mod p) 800 4. s := (r - ck) (mod p) 801 5. Output D := (c, s) 803 We note here that it is essential that a different r value is used 804 for every invocation. If this is not done, then this may leak the 805 key k in a similar fashion as is possible in Schnorr or (EC)DSA 806 scenarios where fresh randomness is not used. 808 5.2. DLEQ_Verify 809 Input: 811 G: Public fixed generator of GG. 812 Y: Evaluator public key. 813 M: An element in GG. 814 Z: An element in GG. 815 D: DLEQ proof (c, s). 817 Output: 819 True if log_G(Y) == log_M(Z), False otherwise. 821 Steps: 823 1. A' := (sG + cY) 824 2. B' := (sM + cZ) 825 3. c' <- H_3(G,Y,M,Z,A',B') (mod p) 826 4. Output c == c' (mod p) 828 6. Batched VOPRF evaluation 830 Common applications (e.g. [PrivacyPass]) require V to obtain 831 multiple PRF evaluations from P. In the VOPRF case, this would also 832 require generation and verification of a DLEQ proof for each Zi 833 received by V. This is costly, both in terms of computation and 834 communication. To get around this, applications use a 'batching' 835 procedure for generating and verifying DLEQ proofs for a finite 836 number of PRF evaluation pairs (Mi,Zi). For n PRF evaluations: 838 o Proof generation is slightly more expensive from 2n modular 839 exponentiations to 2n+2. 841 o Proof verification is much more efficient, from 4n modular 842 exponentiations to 2n+4. 844 o Communications falls from 2n to 2 group elements. 846 Therefore, since P is usually a powerful server, we can tolerate a 847 slight increase in proof generation complexity for much more 848 efficient communication and proof verification. 850 In this section, we describe algorithms for batching the DLEQ 851 generation and verification procedure. For these algorithms we 852 require an additional random oracle H_5: {0,1}^a x ZZ^3 -> {0,1}^b 853 that takes an inputs of a binary string of length a and three integer 854 values, and outputs an element in {0,1}^b. 856 6.1. Batched DLEQ algorithms 858 6.1.1. Batched_DLEQ_Generate 860 Input: 862 k: Evaluator secret key. 863 G: Public fixed generator of group GG. 864 Y: Evaluator public key (= kG). 865 n: Number of PRF evaluations. 866 [ Mi ]: An array of points in GG of length n. 867 [ Zi ]: An array of points in GG of length n. 868 H_4: A hash function from GG^(2n+2) to {0,1}^a, modelled as a random oracle. 869 H_5: A hash function from {0,1}^a x ZZ^2 to {0,1}^b, modelled as a random oracle. 870 label: An integer label value for the splitting the domain of H_5 872 Output: 874 D: DLEQ proof (c, s). 876 Steps: 878 1. seed <- H_4(G,Y,[Mi,Zi])) 879 2. for i in [n]: di <- H_5(seed,i,label) 880 3. c1,...,cn := (int)d1,...,(int)dn 881 4. M := c1M1 + ... + cnMn 882 5. Z := c1Z1 + ... + cnZn 883 6. Output D <- DLEQ_Generate(k,G,Y,M,Z) 885 6.1.2. Batched_DLEQ_Verify 886 Input: 888 G: Public fixed generator of group GG. 889 Y: Evaluator public key. 890 [ Mi ]: An array of points in GG of length n. 891 [ Zi ]: An array of points in GG of length n. 892 D: DLEQ proof (c, s). 894 Output: 896 True if log_G(Y) == log_(Mi)(Zi) for each i in 1...n, False otherwise. 898 Steps: 900 1. seed <- H_4(G,Y,[Mi,Zi])) 901 2. for i in [n]: di <- H_5(seed,i,info) 902 3. c1,...,cn := (int)d1,...,(int)dn 903 4. M := c1M1 + ... + cnMn 904 5. Z := c1Z1 + ... + cnZn 905 6. Output DLEQ_Verify(G,Y,M,Z,D) 907 6.2. Modified protocol execution 909 The VOPRF protocol from Section Section 4 changes to allow specifying 910 multiple blinded PRF inputs [ Mi ] for i in 1...n. P computes the 911 array [ Zi ] and replaces DLEQ_Generate with Batched_DLEQ_Generate 912 over these arrays. The same applies to the algorithm VOPRF_Eval. 913 The same applies for replacing DLEQ_Verify with Batched_DLEQ_Verify 914 when V verifies the response from P and during the algorithm 915 VOPRF_Verify. 917 6.3. Random oracle instantiations for proofs 919 We can instantiate the random oracle function H_4 using the same hash 920 function that is used for H_1,H_2,H_3. For H_5, we can also use a 921 similar instantiation, or we can use a variable-length output 922 generator. For example, for groups with an order of 256-bit, valid 923 instantiations include functions such as SHAKE-256 [SHAKE] or HKDF- 924 Expand-SHA256 [RFC5869]. 926 In addition if a function with larger output than the order of the 927 base field is used, we note that the outputs of H_5 (d1,...,dn) must 928 be smaller than this order. If any di that is sampled is larger than 929 then order, then we should resample until a di' is sampled that is 930 valid. 932 In these cases, the iterating integer i is increased monotonically to 933 i' until such di' is sampled. When sampling the next value d(i+1), 934 the counter i+1 is started at i'+1. 936 TODO: Give a more detailed specification of this construction. 938 7. Supported ciphersuites 940 This section specifies supported ECVOPRF group and hash function 941 instantiations. We only provide ciphersuites in the EC setting as 942 these provide the most efficient way of instantiating the OPRF. Our 943 instantiation includes considerations for providing the DLEQ proofs 944 that make the instantiation a VOPRF. Supporting OPRF operations 945 (ECOPRF) alone can be allowed by simply dropping the relevant 946 components. In addition, we currently only support ciphersuites 947 demonstrating 128 bits of security. 949 7.1. ECVOPRF-P256-HKDF-SHA256-SSWU: 951 o GG: secp256r1 [SEC2] 953 o H_1: P256-SHA256-SSWU-RO [I-D.irtf-cfrg-hash-to-curve] 955 * label: voprf_h2c 957 o H_2: SHA256 959 o H_3: SHA256 961 o H_4: SHA256 963 o H_5: HKDF-Expand-SHA256 965 7.2. ECVOPRF-ed25519-HKDF-SHA256-Elligator2: 967 o GG: Ristretto255 [RISTRETTO] 969 o H_1: edwards25519-SHA256-EDELL2-RO [I-D.irtf-cfrg-hash-to-curve] 971 * label: voprf_h2c 973 o H_2: SHA256 975 o H_3: SHA256 977 o H_4: SHA256 979 o H_5: HKDF-Expand-SHA256 980 In the case of Ristretto, internal point representations are 981 represented by Ed25519 [RFC7748] points. As a result, we can use the 982 same hash-to-curve encoding as we would use for Ed25519 983 [I-D.irtf-cfrg-hash-to-curve]. We remark that the 'label' field is 984 necessary for domain separation of the hash-to-curve functionality. 986 8. Security Considerations 988 Security of the protocol depends on P's secrecy of k. Best practices 989 recommend P regularly rotate k so as to keep its window of compromise 990 small. Moreover, if each key should be generated from a source of 991 safe, cryptographic randomness. 993 A critical aspect of this protocol is reliance on 994 [I-D.irtf-cfrg-hash-to-curve] for mapping arbitrary inputs x to 995 points on a curve. Security requires this mapping be pre-image and 996 collision resistant. 998 8.1. Timing Leaks 1000 To ensure no information is leaked during protocol execution, all 1001 operations that use secret data MUST be constant time. Operations 1002 that SHOULD be constant time include: H_1() (hashing arbitrary 1003 strings to curves) and DLEQ_Generate(). 1004 [I-D.irtf-cfrg-hash-to-curve] describes various algorithms for 1005 constant-time implementations of H_1. 1007 8.2. Hashing to curves 1009 We choose different encodings in relation to the elliptic curve that 1010 is used, all methods are illuminated precisely in 1011 [I-D.irtf-cfrg-hash-to-curve]. In summary, we use the simplified 1012 Shallue-Woestijne-Ulas algorithm for hashing binary strings to the 1013 P-256 curve; the Icart algorithm for hashing binary strings to P384; 1014 the Elligator2 algorithm for hashing binary strings to CURVE25519 and 1015 CURVE448. 1017 8.3. Verifiability (key consistency) 1019 DLEQ proofs are essential to the protocol to allow V to check that 1020 P's designated private key was used in the computation. A side 1021 effect of this property is that it prevents P from using a unique key 1022 for select verifiers as a way of "tagging" them. If all verifiers 1023 expect use of a certain private key, e.g., by locating P's public key 1024 published from a trusted registry, then P cannot present unique keys 1025 to an individual verifier. 1027 For this side effect to hold, P must also be prevented from using 1028 other techniques to manipulate their public key within the trusted 1029 registry to reduce client anonymity. For example, if P's public key 1030 is rotated too frequently then this may stratify the user base into 1031 small anonymity groups (those with VOPRF_Eval outputs taken from a 1032 given key epoch). In this case, it may become practical to link 1033 VOPRF sessions for a given user and thus compromise their privacy. 1035 Similarly, if P can publish N public keys to a trusted registry then 1036 P may be able to control presentation of these keys in such a way 1037 that V is retroactively identified by V's key choice across multiple 1038 requests. 1040 9. Applications 1042 This section describes various applications of the VOPRF protocol. 1044 9.1. Privacy Pass 1046 This VOPRF protocol is used by the Privacy Pass system [PrivacyPass] 1047 to help Tor users bypass CAPTCHA challenges. Their system works as 1048 follows. Client C connects - through Tor - to an edge server E 1049 serving content. Upon receipt, E serves a CAPTCHA to C, who then 1050 solves the CAPTCHA and supplies, in response, n blinded points. E 1051 verifies the CAPTCHA response and, if valid, signs (at most) n 1052 blinded points, which are then returned to C along with a batched 1053 DLEQ proof. C stores the tokens if the batched proof verifies 1054 correctly. When C attempts to connect to E again and is prompted 1055 with a CAPTCHA, C uses one of the unblinded and signed points, or 1056 tokens, to derive a shared symmetric key sk used to MAC the CAPTCHA 1057 challenge. C sends the CAPTCHA, MAC, and token input x to E, who can 1058 use x to derive sk and verify the CAPTCHA MAC. Thus, each token is 1059 used at most once by the system. 1061 The Privacy Pass implementation uses the P-256 instantiation of the 1062 VOPRF protocol. For more details, see [DGSTV18]. 1064 9.2. Private Password Checker 1066 In this application, let D be a collection of plaintext passwords 1067 obtained by prover P. For each password p in D, P computes 1068 VOPRF_Eval on H_1(p), where H_1 is as described above, and stores the 1069 result in a separate collection D'. P then publishes D' with Y, its 1070 public key. If a client C wishes to query D' for a password p', it 1071 runs the VOPRF protocol using p as input x to obtain output y. By 1072 construction, y will be the OPRF evaluation of p hashed onto the 1073 curve. C can then search D' for y to determine if there is a match. 1075 Concrete examples of important applications in the password domain 1076 include: 1078 o password-protected storage [JKK14], [JKKX16]; 1080 o perfectly-hiding password management [SJKS17]; 1082 o password-protected secret-sharing [JKKX17]. 1084 9.2.1. Parameter Commitments 1086 For some applications, it may be desirable for P to bind tokens to 1087 certain parameters, e.g., protocol versions, ciphersuites, etc. To 1088 accomplish this, P should use a distinct scalar for each parameter 1089 combination. Upon redemption of a token T from V, P can later verify 1090 that T was generated using the scalar associated with the 1091 corresponding parameters. 1093 10. Acknowledgements 1095 This document resulted from the work of the Privacy Pass team 1096 [PrivacyPass]. The authors would also like to acknowledge the 1097 helpful conversations with Hugo Krawczyk. Eli-Shaoul Khedouri 1098 provided additional review and comments on key consistency. 1100 11. References 1102 11.1. Normative References 1104 [ChaumBlindSignature] 1105 "Blind Signatures for Untraceable Payments", n.d., 1106 . 1109 [ChaumPedersen] 1110 "Wallet Databases with Observers", n.d., 1111 . 1113 [DECAF] "Decaf, Eliminating cofactors through point compression", 1114 n.d., . 1116 [DGSTV18] "Privacy Pass, Bypassing Internet Challenges Anonymously", 1117 n.d., . 1121 [I-D.irtf-cfrg-hash-to-curve] 1122 Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R., and 1123 C. Wood, "Hashing to Elliptic Curves", draft-irtf-cfrg- 1124 hash-to-curve-04 (work in progress), July 2019. 1126 [JKK14] "Round-Optimal Password-Protected Secret Sharing and 1127 T-PAKE in the Password-Only model", n.d., 1128 . 1130 [JKKX16] "Highly-Efficient and Composable Password-Protected Secret 1131 Sharing (Or, How to Protect Your Bitcoin Wallet Online)", 1132 n.d., . 1134 [JKKX17] "TOPPSS: Cost-minimal Password-Protected Secret Sharing 1135 based on Threshold OPRF", n.d., 1136 . 1138 [NIST] "Keylength - NIST Report on Cryptographic Key Length and 1139 Cryptoperiod (2016)", n.d., 1140 . 1142 [OPAQUE] "The OPAQUE Asymmetric PAKE Protocol", n.d., 1143 . 1146 [PrivacyPass] 1147 "Privacy Pass", n.d., 1148 . 1150 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1151 Requirement Levels", BCP 14, RFC 2119, 1152 DOI 10.17487/RFC2119, March 1997, 1153 . 1155 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1156 Key Derivation Function (HKDF)", RFC 5869, 1157 DOI 10.17487/RFC5869, May 2010, 1158 . 1160 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1161 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1162 2016, . 1164 [RISTRETTO] 1165 "The ristretto255 Group", n.d., 1166 . 1169 [SEC2] Standards for Efficient Cryptography Group (SECG), ., "SEC 1170 2: Recommended Elliptic Curve Domain Parameters", n.d., 1171 . 1173 [SHAKE] "SHA-3 Standard, Permutation-Based Hash and Extendable- 1174 Output Functions", n.d., 1175 . 1179 [SJKS17] "SPHINX, A Password Store that Perfectly Hides from 1180 Itself", n.d., . 1182 11.2. URIs 1184 [1] https://tools.ietf.org/html/draft-irtf-cfrg-voprf-00 1186 Appendix A. Test Vectors 1188 This section includes test vectors for the ECVOPRF-P256-HKDF-SHA256 1189 VOPRF ciphersuite, including batched DLEQ output. 1191 P-256 1192 X: 04b14b08f954f5b6ab1d014b1398f03881d70842acdf06194eb96a6d08186f8cb985c1c5521 \ 1193 f4ee19e290745331f7eb89a4053de0673dc8ef14cfe9bf8226c6b31 1194 r: b72265c85b1ba42cfed7caaf00d2ccac0b1a99259ba0dbb5a1fc2941526a6849 1195 M: 046025a41f81a160c648cfe8fdcaa42e5f7da7a71055f8e23f1dc7e4204ab84b705043ba5c7 \ 1196 000123e1fd058150a4d3797008f57a8b2537766d9419c7396ba5279 1197 k: f84e197c8b712cdf452d2cff52dec1bd96220ed7b9a6f66ed28c67503ae62133 1198 Z: 043ab5ccb690d844dcb780b2d9e59126d62bc853ba01b2c339ba1c1b78c03e4b6adc5402f77 \ 1199 9fc29f639edc138012f0e61960e1784973b37f864e4dc8abbc68e0b 1200 N: 04e8aa6792d859075821e2fba28500d6974ba776fe230ba47ef7e42be1d967654ce776f889e \ 1201 e1f374ffa0bce904408aaa4ed8a19c6cc7801022b7848031f4e442a 1202 D: { s: faddfaf6b5d6b4b6357adf856fc1e0044614ebf9dafdb4c6541c1c9e61243c5b, 1203 c: 8b403e170b56c915cc18864b3ab3c2502bd8f5ca25301bc03ab5138343040c7b } 1205 P-256 1206 X: 047e8d567e854e6bdc95727d48b40cbb5569299e0a4e339b6d707b2da3508eb6c238d3d4cb4 \ 1207 68afc6ffc82fccbda8051478d1d2c9b21ffdfd628506c873ebb1249 1208 r: f222dfe530fdbfcb02eb851867bfa8a6da1664dfc7cee4a51eb6ff83c901e15e 1209 M: 04e2efdc73747e15e38b7a1bb90fe5e4ef964b3b8dccfda428f85a431420c84efca02f0f09c \ 1210 83a8241b44572a059ab49c080a39d0bce2d5d0b44ff5d012b5184e7 1211 k: fb164de0a87e601fd4435c0d7441ff822b5fa5975d0c68035beac05a82c41118 1212 Z: 049d01e1c555bd3324e8ce93a13946b98bdcc765298e6d60808f93c00bdfba2ebf48eef8f28 \ 1213 d8c91c903ad6bea3d840f3b9631424a6cc543a0a0e1f2d487192d5b 1214 N: 04723880e480b60b4415ca627585d1715ab5965570d30c94391a8b023f8854ac26f76c1d6ab \ 1215 bb38688a5affbcadad50ecbf7c93ef33ddfd735003b5a4b1a21ba14 1216 D: { s: dfdf6ae40d141b61d5b2d72cf39c4a6c88db6ac5b12044a70c212e2bf80255b4, 1217 c: 271979a6b51d5f71719127102621fe250e3235867cfcf8dea749c3e253b81997 } 1219 Batched DLEQ (P256) 1220 M_0: 046025a41f81a160c648cfe8fdcaa42e5f7da7a71055f8e23f1dc7e4204ab84b705043ba5c\ 1221 7000123e1fd058150a4d3797008f57a8b2537766d9419c7396ba5279 1222 M_1: 04e2efdc73747e15e38b7a1bb90fe5e4ef964b3b8dccfda428f85a431420c84efca02f0f09\ 1223 c83a8241b44572a059ab49c080a39d0bce2d5d0b44ff5d012b5184e7 1224 Z_0: 043ab5ccb690d844dcb780b2d9e59126d62bc853ba01b2c339ba1c1b78c03e4b6adc5402f7\ 1225 79fc29f639edc138012f0e61960e1784973b37f864e4dc8abbc68e0b 1226 Z_1: 04647e1ab7946b10c1c1c92dd333e2fc9e93e85fdef5939bf2f376ae859248513e0cd91115\ 1227 e48c6852d8dd173956aec7a81401c3f63a133934898d177f2a237eeb 1228 k: f84e197c8b712cdf452d2cff52dec1bd96220ed7b9a6f66ed28c67503ae62133 1229 H_5: HKDF-Expand-SHA256 1230 label: "DLEQ_PROOF" 1231 D: { s: b2123044e633d4721894d573decebc9366869fe3c6b4b79a00311ecfa46c9e34, 1232 c: 3506df9008e60130fcddf86fdb02cbfe4ceb88ff73f66953b1606f6603309862 } 1234 Authors' Addresses 1235 Alex Davidson 1236 Cloudflare 1237 County Hall 1238 London, SE1 7GP 1239 United Kingdom 1241 Email: adavidson@cloudflare.com 1243 Nick Sullivan 1244 Cloudflare 1245 101 Townsend St 1246 San Francisco 1247 United States of America 1249 Email: nick@cloudflare.com 1251 Christopher A. Wood 1252 Apple Inc. 1253 One Apple Park Way 1254 Cupertino, California 95014 1255 United States of America 1257 Email: cawood@apple.com