idnits 2.17.00 (12 Aug 2021) /tmp/idnits38505/draft-dew-cfrg-signature-key-blinding-02.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (3 May 2022) is 11 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '32' on line 297 -- Looks like a reference, but probably isn't: '63' on line 297 -- Looks like a reference, but probably isn't: '57' on line 338 -- Looks like a reference, but probably isn't: '113' on line 338 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 WG Working Group F. Denis 3 Internet-Draft Fastly Inc. 4 Intended status: Informational E. Eaton 5 Expires: 4 November 2022 University of Waterloo 6 C. A. Wood 7 Cloudflare, Inc. 8 3 May 2022 10 Key Blinding for Signature Schemes 11 draft-dew-cfrg-signature-key-blinding-02 13 Abstract 15 This document describes extensions to existing digital signature 16 schemes for key blinding. The core property of signing with key 17 blinding is that a blinded public key and all signatures produced 18 using the blinded key pair are independent of the unblinded key pair. 19 Moreover, signatures produced using blinded key pairs are 20 indistinguishable from signatures produced using unblinded key pairs. 21 This functionality has a variety of applications, including Tor onion 22 services and privacy-preserving airdrop for bootstrapping 23 cryptocurrency systems. 25 About This Document 27 This note is to be removed before publishing as an RFC. 29 The latest revision of this draft can be found at https://chris- 30 wood.github.io/draft-dew-cfrg-signature-key-blinding/draft-dew-cfrg- 31 signature-key-blinding.html. Status information for this document 32 may be found at https://datatracker.ietf.org/doc/draft-dew-cfrg- 33 signature-key-blinding/. 35 Discussion of this document takes place on the CFRG Working Group 36 mailing list (mailto:cfrg@irtf.org), which is archived at 37 https://mailarchive.ietf.org/arch/browse/cfrg/. 39 Source for this draft and an issue tracker can be found at 40 https://github.com/chris-wood/draft-dew-cfrg-signature-key-blinding. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on 4 November 2022. 59 Copyright Notice 61 Copyright (c) 2022 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 66 license-info) in effect on the date of publication of this document. 67 Please review these documents carefully, as they describe your rights 68 and restrictions with respect to this document. Code Components 69 extracted from this document must include Revised BSD License text as 70 described in Section 4.e of the Trust Legal Provisions and are 71 provided without warranty as described in the Revised BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 1.1. DISCLAIMER . . . . . . . . . . . . . . . . . . . . . . . 4 77 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 78 3. Key Blinding . . . . . . . . . . . . . . . . . . . . . . . . 5 79 4. Ed25519ph, Ed25519ctx, and Ed25519 . . . . . . . . . . . . . 6 80 4.1. BlindPublicKey and UnblindPublicKey . . . . . . . . . . . 6 81 4.2. BlindKeySign . . . . . . . . . . . . . . . . . . . . . . 6 82 5. Ed448ph and Ed448 . . . . . . . . . . . . . . . . . . . . . . 7 83 5.1. BlindPublicKey and UnblindPublicKey . . . . . . . . . . . 7 84 5.2. BlindKeySign . . . . . . . . . . . . . . . . . . . . . . 7 85 6. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 86 6.1. BlindPublicKey and UnblindPublicKey . . . . . . . . . . . 8 87 6.2. BlindKeySign . . . . . . . . . . . . . . . . . . . . . . 9 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 90 9. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 10 91 9.1. Ed25519 Test Vectors . . . . . . . . . . . . . . . . . . 10 92 9.2. ECDSA(P-384, SHA-384) Test Vectors . . . . . . . . . . . 10 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 94 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 95 10.2. Informative References . . . . . . . . . . . . . . . . . 11 96 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 99 1. Introduction 101 Digital signature schemes allow a signer to sign a message using a 102 private signing key and produce a digital signature such that anyone 103 can verify the digital signature over the message with the public 104 verification key corresponding to the signing key. Digital signature 105 schemes typically consist of three functions: 107 * KeyGen: A function for generating a private signing key skS and 108 the corresponding public verification key pkS. 110 * Sign(skS, msg): A function for signing an input message msg using 111 a private signing key skS, producing a digital signature sig. 113 * Verify(pkS, msg, sig): A function for verifying the digital 114 signature sig over input message msg against a public verification 115 key pkS, yielding true if the signature is valid and false 116 otherwise. 118 In some applications, it's useful for a signer to produce digital 119 signatures using the same long-term private signing key such that a 120 verifier cannot link any two signatures to the same signer. In other 121 words, the signature produced is independent of the long-term 122 private-signing key, and the public verification key for verifying 123 the signature is independent of the long-term public verification 124 key. This type of functionality has a number of practical 125 applications, including, for example, in the Tor onion services 126 protocol [TORDIRECTORY] and privacy-preserving airdrop for 127 bootstrapping cryptocurrency systems [AIRDROP]. It is also necessary 128 for a variant of the Privacy Pass issuance protocol [RATELIMITED]. 130 One way to accomplish this is by signing with a private key which is 131 a function of the long-term private signing key and a freshly chosen 132 blinding key, and similarly by producing a public verification key 133 which is a function of the long-term public verification key and same 134 blinding key. A signature scheme with this functionality is referred 135 to as signing with key blinding. A signature scheme with key 136 blinding extends a basic digital scheme with four new functions: 138 * BlindKeyGen: A function for generating a private blind key. 140 * BlindPublicKey(pkS, bk): Blind the public verification key pkS 141 using the private blinding key bk, yielding a blinded public key 142 pkR. 144 * UnblindPublicKey(pkR, bk): Unblind the public verification key pkR 145 using the private blinding key bk. 147 * BlindKeySign(skS, bk, msg): Sign a message msg using the private 148 signing key skS with the private blind key bk. 150 A signature scheme with key blinding aims to achieve unforgeability 151 and unlinkability. Informally, unforgeability means that one cannot 152 produce a valid (message, signature) pair for any blinding key 153 without access to the private signing key. Similarly, unlinkability 154 means that one cannot distinguish between two signatures produced 155 from two separate key signing keys, and two signatures produced from 156 the same signing key but with different blinding keys. 158 This document describes extensions to EdDSA [RFC8032] and ECDSA 159 [ECDSA] to enable signing with key blinding. Security analysis of 160 these extensions is currently underway; see Section 7 for more 161 details. 163 This functionality is also possible with other signature schemes, 164 including some post-quantum signature schemes [ESS21], though such 165 extensions are not specified here. 167 1.1. DISCLAIMER 169 This document is a work in progress and is still undergoing security 170 analysis. As such, it MUST NOT be used for real world applications. 171 See Section 7 for additional information. 173 2. Conventions and Definitions 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 177 "OPTIONAL" in this document are to be interpreted as described in 178 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 179 capitals, as shown here. 181 The following terms are used throughout this document to describe the 182 blinding modification. 184 * G: The standard base point. 186 * sk: A signature scheme private key. For EdDSA, this is a a 187 randomly generated private seed of length 32 bytes or 57 bytes 188 according to [RFC8032], Section 5.1.5 or [RFC8032], Section 5.2.5, 189 respectively. For [ECDSA], sk is a random scalar in the prime- 190 order elliptic curve group. 192 * pk(sk): The public key corresponding to the private key sk. 194 * concat(x0, ..., xN): Concatenation of byte strings. concat(0x01, 195 0x0203, 0x040506) = 0x010203040506. 197 * ScalarMult(pk, k): Multiply the public key pk by scalar k, 198 producing a new public key as a result. 200 * ModInverse(x, L): Compute the multiplicative inverse of x modulo 201 L. 203 In pseudocode descriptions below, integer multiplication of two 204 scalar values is denoted by the * operator. For example, the product 205 of two scalars x and y is denoted as x * y. 207 3. Key Blinding 209 At a high level, a signature scheme with key blinding allows signers 210 to blind their private signing key such that any signature produced 211 with a private signing key and blinding key is independent of the 212 private signing key. Similar to the signing key, the blinding key is 213 also a private key that remains secret. For example, the blind is a 214 32-byte or 57-byte random seed for Ed25519 or Ed448 variants, 215 respectively, whereas the blind for ECDSA over P-256 is a random 216 scalar in the P-256 group. Key blinding introduces four new 217 functionalities for the signature scheme: 219 * BlindKeyGen: A function for generating a private blind key. 221 * BlindPublicKey(pkS, bk): Blind the public verification key pkS 222 using the private blinding key bk, yielding a blinded public key 223 pkR. 225 * UnblindPublicKey(pkR, bk): Unblind the public verification key pkR 226 using the private blinding key bk. 228 * BlindKeySign(skS, bk, msg): Sign a message msg using the private 229 signing key skS with the private blind key bk. 231 For a given bk produced from BlindKeyGen, correctness requires the 232 following equivalence to hold: 234 UnblindPublicKey(BlindPublicKey(pkS, bk), bk) = pkS 236 Security requires that signatures produced using BlindKeySign are 237 unlinkable from signatures produced using the standard signature 238 generation function with the same private key. 240 4. Ed25519ph, Ed25519ctx, and Ed25519 242 This section describes implementations of BlindPublicKey, 243 UnblindPublicKey, and BlindKeySign as modifications of routines in 244 [RFC8032], Section 5.1. BlindKeyGen invokes the key generation 245 routine specified in [RFC8032], Section 5.1.5 and outputs only the 246 private key. 248 4.1. BlindPublicKey and UnblindPublicKey 250 BlindPublicKey transforms a private blind bk into a scalar for the 251 edwards25519 group and then multiplies the target key by this scalar. 252 UnblindPublicKey performs essentially the same steps except that it 253 multiplies the target public key by the multiplicative inverse of the 254 scalar, where the inverse is computed using the order of the group L, 255 described in [RFC8032], Section 5.1. 257 More specifically, BlindPublicKey(pk, bk) works as follows. 259 1. Hash the 32-byte private key bk using SHA-512, storing the digest 260 in a 64-octet large buffer, denoted b. Interpret the lower 32 261 bytes buffer as a little-endian integer, forming a secret scalar 262 s. Note that this explicitly skips the buffer pruning step in 263 [RFC8032], Section 5.1. 265 2. Perform a scalar multiplication ScalarMult(pk, s), and output the 266 encoding of the resulting point as the public key. 268 UnblindPublicKey(pkR, bk) works as follows. 270 1. Compute the secret scalar s from bk as in BlindPublicKey. 272 2. Compute the sInv = ModInverse(s, L), where L is as defined in 273 [RFC8032], Section 5.1. 275 3. Perform a scalar multiplication ScalarMult(pk, sInv), and output 276 the encoding of the resulting point as the public key. 278 4.2. BlindKeySign 280 BlindKeySign transforms a private key bk into a scalar for the 281 edwards25519 group and a message prefix to blind both the signing 282 scalar and the prefix of the message used in the signature generation 283 routine. 285 More specifically, BlindKeySign(skS, bk, msg) works as follows: 287 1. Hash the private key skS, 32 octets, using SHA-512. Let h denote 288 the resulting digest. Construct the secret scalar s1 from the 289 first half of the digest, and the corresponding public key A1, as 290 described in [RFC8032], Section 5.1.5. Let prefix1 denote the 291 second half of the hash digest, h[32],...,h[63]. 293 2. Hash the 32-byte private key bk using SHA-512, storing the digest 294 in a 64-octet large buffer, denoted b. Interpret the lower 32 295 bytes buffer as a little-endian integer, forming a secret scalar 296 s2. Let prefix2 denote the second half of the hash digest, 297 b[32],...,b[63]. 299 3. Compute the signing scalar s = s1 * s2 (mod L) and the signing 300 public key A = ScalarMult(G, s). 302 4. Compute the signing prefix as concat(prefix1, prefix2). 304 5. Run the rest of the Sign procedure in [RFC8032], Section 5.1.6 305 from step (2) onwards using the modified scalar s, public key A, 306 and string prefix. 308 5. Ed448ph and Ed448 310 This section describes implementations of BlindPublicKey, 311 UnblindPublicKey, and BlindKeySign as modifications of routines in 312 [RFC8032], Section 5.2. BlindKeyGen invokes the key generation 313 routine specified in [RFC8032], Section 5.1.5 and outputs only the 314 private key. 316 5.1. BlindPublicKey and UnblindPublicKey 318 BlindPublicKey and UnblindPublicKey for Ed448ph and Ed448 are 319 implemented just as these routines are for Ed25519ph, Ed25519ctx, and 320 Ed25519, except that SHAKE256 is used instead of SHA-512 for hashing 321 the secret blind to a 114-byte buffer (and using the lower 57-bytes 322 for the secret), and the order of the edwards448 group L is as 323 defined in [RFC8032], Section 5.2.1. 325 5.2. BlindKeySign 327 BlindKeySign for Ed448ph and Ed448 is implemented just as this 328 routine for Ed25519ph, Ed25519ctx, and Ed25519, except in how the 329 scalars (s1, s2), public keys (A1, A2), and message strings (prefix1, 330 prefix2) are computed. More specifically, BlindKeySign(skS, bk, msg) 331 works as follows: 333 1. Hash the private key skS, 57 octets, using SHAKE256(skS, 117). 334 Let h denote the resulting digest. Construct the secret scalar 335 s1 from the first half of the digest, and the corresponding 336 public key A1, as described in [RFC8032], Section 5.2.5. Let 337 prefix1 denote the second half of the hash digest, 338 h[57],...,h[113]. 340 2. Perform the same routine to transform the secret blind bk into a 341 secret scalar s2, public key A2, and prefix2. 343 3. Compute the signing scalar s = s1 * s2 (mod L) and the signing 344 public key A = ScalarMult(A1, s2). 346 4. Compute the signing prefix as concat(prefix1, prefix2). 348 5. Run the rest of the Sign procedure in [RFC8032], Section 5.2.6 349 from step (2) onwards using the modified scalar s, public key A, 350 and string prefix. 352 6. ECDSA 354 [[DISCLAIMER: Multiplicative blinding for ECDSA is known to be NOT be 355 SUF-CMA-secure in the presence of an adversary that controls the 356 blinding value. [MSMHI15] describes this in the context of related- 357 key attacks. This variant may likely be removed in followup versions 358 of this document based on further analysis.]] 360 This section describes implementations of BlindPublicKey, 361 UnblindPublicKey, and BlindKeySign as functions implemented on top of 362 an existing [ECDSA] implementation. BlindKeyGen invokes the key 363 generation routine specified in [ECDSA] and outputs only the private 364 key. In the descriptions below, let p be the order of the 365 corresponding elliptic curve group used for ECDSA. For example, for 366 P-256, p = 1157920892103562487626974469494075735299969552241357603424 367 22259061068512044369. 369 6.1. BlindPublicKey and UnblindPublicKey 371 BlindPublicKey multiplies the public key pkS by an augmented private 372 key bk yielding a new public key pkR. UnblindPublicKey inverts this 373 process by multiplying the input public key by the multiplicative 374 inverse of the augmented bk. Augmentation here maps the private key 375 bk to another scalar using hash_to_field as defined in Section 5 of 376 [H2C], with DST set to "ECDSA Key Blind", L set to the value 377 corresponding to the target curve, e.g., 48 for P-256 and 72 for 378 P-384, expand_message_xmd with a hash function matching that used for 379 the corresponding digital signature algorithm, and prime modulus 380 equal to the order p of the corresponding curve. Letting 381 HashToScalar denote this augmentation process, BlindPublicKey and 382 UnblindPublicKey are then implemented as follows: 384 BlindPublicKey(pk, bk) = ScalarMult(pk, HashToScalar(bk)) 385 UnblindPublicKey(pk, bk) = ScalarMult(pk, ModInverse(HashToScalar(bk), p)) 387 6.2. BlindKeySign 389 BlindKeySign transforms the signing key skS by the private key bk 390 into a new signing key, skR, and then invokes the existing ECDSA 391 signing procedure. More specifically, skR = skS * HashToScalar(bk) 392 (mod p). 394 7. Security Considerations 396 The signature scheme extensions in this document aim to achieve 397 unforgeability and unlinkability. Informally, unforgeability means 398 that one cannot produce a valid (message, signature) pair for any 399 blinding key without access to the private signing key. Similarly, 400 unlinkability means that one cannot distinguish between two 401 signatures produced from two separate key signing keys, and two 402 signatures produced from the same signing key but with different 403 blinds. Security analysis of the extensions in this document with 404 respect to these two properties is currently underway. 406 Preliminary analysis has been done for a variant of these extensions 407 used for identity key blinding routine used in Tor's Hidden Service 408 feature [TORBLINDING]. For EdDSA, further analysis is needed to 409 ensure this is compliant with the signature algorithm described in 410 [RFC8032]. 412 The constructions in this document assume that both the signing and 413 blinding keys are private, and, as such, not controlled by an 414 attacker. [MSMHI15] demonstrate that ECDSA with attacker-controlled 415 multiplicative blinding for producing related keys can be abused to 416 produce forgeries. In particular, if an attacker can control the 417 private blinding key used in BlindKeySign, they can construct a 418 forgery over a different message that validates under a different 419 public key. One mitigation to this problem is to change BlindKeySign 420 such that the signature is computed over the input message as well as 421 the blind public key. However, this would require verifiers to treat 422 both the blind public key and message as input to their verification 423 interface. The construction in Section 6 does not require this 424 change. However, further analysis is needed to determine whether or 425 not this construction is safe. 427 8. IANA Considerations 429 This document has no IANA actions. 431 9. Test Vectors 433 This section contains test vectors for a subset of the signature 434 schemes covered in this document. 436 9.1. Ed25519 Test Vectors 438 This section contains test vectors for Ed25519 as described in 439 [RFC8032]. Each test vector lists the private key and blind seeds, 440 denoted skS and bk and encoded as hexadecimal strings, along with the 441 public key pkS corresponding to skS encoded has hexadecimal strings 442 according to [RFC8032], Section 5.1.2. Each test vector also 443 includes the blinded public key pkR computed from skS and bk, denoted 444 pkR and encoded has a hexadecimal string. Finally, each vector 445 includes the message and signature values, each encoded as 446 hexadecimal strings. 448 // Randomly generated private key and blind seed 449 skS: 875532ab039b0a154161c284e19c74afa28d5bf5454e99284bbcffaa71eebf45 450 pkS: 3b5983605b277cd44918410eb246bb52d83adfc806ccaa91a60b5b2011bc5973 451 bk: c461e8595f0ac41d374f878613206704978115a226f60470ffd566e9e6ae73bf 452 pkR: e52bbb204e72a816854ac82c7e244e13a8fcc3217cfdeb90c8a5a927e741a20f 453 message: 68656c6c6f20776f726c64 454 signature: f35d2027f14250c07b3b353359362ec31e13076a547c749a981d0135fce06 455 7a361ad6522849e6ed9f61d93b0f76428129b9eb3f9c3cd0bfa1bc2a086a5eebd09 457 // Randomly generated private key seed and zero blind seed 458 skS: f3348942e77a83943a6330d372e7531bb52203c2163a728038388ea110d1c871 459 pkS: ada4f42be4b8fa93ddc7b41ca434239a940b4b18d314fe04d5be0b317a861ddf 460 bk: 0000000000000000000000000000000000000000000000000000000000000000 461 pkR: 7b8dcabbdfce4f8ad57f38f014abc4a51ac051a4b77b345da45ee2725d9327d0 462 message: 68656c6c6f20776f726c64 463 signature: b38b9d67cb4182e91a86b2eb0591e04c10471c1866202dd1b3b076fb86a61 464 c7c4ab5d626e5c5d547a584ca85d44839c13f6c976ece0dcba53d82601e6737a400 466 9.2. ECDSA(P-384, SHA-384) Test Vectors 468 This section contains test vectors for ECDSA with P-384 and SHA-384, 469 as described in [ECDSA]. Each test vector lists the signing and 470 blinding keys, denoted skS and bk, each serialized as a big-endian 471 integers and encoded as hexadecimal strings. Each test vector also 472 blinded public key pkR, encoded as compressed elliptic curve points 473 according to [ECDSA]. Finally, each vector lists message and 474 signature values, where the message is encoded as a hexadecimal 475 string, and the signature value is serialized as the concatenation of 476 scalars (r, s) and encoded as a hexadecimal string. 478 // Randomly generated signing and blind private keys 479 skS: 0e1e4fcc2726e36c5a24be3d30dc6f52d61e6614f5c57a1ec7b829d8adb7c85f456 480 c30c652d9cd1653cef4ce4da9008d 481 pkS: 03c66e61f5e12c35568928d9a0ffbc145ee9679e17afea3fba899ed3f878f9e82a8 482 859ce784d9ff43fea2bc8e726468dd3 483 bk: 865b6b7fc146d0f488854932c93128c3ab3572b7137c4682cb28a2d55f7598df467 484 e890984a687b22c8bc60a986f6a28 485 pkR: 038defb9b698b91ee7f3985e54b57b519be237ced2f6f79408558ff7485bf2d60a2 486 4dc986b9145e422ea765b56de7c5956 487 message: 68656c6c6f20776f726c64 488 signature: 5e5643a8c22b274ec5f776e63ed23ff182c8c87642e35bd5a5f7455ae1a19 489 a9956795df33e2f8b30150904ef6ba5e7ee4f18cef026f594b4d21fc157552ce3cf6d7ef 490 c3226b8d8194fc93df1c7f5facafc96daab7c5a0d840fbd3b9342f2ddad 492 10. References 494 10.1. Normative References 496 [ECDSA] American National Standards Institute, "Public Key 497 Cryptography for the Financial Services Industry - The 498 Elliptic Curve Digital Signature Algorithm (ECDSA)", 499 ANSI ANS X9.62-2005, November 2005. 501 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 502 Requirement Levels", BCP 14, RFC 2119, 503 DOI 10.17487/RFC2119, March 1997, 504 . 506 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 507 Signature Algorithm (EdDSA)", RFC 8032, 508 DOI 10.17487/RFC8032, January 2017, 509 . 511 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 512 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 513 May 2017, . 515 10.2. Informative References 517 [AIRDROP] Wahby, R. S., Boneh, D., Jeffrey, C., and J. Poon, "An 518 airdrop that preserves recipient privacy", n.d., 519 . 521 [ESS21] Eaton, E., Stebila, D., and R. Stracovsky, "Post-Quantum 522 Key-Blinding for Authentication in Anonymity Networks", 523 2021, . 525 [H2C] Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R. S., 526 and C. A. Wood, "Hashing to Elliptic Curves", Work in 527 Progress, Internet-Draft, draft-irtf-cfrg-hash-to-curve- 528 14, 18 February 2022, 529 . 532 [MSMHI15] Morita, H., Schuldt, J., Matsuda, T., Hanaoka, G., and T. 533 Iwata, "On the Security of the Schnorr Signature Scheme 534 and DSA Against Related-Key Attacks", Information Security 535 and Cryptology - ICISC 2015 pp. 20-35, 536 DOI 10.1007/978-3-319-30840-1_2, 2016, 537 . 539 [RATELIMITED] 540 Hendrickson, S., Iyengar, J., Pauly, T., Valdez, S., and 541 C. A. Wood, "Rate-Limited Token Issuance Protocol", Work 542 in Progress, Internet-Draft, draft-privacypass-rate-limit- 543 tokens-02, 2 May 2022, 544 . 547 [TORBLINDING] 548 Hopper, N., "Proving Security of Tor’s Hidden Service 549 Identity Blinding Protocol", 2013, 550 . 552 [TORDIRECTORY] 553 "Tor directory protocol, version 3", n.d., 554 . 557 Acknowledgments 559 The authors would like to thank Dennis Jackson for helpful 560 discussions that informed the development of this draft. 562 Authors' Addresses 564 Frank Denis 565 Fastly Inc. 566 475 Brannan St 567 San Francisco, 568 United States of America 569 Email: fde@00f.net 571 Edward Eaton 572 University of Waterloo 573 200 University Av West 574 Waterloo 575 Canada 576 Email: ted@eeaton.ca 578 Christopher A. Wood 579 Cloudflare, Inc. 580 101 Townsend St 581 San Francisco, 582 United States of America 583 Email: caw@heapingbits.net