idnits 2.17.1 draft-irtf-cfrg-rsa-blind-signatures-03.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 abstract seems to contain references ([Chaum83], [RFC8017]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (2 February 2022) is 813 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) == Outdated reference: A later version (-05) exists of draft-irtf-cfrg-bls-signature-04 == Outdated reference: A later version (-21) exists of draft-irtf-cfrg-voprf-08 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Denis 3 Internet-Draft Fastly Inc. 4 Intended status: Informational F. Jacobs 5 Expires: 6 August 2022 Apple Inc. 6 C.A. Wood 7 Cloudflare 8 2 February 2022 10 RSA Blind Signatures 11 draft-irtf-cfrg-rsa-blind-signatures-03 13 Abstract 15 This document specifies the RSA-based blind signature protocol with 16 appendix (RSA-BSSA). RSA blind signatures were first introduced by 17 Chaum for untraceable payments [Chaum83]. It extends RSA-PSS 18 encoding specified in [RFC8017] to enable blind signature support. 20 Discussion Venues 22 This note is to be removed before publishing as an RFC. 24 Source for this draft and an issue tracker can be found at 25 https://github.com/chris-wood/draft-wood-cfrg-blind-signatures. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 6 August 2022. 44 Copyright Notice 46 Copyright (c) 2022 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 62 3. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Blind Signature Protocol Overview . . . . . . . . . . . . . . 4 64 5. RSABSSA Signature Instantiation . . . . . . . . . . . . . . . 4 65 5.1. Signature Generation . . . . . . . . . . . . . . . . . . 4 66 5.1.1. Blind . . . . . . . . . . . . . . . . . . . . . . . . 5 67 5.1.2. BlindSign . . . . . . . . . . . . . . . . . . . . . . 6 68 5.1.3. Finalize . . . . . . . . . . . . . . . . . . . . . . 6 69 5.2. Encoding Options . . . . . . . . . . . . . . . . . . . . 7 70 6. Public Key Certification . . . . . . . . . . . . . . . . . . 8 71 7. Implementation Considerations . . . . . . . . . . . . . . . . 8 72 7.1. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 7.2. API Considerations . . . . . . . . . . . . . . . . . . . 8 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 8.1. Timing Side Channels . . . . . . . . . . . . . . . . . . 9 76 8.2. Message Robustness . . . . . . . . . . . . . . . . . . . 9 77 8.3. Randomized and Deterministic Signatures . . . . . . . . . 10 78 8.4. Key Substitution Attacks . . . . . . . . . . . . . . . . 10 79 8.5. Alternative RSA Encoding Functions . . . . . . . . . . . 10 80 8.6. Alternative Blind Signature Protocols . . . . . . . . . . 11 81 8.7. Post-Quantum Readiness . . . . . . . . . . . . . . . . . 12 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 85 10.2. Informative References . . . . . . . . . . . . . . . . . 13 86 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 16 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 89 1. Introduction 91 Originally introduced in the context of digital cash systems by Chaum 92 for untraceable payments [Chaum83], RSA blind signatures turned out 93 to have a wide range of applications ranging from electric voting 94 schemes to authentication mechanisms. 96 Recently, interest in blind signatures has grown to address 97 operational shortcomings from VOPRFs such as [I-D.irtf-cfrg-voprf]. 98 Specifically, VOPRF evaluation requires access to the private key, 99 and is therefore required for both issuance and redemption of tokens 100 in anonymous authentication protocols such as Privacy Pass 101 [I-D.davidson-pp-protocol]. This limitation complicates deployments 102 where it is not desirable to distribute secret keys to entities 103 performing token verification. Additionally, if the private key is 104 kept in a Hardware Security Module, the number of operations on the 105 key is doubled compared to a scheme where the private key is only 106 required for issuance of the tokens. 108 In contrast, cryptographic signatures provide a primitive that is 109 publicly verifiable and does not require access to the private key 110 for verification. Moreover, [JKK14] shows that one can realize a 111 VOPRF in the Random Oracle Model by hashing a (deterministic) blind 112 signature-message pair. 114 This document specifies a protocol for the RSA Blind Signature Scheme 115 with Appendix (RSABSSA). In order to facilitate deployment, we 116 define it in such a way that the resulting (unblinded) signature can 117 be verified with a standard RSA-PSS library. 119 2. Requirements Notation 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in 124 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 125 capitals, as shown here. 127 3. Notation 129 The following terms are used throughout this document to describe the 130 protocol operations in this document: 132 * bytes_to_int and int_to_bytes: Convert a byte string to and from a 133 non-negative integer. bytes_to_int and int_to_bytes are 134 implemented as OS2IP and I2OSP as described in [RFC8017], 135 respectively. Note that these functions operate on byte strings 136 in big-endian byte order. 138 * random_integer_uniform(M, N): Generate a random, uniformly 139 distributed integer R such that M <= R < N. 141 * inverse_mod(x, n): Compute the multiplicative inverse of x mod n. 142 This function fails if x and n are not co-prime. 144 * len(s): The length of a byte string, in octets. 146 4. Blind Signature Protocol Overview 148 In this section, we sketch the blind signature protocol wherein a 149 client and server interact to compute sig = Sign(skS, msg), where msg 150 is the private message to be signed, and skS is the server's private 151 key. In this protocol, the server learns nothing of msg, whereas the 152 client learns sig and nothing of skS. 154 The core issuance protocol runs as follows: 156 Client(pkS, msg) Server(skS, pkS) 157 ------------------------------------------------------- 158 blinded_msg, inv = Blind(pkS, msg) 160 blinded_msg 161 ----------> 163 blind_sig = BlindSign(skS, blinded_msg) 165 blind_sig 166 <---------- 168 sig = Finalize(pkS, msg, blind_sig, inv) 170 Upon completion, correctness requires that clients can verify 171 signature sig over private input message msg using the server public 172 key pkS by invoking the RSASSA-PSS-VERIFY routine defined in 173 [RFC3447]. The finalization function performs that check before 174 returning the signature. 176 5. RSABSSA Signature Instantiation 178 Section 8.1 of [RFC8017] defines RSASSA-PSS RSAE, which is a 179 signature algorithm using RSASSA-PSS [RFC8017] with mask generation 180 function 1. In this section, we define RSABSSA, a blinded variant of 181 this algorithm. 183 5.1. Signature Generation 185 As outlined in Section 4, signature generation involves three 186 subroutines: Blind, BlindSign, and Finalize. The output from 187 Finalize is a signature over the input to Blind. A specification of 188 these subroutines is below. 190 5.1.1. Blind 192 rsabssa_blind encodes an input message and blinds it with the 193 server's public key. It outputs the blinded message to be sent to 194 the server and the corresponding inverse, both encoded as octet 195 strings. RSAVP1 and EMSA-PSS-ENCODE are as defined in [RFC3447]. 197 rsabssa_blind(pkS, msg) 199 Parameters: 200 - kLen, the length in octets of the RSA modulus n 201 - kBits, the length in bits of the RSA modulus n 202 - HF, the hash function used to hash the message 203 - MGF, the mask generation function 205 Inputs: 206 - pkS, server public key (n, e) 207 - msg, message to be signed, an octet string 209 Outputs: 210 - blinded_msg, an octet string of length kLen 211 - inv, an octet string of length kLen 213 Errors: 214 - "message too long": Raised when the input message is too long. 215 - "encoding error": Raised when the input message fails encoding. 216 - "invalid blind": Raised when the inverse of r cannot be found. 218 Steps: 219 1. encoded_msg = EMSA-PSS-ENCODE(msg, kBits - 1) 220 with MGF and HF as defined in the parameters 221 2. If EMSA-PSS-ENCODE raises an error, raise the error and stop 222 3. m = bytes_to_int(encoded_msg) 223 4. r = random_integer_uniform(1, n) 224 5. r_inv = inverse_mod(r, n) 225 6. If inverse_mod fails, raise an "invalid blind" error 226 and stop 227 7. x = RSAVP1(pkS, r) 228 8. z = m * x mod n 229 9. blinded_msg = int_to_bytes(z, kLen) 230 10. inv = int_to_bytes(r_inv, kLen) 231 11. output blinded_msg, inv 233 The blinding factor r must be randomly chosen from a uniform 234 distribution. This is typically done via rejection sampling. 236 5.1.2. BlindSign 238 rsabssa_blind_sign performs the RSA private key operation on the 239 client's blinded message input and returns the output encoded as an 240 octet string. RSASP1 is as defined in [RFC3447]. 242 rsabssa_blind_sign(skS, blinded_msg) 244 Parameters: 245 - kLen, the length in octets of the RSA modulus n 247 Inputs: 248 - skS, server private key 249 - blinded_msg, encoded and blinded message to be signed, an 250 octet string 252 Outputs: 253 - blind_sig, an octet string of length kLen 255 Errors: 256 - "unexpected input size": Raised when a byte string input doesn't 257 have the expected length. 258 - "invalid message length": Raised when the message representative 259 to sign is not an integer between 0 and n - 1. 261 Steps: 262 1. If len(blinded_msg) != kLen, raise "unexpected input size" 263 and stop 264 2. m = bytes_to_int(blinded_msg) 265 3. If m >= n, raise "invalid message length" and stop 266 4. s = RSASP1(skS, m) 267 5. blind_sig = int_to_bytes(s, kLen) 268 6. output blind_sig 270 5.1.3. Finalize 272 rsabssa_finalize validates the server's response, unblinds the 273 message to produce a signature, verifies it for correctness, and 274 outputs the signature upon success. Note that this function will 275 internally hash the input message as is done in rsabssa_blind. 277 rsabssa_finalize(pkS, msg, blind_sig, inv) 279 Parameters: 280 - kLen, the length in octets of the RSA modulus n 282 Inputs: 283 - pkS, server public key (n, e) 284 - msg, message to be signed, an octet string 285 - blind_sig, signed and blinded element, an octet string of 286 length kLen 287 - inv, inverse of the blind, an octet string of length kLen 289 Outputs: 290 - sig, an octet string of length kLen 292 Errors: 293 - "invalid signature": Raised when the signature is invalid 294 - "unexpected input size": Raised when a byte string input doesn't 295 have the expected length. 297 Steps: 298 1. If len(blind_sig) != kLen, raise "unexpected input size" and stop 299 2. If len(inv) != kLen, raise "unexpected input size" and stop 300 3. z = bytes_to_int(blind_sig) 301 4. r_inv = bytes_to_int(inv) 302 5. s = z * r_inv mod n 303 6. sig = int_to_bytes(s, kLen) 304 7. result = RSASSA-PSS-VERIFY(pkS, msg, sig) 305 8. If result = "valid signature", output sig, else 306 raise "invalid signature" and stop 308 5.2. Encoding Options 310 The RSASSA-PSS parameters, defined as in [RFC8017], Section 9.1.1, 311 are as follows: 313 * Hash: hash function (hLen denotes the length in octets of the hash 314 function output) 316 * MGF: mask generation function 318 * sLen: intended length in octets of the salt 320 It is RECOMMENDED that implementations support the following encoding 321 options: 323 * SHA-384 as Hash and MGF functions and sLen = 48, as described in 324 [RFC8230], Section 2; and 326 * SHA-384 as Hash and MGF functions and sLen = 0. 328 Note that setting sLen = 0 has the result of making the signature 329 deterministic. 331 The blinded functions in Section 5.1 are orthogonal to the choice of 332 these encoding options. 334 6. Public Key Certification 336 If the server public key is carried in an X.509 certificate, it MUST 337 use the RSASSA-PSS OID [RFC5756]. It MUST NOT use the rsaEncryption 338 OID [RFC5280]. 340 7. Implementation Considerations 342 This section documents considerations for interfaces to 343 implementations of the protocol in this document. This includes 344 error handling and API considerations. 346 7.1. Errors 348 The high-level functions specified in Section 5.1 are all fallible. 349 The explicit errors generated throughout this specification, along 350 with the conditions that lead to each error, are listed in the 351 definitions for rsabssa_blind, rsabssa_blind_sign, and 352 rsabssa_finalize. These errors are meant as a guide for 353 implementors. They are not an exhaustive list of all the errors an 354 implementation might emit. For example, implementations might run 355 out of memory. 357 7.2. API Considerations 359 It is NOT RECOMMENDED that APIs allow clients to specify RSA-PSS 360 parameters directly, e.g., to set the PSS salt value or its length. 361 Instead, it is RECOMMENDED that implementations generate the PSS salt 362 using the same source of randomness used to produce the blinding 363 factor. 365 If implementations need support for randommized and deterministic 366 signatures, they should offer separate abstractions for each. 367 Allowing callers to control the PSS salt value or length may have 368 security consequences. See Section 8.3 for more information about 369 details. 371 8. Security Considerations 373 Bellare et al. [BNPS03] proved the following properties of Chaum's 374 original blind signature protocol based on RSA-FDH: 376 * One-more-forgery polynomial security. This means the adversary, 377 interacting with the server (signer) as a client, cannot output 378 n+1 valid message and signature tuples after only interacting with 379 the server n times, for some n which is polynomial in the 380 protocol's security parameter. 382 * Concurrent polynomial security. This means that servers can 383 engage in polynomially many invocations of the protocol without 384 compromising security. 386 Both results rely upon the RSA Known Target Inversion Problem being 387 hard. 389 The design in this document differs from the analysis in [BNPS03] 390 only in message encoding, i.e., using PSS instead of FDH. Note, 391 importantly, that an empty salt effectively reduces PSS to FDH, so 392 the same results apply. 394 8.1. Timing Side Channels 396 rsabssa_blind_sign is functionally a remote procedure call for 397 applying the RSA private key operation. As such, side channel 398 resistance is paramount to protect the private key from exposure 399 [RemoteTimingAttacks]. Implementations MUST implement RSA blinding 400 as a side channel attack mitigation. One mechanism is described in 401 Section 10 of [TimingAttacks]. Failure to do so may lead to side 402 channel attacks that leak the private signing key. 404 8.2. Message Robustness 406 An essential property of blind signature protocols is that the signer 407 learns nothing of the message being signed. In some circumstances, 408 this may raise concerns of arbitrary signing oracles. Applications 409 using blind signature protocols should take precautions to ensure 410 that such oracles do not cause cross-protocol attacks. This can be 411 done, for example, by keeping blind signature keys distinct from 412 signature keys used for other protocols, such as TLS. 414 An alternative solution to this problem of message blindness is to 415 give signers proof that the message being signed is well-structured. 416 Depending on the application, zero knowledge proofs could be useful 417 for this purpose. Defining such a proof is out of scope for this 418 document. 420 Verifiers should check that, in addition to signature validity, the 421 unblinded message is well-structured for the relevant application. 422 For example, if an application of this protocol requires messages to 423 be structures of a particular form, then verifiers should check that 424 unblinded messages adhere to this form. 426 8.3. Randomized and Deterministic Signatures 428 When sLen > 0, the PSS salt is a randomly generated string chosen 429 when a message is encoded. This means the resulting signature is 430 non-deterministic. As a result, two signatures over the same message 431 will be different. If the salt is not generated randomly, or is 432 otherwise constructed maliciously, it might be possible for the salt 433 to encode information that is not present in the signed message. For 434 example, the salt might be maliciously constructed to encode the 435 local IP address of the client. As a result, APIs SHOULD NOT allow 436 clients to provide the salt directly; see Section 7.2 for API 437 considerations. 439 When sLen = 0, the PSS salt is empty and the resulting signature is 440 deterministic. Such signatures may be useful for applications 441 wherein the only desired source of entropy is the input message. 443 Applications that use deterministic signatures SHOULD carefully 444 analyze the security implications. When the required signature 445 protocol is not clear, applications SHOULD default to randomized 446 signatures. 448 8.4. Key Substitution Attacks 450 RSA is well known to permit key substitution attacks, wherein an 451 attacker generates a key pair (skA, pkA) that verify some known 452 (message, signature) pair produced under a different (skS, pkS) key 453 pair [WM99]. This means it may be possible for an attacker to use a 454 (message, signature) pair from one context in another. Entities that 455 verify signatures must take care to ensure a (message, signature) 456 pair verifies with a valid public key from the expected issuer. 458 8.5. Alternative RSA Encoding Functions 460 This document document uses PSS encoding as specified in [RFC3447] 461 for a number of reasons. First, it is recommended in recent 462 standards, including TLS 1.3 [RFC8446], X.509v3 [RFC4055], and even 463 PKCS#1 itself. According to [RFC3447], "Although no attacks are 464 known against RSASSA-PKCS#1 v1.5, in the interest of increased 465 robustness, RSA-PSS is recommended for eventual adoption in new 466 applications." While RSA-PSS is more complex than RSASSA-PKCS#1 v1.5 467 encoding, ubiquity of RSA-PSS support influenced the design decision 468 in this draft, despite PKCS#1 v1.5 having equivalent security 469 properties for digital signatures [JKM18] 471 Full Domain Hash (FDH) [RSA-FDH] encoding is also possible, and this 472 variant has equivalent security to PSS [KK18]. However, FDH is less 473 standard and not used widely in related technologies. Moreover, FDH 474 is deterministic, whereas PSS supports deterministic and 475 probabilistic encodings. 477 8.6. Alternative Blind Signature Protocols 479 RSA has some advantages as a signature protocol, particularly around 480 verification efficiency. However, the protocol in this document is 481 not without shortcomings, including: 483 * RSA key and signature sizes are larger than those of alternative 484 blind signature protocols; 486 * No evaluation batching support, which means that the cost of the 487 protocol scales linearly with the number of invocations; and 489 * Extensions for features such as threshold signing are more complex 490 to instantiate compared to other protocols based on, for example, 491 Schnorr signatures. 493 There are a number of blind signature protocols beyond blind RSA. 494 This section summarizes these at a high level, and discusses why an 495 RSA-based variant was chosen for the basis of this specification, 496 despite the shortcomings above. 498 * Blind Schnorr [Sch01]: This is a three-message protocol based on 499 the classical Schnorr signature protocol over elliptic curve 500 groups. Although simple, the hardness problem upon which this is 501 based -- Random inhomogeneities in a Overdetermined Solvable 502 system of linear equations, or ROS -- can be broken in polynomial 503 time when a small number of concurrent signing sessions are 504 invoked [PolytimeROS], leading to signature forgeries. Even with 505 small concurrency limits, Wagner's generalized attack [Wagner02] 506 leads to subexponential forgery speedup. For example, a limit of 507 15 parallel sessions yields an attack runtime of approximately 508 2^55, which is substantially lower than acceptable security 509 levels. In contrast, the variant in this specification has no 510 such concurrency limit. 512 * Clause Blind Schnorr [FPS20]: This is a three-message protocol 513 based on a variant of the blind Schnorr signature protocol. This 514 variant of the protocol is not known to be vulnerable to the 515 attack in [PolytimeROS], though the protocol is still new and 516 under consideration. In the future, this may be a candidate for 517 future blind signatures based on blind signatures. However, the 518 three-message flow necessarily requires two round trips between 519 the client and server, which may be prohibitive for large-scale 520 signature generation. Further analysis and experimentation with 521 this protocol is needed. 523 * BSA [Abe01]: This is a three-message protocol based on elliptic 524 curve groups similar to blind Schnorr. It is also not known to be 525 vulnerable to the ROS attack in [PolytimeROS]. Kastner et al. 526 [KLRX20] proved concurrent security with a polynomial number of 527 sessions. For similar reasons to the clause blind Schnorr 528 protocol above, the additional number of round trips requires 529 further analysis and experimentation. 531 * Blind BLS [BLS-Proposal]: The Boneh-Lynn-Shacham 532 [I-D.irtf-cfrg-bls-signature] protocol can incorporate message 533 blinding when properly instantiated with Type III pairing group. 534 This is a two-message protocol similar to the RSA variant, though 535 it requires pairing support, which is not common in widely 536 deployed cryptographic libraries backing protocols such as TLS. 537 In contrast, the specification in this document relies upon widely 538 deployed cryptographic primitives. 540 Beyond blind signature protocols, anonymous credential schemes with 541 public verifiability such as U-Prove [UProve] may be used instead of 542 blind signature protocols. Anonymous credentials may even be 543 constructed with blind signature protocols. However, anonymous 544 credentials are higher-level constructions that present a richer 545 feature set. 547 8.7. Post-Quantum Readiness 549 The blind signature protocol specified in this document is not post- 550 quantum ready since it is based on RSA. (Shor's polynomial-time 551 factorization algorithm readily applies.) 553 9. IANA Considerations 555 This document makes no IANA requests. 557 10. References 559 10.1. Normative References 561 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 562 Requirement Levels", BCP 14, RFC 2119, 563 DOI 10.17487/RFC2119, March 1997, 564 . 566 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 567 Standards (PKCS) #1: RSA Cryptography Specifications 568 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 569 2003, . 571 [RFC5756] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 572 "Updates for RSAES-OAEP and RSASSA-PSS Algorithm 573 Parameters", RFC 5756, DOI 10.17487/RFC5756, January 2010, 574 . 576 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 577 "PKCS #1: RSA Cryptography Specifications Version 2.2", 578 RFC 8017, DOI 10.17487/RFC8017, November 2016, 579 . 581 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 582 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 583 May 2017, . 585 [RFC8230] Jones, M., "Using RSA Algorithms with CBOR Object Signing 586 and Encryption (COSE) Messages", RFC 8230, 587 DOI 10.17487/RFC8230, September 2017, 588 . 590 10.2. Informative References 592 [Abe01] Abe, M., "A Secure Three-Move Blind Signature Scheme for 593 Polynomially Many Signatures", 594 DOI 10.1007/3-540-44987-6_9, Lecture Notes in Computer 595 Science pp. 136-151, 2001, 596 . 598 [BLS-Proposal] 599 "[Privacy-pass] External verifiability: a concrete 600 proposal", July 2020, 601 . 604 [BNPS03] Bellare, ., Namprempre, ., Pointcheval, ., and . Semanko, 605 "The One-More-RSA-Inversion Problems and the Security of 606 Chaum's Blind Signature Scheme", 607 DOI 10.1007/s00145-002-0120-1, Journal of Cryptology Vol. 608 16, pp. 185-215, June 2003, 609 . 611 [Chaum83] "Blind Signatures for Untraceable Payments", 1983, 612 . 615 [FPS20] Fuchsbauer, G., Plouviez, A., and Y. Seurin, "Blind 616 Schnorr Signatures and Signed ElGamal Encryption in the 617 Algebraic Group Model", DOI 10.1007/978-3-030-45724-2_3, 618 Advances in Cryptology - EUROCRYPT 2020 pp. 63-95, 2020, 619 . 621 [I-D.davidson-pp-protocol] 622 Davidson, A., "Privacy Pass: The Protocol", Work in 623 Progress, Internet-Draft, draft-davidson-pp-protocol-01, 624 13 July 2020, . 627 [I-D.irtf-cfrg-bls-signature] 628 Boneh, D., Gorbunov, S., Wahby, R. S., Wee, H., and Z. 629 Zhang, "BLS Signatures", Work in Progress, Internet-Draft, 630 draft-irtf-cfrg-bls-signature-04, 10 September 2020, 631 . 634 [I-D.irtf-cfrg-voprf] 635 Davidson, A., Faz-Hernandez, A., Sullivan, N., and C. A. 636 Wood, "Oblivious Pseudorandom Functions (OPRFs) using 637 Prime-Order Groups", Work in Progress, Internet-Draft, 638 draft-irtf-cfrg-voprf-08, 25 October 2021, 639 . 642 [JKK14] "Round-Optimal Password-Protected Secret Sharing and 643 T-PAKE in the Password-Only model", August 2014, 644 . 646 [JKM18] Jager, T., Kakvi, S., and A. May, "On the Security of the 647 PKCS#1 v1.5 Signature Scheme", 648 DOI 10.1145/3243734.3243798, Proceedings of the 2018 ACM 649 SIGSAC Conference on Computer and Communications Security, 650 January 2018, . 652 [KK18] Kakvi, S. and E. Kiltz, "Optimal Security Proofs for Full 653 Domain Hash, Revisited", DOI 10.1007/s00145-017-9257-9, 654 Journal of Cryptology Vol. 31, pp. 276-306, April 2017, 655 . 657 [KLRX20] "On Pairing-Free Blind Signature Schemes in the Algebraic 658 Group Model", September 2020, 659 . 661 [PolytimeROS] 662 "On the (in)security of ROS", July 2020, 663 . 665 [RemoteTimingAttacks] 666 "Remote Timing Attacks are Practical", May 2003, 667 . 669 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 670 Algorithms and Identifiers for RSA Cryptography for use in 671 the Internet X.509 Public Key Infrastructure Certificate 672 and Certificate Revocation List (CRL) Profile", RFC 4055, 673 DOI 10.17487/RFC4055, June 2005, 674 . 676 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 677 Housley, R., and W. Polk, "Internet X.509 Public Key 678 Infrastructure Certificate and Certificate Revocation List 679 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 680 . 682 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 683 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 684 . 686 [RSA-FDH] "Random Oracles are Practical: A Paradigm for Designing 687 Efficient Protocols", October 1995, 688 . 690 [Sch01] Schnorr, C., "Security of Blind Discrete Log Signatures 691 against Interactive Attacks", DOI 10.1007/3-540-45600-7_1, 692 Information and Communications Security pp. 1-12, 2001, 693 . 695 [TimingAttacks] 696 Kocher, P., "Timing Attacks on Implementations of Diffie- 697 Hellman, RSA, DSS, and Other Systems", 698 DOI 10.1007/3-540-68697-5_9, Advances in Cryptology - 699 CRYPTO '96 pp. 104-113, 1996, 700 . 702 [UProve] "U-Prove", February 2012, . 705 [Wagner02] Wagner, D., "A Generalized Birthday Problem", 706 DOI 10.1007/3-540-45708-9_19, Advances in Cryptology - 707 CRYPTO 2002 pp. 288-304, 2002, 708 . 710 [WM99] "Unknown key-share attacks on the station-to-station (STS) 711 protocol", October 1999. 713 Appendix A. Test Vectors 715 This section includes test vectors for the blind signature protocol 716 defined in this document. The following parameters are specified: 718 * p, q, n, e, d: RSA private and public key parameters, each encoded 719 as a hexadecimal string. 721 * msg: Messsage being signed, encoded as a hexadecimal string. The 722 hash is computed using SHA-384. 724 * salt: Randomly-generated salt used when computing the signature. 725 The length (sLen) is either 48 or 0 bytes. 727 * inv: The message blinding inverse, encoded as a hexadecimal 728 string. 730 * encoded_msg: EMSA-PSS encoded message. The mask generation 731 function is MGF1 with SHA-384. 733 * blinded_msg, blind_sig: The protocol values exchanged during the 734 computation, encoded as hexadecimal strings. 736 * sig: The output message signature. 738 Test vector for probabilistic signatures (sLen=48): 740 p = e1f4d7a34802e27c7392a3cea32a262a34dc3691bd87f3f310dc756734889305 741 59c120fd0410194fb8a0da55bd0b81227e843fdca6692ae80e5a5d414116d4803fca 742 7d8c30eaaae57e44a1816ebb5c5b0606c536246c7f11985d731684150b63c9a3ad9e 743 41b04c0b5b27cb188a692c84696b742a80d3cd00ab891f2457443dadfeba6d6daf10 744 8602be26d7071803c67105a5426838e6889d77e8474b29244cefaf418e381b312048 745 b457d73419213063c60ee7b0d81820165864fef93523c9635c22210956e53a8d9632 746 2493ffc58d845368e2416e078e5bcb5d2fd68ae6acfa54f9627c42e84a9d3f277401 747 7e32ebca06308a12ecc290c7cd1156dcccfb2311 748 q = c601a9caea66dc3835827b539db9df6f6f5ae77244692780cd334a006ab353c8 749 06426b60718c05245650821d39445d3ab591ed10a7339f15d83fe13f6a3dfb20b945 750 2c6a9b42eaa62a68c970df3cadb2139f804ad8223d56108dfde30ba7d367e9b0a7a8 751 0c4fdba2fd9dde6661fc73fc2947569d2029f2870fc02d8325acf28c9afa19ecf962 752 daa7916e21afad09eb62fe9f1cf91b77dc879b7974b490d3ebd2e95426057f35d0a3 753 c9f45f79ac727ab81a519a8b9285932d9b2e5ccd347e59f3f32ad9ca359115e7da00 754 8ab7406707bd0e8e185a5ed8758b5ba266e8828f8d863ae133846304a2936ad7bc7c 755 9803879d2fc4a28e69291d73dbd799f8bc238385 756 n = aec4d69addc70b990ea66a5e70603b6fee27aafebd08f2d94cbe1250c556e047 757 a928d635c3f45ee9b66d1bc628a03bac9b7c3f416fe20dabea8f3d7b4bbf7f963be3 758 35d2328d67e6c13ee4a8f955e05a3283720d3e1f139c38e43e0338ad058a9495c533 759 77fc35be64d208f89b4aa721bf7f7d3fef837be2a80e0f8adf0bcd1eec5bb040443a 760 2b2792fdca522a7472aed74f31a1ebe1eebc1f408660a0543dfe2a850f106a617ec6 761 685573702eaaa21a5640a5dcaf9b74e397fa3af18a2f1b7c03ba91a6336158de420d 762 63188ee143866ee415735d155b7c2d854d795b7bc236cffd71542df34234221a0413 763 e142d8c61355cc44d45bda94204974557ac2704cd8b593f035a5724b1adf442e78c5 764 42cd4414fce6f1298182fb6d8e53cef1adfd2e90e1e4deec52999bdc6c29144e8d52 765 a125232c8c6d75c706ea3cc06841c7bda33568c63a6c03817f722b50fcf898237d78 766 8a4400869e44d90a3020923dc646388abcc914315215fcd1bae11b1c751fd52443aa 767 c8f601087d8d42737c18a3fa11ecd4131ecae017ae0a14acfc4ef85b83c19fed33cf 768 d1cd629da2c4c09e222b398e18d822f77bb378dea3cb360b605e5aa58b20edc29d00 769 0a66bd177c682a17e7eb12a63ef7c2e4183e0d898f3d6bf567ba8ae84f84f1d23bf8 770 b8e261c3729e2fa6d07b832e07cddd1d14f55325c6f924267957121902dc19b3b329 771 48bdead5 772 e = 010001 773 d = 0d43242aefe1fb2c13fbc66e20b678c4336d20b1808c558b6e62ad16a2870771 774 80b177e1f01b12f9c6cd6c52630257ccef26a45135a990928773f3bd2fc01a313f1d 775 ac97a51cec71cb1fd7efc7adffdeb05f1fb04812c924ed7f4a8269925dad88bd7dcf 776 bc4ef01020ebfc60cb3e04c54f981fdbd273e69a8a58b8ceb7c2d83fbcbd6f784d05 777 2201b88a9848186f2a45c0d2826870733e6fd9aa46983e0a6e82e35ca20a439c5ee7 778 b502a9062e1066493bdadf8b49eb30d9558ed85abc7afb29b3c9bc644199654a4676 779 681af4babcea4e6f71fe4565c9c1b85d9985b84ec1abf1a820a9bbebee0df1398aae 780 2c85ab580a9f13e7743afd3108eb32100b870648fa6bc17e8abac4d3c99246b1f0ea 781 9f7f93a5dd5458c56d9f3f81ff2216b3c3680a13591673c43194d8e6fc93fc1e37ce 782 2986bd628ac48088bc723d8fbe293861ca7a9f4a73e9fa63b1b6d0074f5dea2a624c 783 5249ff3ad811b6255b299d6bc5451ba7477f19c5a0db690c3e6476398b1483d10314 784 afd38bbaf6e2fbdbcd62c3ca9797a420ca6034ec0a83360a3ee2adf4b9d4ba29731d 785 131b099a38d6a23cc463db754603211260e99d19affc902c915d7854554aabf608e3 786 ac52c19b8aa26ae042249b17b2d29669b5c859103ee53ef9bdc73ba3c6b537d5c34b 787 6d8f034671d7f3a8a6966cc4543df223565343154140fd7391c7e7be03e241f4ecfe 788 b877a051 789 msg = 8f3dc6fb8c4a02f4d6352edf0907822c1210a9b32f9bdda4c45a698c80023a 790 a6b59f8cfec5fdbb36331372ebefedae7d 791 salt = 051722b35f458781397c3a671a7d3bd3096503940e4c4f1aaa269d60300ce 792 449555cd7340100df9d46944c5356825abf 793 inv = 80682c48982407b489d53d1261b19ec8627d02b8cda5336750b8cee332ae26 794 0de57b02d72609c1e0e9f28e2040fc65b6f02d56dbd6aa9af8fde656f70495dfb723 795 ba01173d4707a12fddac628ca29f3e32340bd8f7ddb557cf819f6b01e445ad96f874 796 ba235584ee71f6581f62d4f43bf03f910f6510deb85e8ef06c7f09d9794a008be7ff 797 2529f0ebb69decef646387dc767b74939265fec0223aa6d84d2a8a1cc912d5ca25b4 798 e144ab8f6ba054b54910176d5737a2cff011da431bd5f2a0d2d66b9e70b39f4b050e 799 45c0d9c16f02deda9ddf2d00f3e4b01037d7029cd49c2d46a8e1fc2c0c17520af1f4 800 b5e25ba396afc4cd60c494a4c426448b35b49635b337cfb08e7c22a39b256dd032c0 801 0adddafb51a627f99a0e1704170ac1f1912e49d9db10ec04c19c58f420212973e0cb 802 329524223a6aa56c7937c5dffdb5d966b6cd4cbc26f3201dd25c80960a1a111b3294 803 7bb78973d269fac7f5186530930ed19f68507540eed9e1bab8b00f00d8ca09b3f099 804 aae46180e04e3584bd7ca054df18a1504b89d1d1675d0966c4ae1407be325cdf623c 805 f13ff13e4a28b594d59e3eadbadf6136eee7a59d6a444c9eb4e2198e8a974f27a39e 806 b63af2c9af3870488b8adaad444674f512133ad80b9220e09158521614f1faadfe85 807 05ef57b7df6813048603f0dd04f4280177a11380fbfc861dbcbd7418d62155248dad 808 5fdec0991f 809 encoded_msg = 6e0c464d9c2f9fbc147b43570fc4f238e0d0b38870b3addcf7 810 a4217df912ccef17a7f629aa850f63a063925f312d61d6437be954b45025e8282f9c 811 0b1131bc8ff19a8a928d859b37113db1064f92a27f64761c181c1e1f9b251ae5a2f8 812 a4047573b67a270584e089beadcb13e7c82337797119712e9b849ff56e04385d144d 813 3ca9d8d92bf78adb20b5bbeb3685f17038ec6afade3ef354429c51c687b45a7018ee 814 3a6966b3af15c9ba8f40e6461ba0a17ef5a799672ad882bab02b518f9da7c1a96294 815 5c2e9b0f02f29b31b9cdf3e633f9d9d2a22e96e1de28e25241ca7dd04147112f5789 816 73403e0f4fd80865965475d22294f065e17a1c4a201de93bd14223e6b1b999fd548f 817 2f759f52db71964528b6f15b9c2d7811f2a0a35d534b8216301c47f4f04f412cae14 818 2b48c4cdff78bc54df690fd43142d750c671dd8e2e938e6a440b2f825b6dbb3e19f1 819 d7a3c0150428a47948037c322365b7fe6fe57ac88d8f80889e9ff38177bad8c8d8d9 820 8db42908b389cb59692a58ce275aa15acb032ca951b3e0a3404b7f33f655b7c7d83a 821 2f8d1b6bbff49d5fcedf2e030e80881aa436db27a5c0dea13f32e7d460dbf01240c2 822 320c2bb5b3225b17145c72d61d47c8f84d1e19417ebd8ce3638a82d395cc6f7050b6 823 209d9283dc7b93fecc04f3f9e7f566829ac41568ef799480c733c09759aa9734e201 824 3d7640dc6151018ea902bc 825 blinded_msg = 10c166c6a711e81c46f45b18e5873cc4f494f003180dd7f115 826 585d871a28930259654fe28a54dab319cc5011204c8373b50a57b0fdc7a678bd74c5 827 23259dfe4fd5ea9f52f170e19dfa332930ad1609fc8a00902d725cfe50685c95e5b2 828 968c9a2828a21207fcf393d15f849769e2af34ac4259d91dfd98c3a707c509e1af55 829 647efaa31290ddf48e0133b798562af5eabd327270ac2fb6c594734ce339a14ea4fe 830 1b9a2f81c0bc230ca523bda17ff42a377266bc2778a274c0ae5ec5a8cbbe364fcf0d 831 2403f7ee178d77ff28b67a20c7ceec009182dbcaa9bc99b51ebbf13b7d542be33717 832 2c6474f2cd3561219fe0dfa3fb207cff89632091ab841cf38d8aa88af6891539f263 833 adb8eac6402c41b6ebd72984e43666e537f5f5fe27b2b5aa114957e9a580730308a5 834 f5a9c63a1eb599f093ab401d0c6003a451931b6d124180305705845060ebba6b0036 835 154fcef3e5e9f9e4b87e8f084542fd1dd67e7782a5585150181c01eb6d90cb958838 836 37384a5b91dbb606f266059ecc51b5acbaa280e45cfd2eec8cc1cdb1b7211c8e1480 837 5ba683f9b78824b2eb005bc8a7d7179a36c152cb87c8219e5569bba911bb32a1b923 838 ca83de0e03fb10fba75d85c55907dda5a2606bf918b056c3808ba496a4d955322120 839 40a5f44f37e1097f26dc27b98a51837daa78f23e532156296b64352669c94a8a855a 840 cf30533d8e0594ace7c442 841 blind_sig = 364f6a40dbfbc3bbb257943337eeff791a0f290898a67912 842 83bba581d9eac90a6376a837241f5f73a78a5c6746e1306ba3adab6067c32ff69115 843 734ce014d354e2f259d4cbfb890244fd451a497fe6ecf9aa90d19a2d441162f7eaa7 844 ce3fc4e89fd4e76b7ae585be2a2c0fd6fb246b8ac8d58bcb585634e30c9168a43478 845 6fe5e0b74bfe8187b47ac091aa571ffea0a864cb906d0e28c77a00e8cd8f6aba4317 846 a8cc7bf32ce566bd1ef80c64de041728abe087bee6cadd0b7062bde5ceef308a23bd 847 1ccc154fd0c3a26110df6193464fc0d24ee189aea8979d722170ba945fdcce9b1b4b 848 63349980f3a92dc2e5418c54d38a862916926b3f9ca270a8cf40dfb9772bfbdd9a3e 849 0e0892369c18249211ba857f35963d0e05d8da98f1aa0c6bba58f47487b8f663e395 850 091275f82941830b050b260e4767ce2fa903e75ff8970c98bfb3a08d6db91ab1746c 851 86420ee2e909bf681cac173697135983c3594b2def673736220452fde4ddec867d40 852 ff42dd3da36c84e3e52508b891a00f50b4f62d112edb3b6b6cc3dbd546ba10f36b03 853 f06c0d82aeec3b25e127af545fac28e1613a0517a6095ad18a98ab79f68801e05c17 854 5e15bae21f821e80c80ab4fdec6fb34ca315e194502b8f3dcf7892b511aee45060e3 855 994cd15e003861bc7220a2babd7b40eda03382548a34a7110f9b1779bf3ef6011361 856 611e6bc5c0dc851e1509de1a 857 sig = 6fef8bf9bc182cd8cf7ce45c7dcf0e6f3e518ae48f06f3c670c649ac737a8b 858 8119a34d51641785be151a697ed7825fdfece82865123445eab03eb4bb91cecf4d69 859 51738495f8481151b62de869658573df4e50a95c17c31b52e154ae26a04067d5ecdc 860 1592c287550bb982a5bb9c30fd53a768cee6baabb3d483e9f1e2da954c7f4cf492fe 861 3944d2fe456c1ecaf0840369e33fb4010e6b44bb1d721840513524d8e9a3519f40d1 862 b81ae34fb7a31ee6b7ed641cb16c2ac999004c2191de0201457523f5a4700dd64926 863 7d9286f5c1d193f1454c9f868a57816bf5ff76c838a2eeb616a3fc9976f65d4371de 864 ecfbab29362caebdff69c635fe5a2113da4d4d8c24f0b16a0584fa05e80e607c5d9a 865 2f765f1f069f8d4da21f27c2a3b5c984b4ab24899bef46c6d9323df4862fe51ce300 866 fca40fb539c3bb7fe2dcc9409e425f2d3b95e70e9c49c5feb6ecc9d43442c33d5000 867 3ee936845892fb8be475647da9a080f5bc7f8a716590b3745c2209fe05b17992830c 868 e15f32c7b22cde755c8a2fe50bd814a0434130b807dc1b7218d4e85342d70695a5d7 869 f29306f25623ad1e8aa08ef71b54b8ee447b5f64e73d09bdd6c3b7ca224058d7c67c 870 c7551e9241688ada12d859cb7646fbd3ed8b34312f3b49d69802f0eaa11bc4211c2f 871 7a29cd5c01ed01a39001c5856fab36228f5ee2f2e1110811872fe7c865c42ed59029 872 c706195d52 874 Test vector for deterministic signatures (sLen=0): 876 p = ca9d82e9059fa3b145da850e0c451ff31093d819644ba29a3409393de2adfa1b 877 cd65e8669a5c5140142c1404204edbc380d4e7a5c866c06bb2427c76b9e3d16bbfc1 878 b1668dec219b8c59fee90b7baf557fc2feb13f2f4b30d8606d20b9928f4f588a3b34 879 baa659b3bd1dd590c83e90e6251b5239fbbb73b12e90534a375e3f71 880 q = c075694f69db6a07456e19eeace01b430f2d6cc6cd5495d569e242b6f5e8ded7 881 df27e6aeea4db4e307554fb519b68279a58d9e2d25cee4b37668554eec2f2feb7924 882 6955a07bd526f02a6afedc7a3aff2b8953287fef2c4a02207ccb9f14e4612e9af344 883 7dd3401728a8957871b759b6bbf22aa0e8271b82f32dd5a2d2550197 884 n = 98530f850dcc894d84ecfce9dec3a475bf30ec3ce4606f677ac4a6ef63f763ff 885 64a162ef1c991d8094b5652d0d78c126b3e97d1d77eba2f833b5be9a124e003065ec 886 2a3ea4fbc31bc283de1c7cd8a971eb57aa7284b082562ccde572b73702068a6143e6 887 dabf886538ff419874c300a85f3d9d50f0731fc6b9c92a121fefb7911f5ea92d25b1 888 7a4f3b2883eff34a221b5c28c488e35067a8460d8fab1c405704ebfa1ca165d69cd4 889 e425995a03a447f6cbba5d20d459707ab4a2c537a5dbd02801d7b19a03aaa9aec21d 890 1c363996c6b9fee2cab370d501c9b67e7dc4a20eb0cdc3b24be242093b5a66119b96 891 da0fb0ec0b1b0da0bd0b92236ece47d5c95bdca7 892 e = 010001 893 d = 6b15d18e4f8220709fe75f7226ca517ef9b7320d28dc66d54fa89a5727670f24 894 c7a0f1857a0c6682338946a4a298e6e90788390e137553afbbe2a4297a7edd8128d6 895 1b68c8e1b96b7596f0fa0406e9308e2ba64735e344edc237c97b993411b7796721ae 896 54d05bda1574d5af913e59e30479b373e86676cb6566f7ada0480d3ae21d50ac94c0 897 b41c476e566d6bcdef88eeab3042ef1016527558e794b6029cff1120596fe2104fac 898 928a66ad2fb1094d1ae1231abf95206cae7cd4e7aad388199d7ac1fe17e3f9174362 899 32cffe70e12056e02cfb9604e73cc34984bb83f7112ed197bf3a4d9f6d0c0e3c4dd8 900 f2d9cbe17185f1e63561b08f7d14bd36112f3ea1 901 msg = 5465737420766563746f7220776974682064657465726d696e697374696320 902 70616464696e67 903 encoded_msg = 4021ac68705782fb7587bf24ac0528853025aa4a998db7b1a503af 904 b5b266cbd1876710a2b0aa6e37b70fca538d42285beddd61d965c02b2162c8644587 905 3bdaf687a29bf6b2ab10fa22013cae53ff1c78969ef6c3eb069bfef339a5df788044 906 d159678e571e50fc3fa40a30fe183348453542f258c663dc9c4b372895120ad12ff8 907 b8ec1d37d766b2604fbf50bf9d84432a59593d21d7f379d6bf9198ea2fa90ee5abad 908 b27eada5d6f40a2ec45aa4bb8710042beab5c6afb4381fc57012e61b3a815800e53e 909 69fe2fdccb3b4ee51968c1ef6281d7e8fe08c4337bad73d99e947df834e5402378a6 910 6142bf032dfade7e6e2d43ae90b145055861e06eff189b63bc 911 inv = 6e69972553327ee6240ce0de7146aea2243927cf9f7f52c0103367df79e3ba 912 febfa61c2ffdc41ea397a38523654a1a806f4eebcd5fe9a2592a463f1faa26c3601f 913 83f29141eda488f14f7c0aa82faa025e37adbe77e02e575f72f7b9d095882923476f 914 2328dfaeb23b607d2f706c6c8ef6c2aee50ddb14e6d27e043e7dec8e5dede6844aa8 915 0b2206b6019350d37925bb8819653aa7a13bfb9cc3c95b53378f278903b5c06a10c0 916 b3ce0aa028e9600f7b2733f0278565f9b88e9d92e039db78300170d7bbd32ce2b89a 917 d8944167839880e3a2aeba05bf00edc8032a63e6279bf42a131ccc9bb95b8693764b 918 27665274fb673bdfb7d69b7957ee8b64a99efbeed9 919 blinded_msg = 5a631b41e7759a634cef04359436e358143ee2892fbebd072d1e5c 920 c45475ff55b6b492e13c59979f4b968994ddca3cc068084d3b176a6132039c584707 921 acbb9862c009fa5b63cfb7b6f6d577825c1e81ad11059cb87a524083230f906ea0a4 922 d9db3434d49cf9f0ea52b2425db4d319f51540e5de6cfb30b86d5e5d810a284f3478 923 f6259f054407c854303ec23c2e0989dd57aa002e56ab6287594c25154a1646060cb4 924 f6479b07f627991f7089ac0491d5841d6461166b324b3d448b2a8071de68505503fe 925 adf7d8182d18d8b0d3b91d77b627a5ffae68f913efbbb2fc082437f845880f94f07d 926 873bc0c0688f60033235bcc1701dcba83dca944b05227884e3 927 blind_sig = 817596a0b568088b60c29482c0178d34e0d54dc34a9375152701e4e6 928 d5ef76c92f4281a377d8b2f438f6af4ef9c26dd38ad2cc932f90fe45d4c0a1ba10e6 929 95a1c8e797aa5023f84385904e5f378df5677b8eb7312f835f9e3a097b1b7e55fece 930 0d00ec3f52ba26b39c91322b6404eef4e567d909195bfc0f72690805ea3f71736d7e 931 b51e84556c5241786f5f37bf9d2a0305bf36454d9ab8b5a9f6fe03fd4ab472b5379d 932 7e8ab92e803c7c15bf3d0234653e1f6d80d23c7f127bed7fba3d297b62fee51b8e71 933 b04d402cf291ac87460011fd222cfd27b5669d79d1e0dcc8d911c2dc6d0edcd205a9 934 1278cc97019cfc709ce8a50297409e66f27b1299e386a6cd 935 sig = 848fc8a032ea073280a7d9146ae55bb0199cd1941c10a03cce1dc38579c4e7 936 7e87f259e250b16a9912ce2c085cb9489846f803fd6ed09bf8605c4aa8b0ebf2c938 937 093e53ad025a48b97f7975255805118c33fa0f73ec204b9723acefacd8031ab3d9f7 938 ebeaf996eee3678c788cea96932dd723b236355c0e6864fad2fc87b00e4eda476e90 939 f000936b0d9fa65bf1112fc296e8aa5bb05ca7cb32dec01407e3d3ed94c1ebb0dc43 940 0ea59588ccc0995a6e2f1423dbe06c6f27650b23b12eb343b9e461ba532825e5e265 941 72fbe723b69753c178361e7a834a566ce950df55ff97d314b384b3fa8c0098d560d4 942 c6ba519a9b6040f908adf34f6b2d5d30c265cd0fb1 944 Authors' Addresses 946 Frank Denis 947 Fastly Inc. 949 Email: fd@00f.net 951 Frederic Jacobs 952 Apple Inc. 954 Email: frederic.jacobs@apple.com 956 Christopher A. Wood 957 Cloudflare 959 Email: caw@heapingbits.net