]> Fastly Inc.

475 Brannan St San Francisco United States of America fde@00f.net

University of Waterloo

200 University Av West Waterloo Canada ted@eeaton.ca

New York United States of America cfrg@tancre.de

Cloudflare, Inc.

101 Townsend St San Francisco United States of America caw@heapingbits.net

AREA WG Working Group Internet-Draft This document describes extensions to existing digital signature schemes for key blinding. The core property of signing with key blinding is that a blinded public key and all signatures produced using the blinded key pair are independent of the unblinded key pair. Moreover, signatures produced using blinded key pairs are indistinguishable from signatures produced using unblinded key pairs. This functionality has a variety of applications, including Tor onion services and privacy-preserving airdrop for bootstrapping cryptocurrency systems. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the CFRG Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Digital signature schemes allow a signer to sign a message using a private signing key and produce a digital signature such that anyone can verify the digital signature over the message with the public verification key corresponding to the signing key. Digital signature schemes typically consist of three functions:

• KeyGen: A function for generating a private signing key skS and the corresponding public verification key pkS.
• Sign(skS, msg): A function for signing an input message msg using a private signing key skS, producing a digital signature sig.
• Verify(pkS, msg, sig): A function for verifying the digital signature sig over input message msg against a public verification key pkS, yielding true if the signature is valid and false otherwise.

In some applications, it's useful for a signer to produce digital signatures using the same long-term private signing key such that a verifier cannot link any two signatures to the same signer. In other words, the signature produced is independent of the long-term private-signing key, and the public verification key for verifying the signature is independent of the long-term public verification key. This type of functionality has a number of practical applications, including, for example, in the Tor onion services protocol and privacy-preserving airdrop for bootstrapping cryptocurrency systems . It is also necessary for a variant of the Privacy Pass issuance protocol . One way to accomplish this is by signing with a private key which is a function of the long-term private signing key and a freshly chosen blinding key, and similarly by producing a public verification key which is a function of the long-term public verification key and the same blinding key. A signature scheme with this functionality is referred to as signing with key blinding. A signature scheme with key blinding aims to achieve unforgeability and unlinkability. Informally, unforgeability means that one cannot produce a valid (message, signature) pair for any blinding key without access to the private signing key. Similarly, unlinkability means that one cannot distinguish between two signatures produced from two separate signing keys, and two signatures produced from the same signing key but with different blinding keys. This document describes extensions to EdDSA and ECDSA to enable signing with key blinding. Security analysis of these extensions is currently underway; see for more details. This functionality is also possible with other signature schemes, including some post-quantum signature schemes , though such extensions are not specified here.

DISCLAIMER This document is a work in progress and is still undergoing security analysis. As such, it MUST NOT be used for real world applications. See for additional information.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The following terms are used throughout this document to describe the blinding modification.

• G: The standard base point.
• sk: A signature scheme private key. For EdDSA, this is a randomly generated private seed of length 32 bytes or 57 bytes according to or , respectively. For , sk is a random scalar in the prime-order elliptic curve group.
• pk(sk): The public key corresponding to the private key sk.
• concat(x0, ..., xN): Concatenation of byte strings. concat(0x01, 0x0203, 0x040506) = 0x010203040506.
• ScalarMult(pk, k): Multiply the public key pk by scalar k, producing a new public key as a result.
• ModInverse(x, L): Compute the multiplicative inverse of x modulo L.

In pseudocode descriptions below, integer multiplication of two scalar values is denoted by the * operator. For example, the product of two scalars x and y is denoted as x * y.

Key Blinding At a high level, a signature scheme with key blinding allows signers to blind their private signing key such that any signature produced with a private signing key and blinding key is independent of the private signing key. Similar to the signing key, the blinding key is also a private key. For example, the blind is a 32-byte or 57-byte random seed for Ed25519 or Ed448 variants, respectively, whereas the blind for ECDSA over P-256 is a random value in the scalar field for the P-256 elliptic curve group. In more detail, consider first the basic digital signature syntax, which is a combination of the following functionalities:

• KeyGen: A function for generating a private and public key pair (skS, pkS).
• Sign(skS, msg): A function for signing a message msg with the given private key skS, producing a signature sig.
• Verify(pkS, msg, sig): A function for verifying a signature sig over message msg against the public key pkS, which returns 1 upon success and 0 otherwise.

Key blinding introduces three new functionalities for the signature scheme syntax:

• BlindKeyGen: A function for generating a private blind key.
• BlindPublicKey(pkS, bk, ctx): Blind the public verification key pkS using the private blinding key bk and context ctx, yielding a blinded public key pkR.
• BlindKeySign(skS, bk, ctx, msg): Sign a message msg using the private signing key skS with the private blind key bk and context ctx.

For a given bk produced from BlindKeyGen, key pair (skS, pkS) produced from KeyGen, a context value ctx, and message msg, correctness requires the following equivalence to hold with overwhelming probability: Security requires that signatures produced using BlindKeySign are unlinkable from signatures produced using the standard signature generation function with the same private key. When the context value is known, a signature scheme with key blinding may also support the ability to unblind public keys. This is represented with the following function.

• UnblindPublicKey(pkR, bk, ctx): Unblind the public verification key pkR using the private blinding key bk and context ctx.

For a given bk produced from BlindKeyGen, (skS, pkS) produced from KeyGen, and context value ctx, correctness of this function requires the following equivalence to hold: Considerations for choosing context strings are discussed in .

Ed25519ph, Ed25519ctx, and Ed25519 This section describes implementations of BlindPublicKey, UnblindPublicKey, and BlindKeySign as modifications of routines in . BlindKeyGen invokes the key generation routine specified in and outputs only the private key. This section assumes a context value ctx has been configured or otherwise chosen by the application.

BlindPublicKey and UnblindPublicKey BlindPublicKey transforms a private blind bk into a scalar for the edwards25519 group and then multiplies the target key by this scalar. UnblindPublicKey performs essentially the same steps except that it multiplies the target public key by the multiplicative inverse of the scalar, where the inverse is computed using the order of the group L, described in . More specifically, BlindPublicKey(pk, bk, ctx) works as follows.

1. Construct the blind_ctx as concat(bk, 0x00, ctx), where bk is a 32-byte octet string, hash the result using SHA-512(blind_ctx), and store the digest in a 64-octet large buffer, denoted b. Interpret the lower 32 bytes buffer as a little-endian integer, forming a secret scalar s. Note that this explicitly skips the buffer pruning step in .
2. Perform a scalar multiplication ScalarMult(pk, s), and output the encoding of the resulting point as the public key.

UnblindPublicKey(pkR, bk, ctx) works as follows.

1. Compute the secret scalar s from bk and ctx as in BlindPublicKey.
2. Compute the sInv = ModInverse(s, L), where L is as defined in .
3. Perform a scalar multiplication ScalarMult(pk, sInv), and output the encoding of the resulting point as the public key.

BlindKeySign BlindKeySign transforms a private key bk into a scalar for the edwards25519 group and a message prefix to blind both the signing scalar and the prefix of the message used in the signature generation routine. More specifically, BlindKeySign(skS, bk, ctx, msg) works as follows:

1. Hash the private key skS, 32 octets, using SHA-512. Let h denote the resulting digest. Construct the secret scalar s1 from the first half of the digest, and the corresponding public key A1, as described in . Let prefix1 denote the second half of the hash digest, h[32],...,h[63].
2. Construct the blind_ctx as concat(bk, 0x00, ctx), where bk is a 32-byte octet string, hash the result using SHA-512(blind_ctx), and store the digest in a 64-octet large buffer, denoted b. Interpret the lower 32 bytes buffer as a little-endian integer, forming a secret scalar s2. Note that this explicitly skips the buffer pruning step in . Let prefix2 denote the second half of the hash digest, b[32],...,b[63].
3. Compute the signing scalar s = s1 * s2 (mod L) and the signing public key A = ScalarMult(G, s).
4. Compute the signing prefix as concat(prefix1, prefix2).
5. Run the rest of the Sign procedure in from step (2) onwards using the modified scalar s, public key A, and string prefix.

Ed448ph and Ed448 This section describes implementations of BlindPublicKey, UnblindPublicKey, and BlindKeySign as modifications of routines in . BlindKeyGen invokes the key generation routine specified in and outputs only the private key. This section assumes a context value ctx has been configured or otherwise chosen by the application.

BlindPublicKey and UnblindPublicKey BlindPublicKey and UnblindPublicKey for Ed448ph and Ed448 are implemented just as these routines are for Ed25519ph, Ed25519ctx, and Ed25519, except that SHAKE256 is used instead of SHA-512 for hashing the secret blind context, i.e., the concatenation of blind key bk and context ctx, to a 114-byte buffer (and using the lower 57-bytes for the secret), and the order of the edwards448 group L is as defined in . Note that this process explicitly skips the buffer pruning step in .

BlindKeySign BlindKeySign for Ed448ph and Ed448 is implemented just as this routine for Ed25519ph, Ed25519ctx, and Ed25519, except in how the scalars (s1, s2), public keys (A1, A2), and message strings (prefix1, prefix2) are computed. More specifically, BlindKeySign(skS, bk, ctx, msg) works as follows:

1. Hash the private key skS, 57 octets, using SHAKE256(skS, 117). Let h1 denote the resulting digest. Construct the secret scalar s1 from the first half of h1, and the corresponding public key A1, as described in . Let prefix1 denote the second half of the hash digest, h1[57],...,h1[113].
2. Construct the blind_ctx as concat(bk, 0x00, ctx), where bk is a 57-byte octet string, hash the result using SHAKE256(blind_ctx, 117), and store the digest in a 117-octet digest, denoted h2. Interpret the lower 57 bytes buffer as a little-endian integer, forming a secret scalar s2. Note that this explicitly skips the buffer pruning step in . Let prefix2 denote the second half of the hash digest, h2[57],...,h2[113].
3. Compute the signing scalar s = s1 * s2 (mod L) and the signing public key A = ScalarMult(A1, s2).
4. Compute the signing prefix as concat(prefix1, prefix2).
5. Run the rest of the Sign procedure in from step (2) onwards using the modified scalar s, public key A, and string prefix.

ECDSA [[DISCLAIMER: Multiplicative blinding for ECDSA is known to NOT be SUF-CMA-secure in the presence of an adversary that controls the blinding value. describes this in the context of related-key attacks. This variant may likely be removed in followup versions of this document based on further analysis.]] This section describes implementations of BlindPublicKey, UnblindPublicKey, and BlindKeySign as functions implemented on top of an existing implementation. BlindKeyGen invokes the key generation routine specified in and outputs only the private key. In the descriptions below, let p be the order of the corresponding elliptic curve group used for ECDSA. For example, for P-256, p = 115792089210356248762697446949407573529996955224135760342422259061068512044369. This section assumes a context value ctx has been configured or otherwise chosen by the application.

BlindPublicKey and UnblindPublicKey BlindPublicKey multiplies the public key pkS by an augmented private key bk yielding a new public key pkR. UnblindPublicKey inverts this process by multiplying the input public key by the multiplicative inverse of the augmented bk. Augmentation here maps the private key bk to another scalar using hash_to_field as defined in , with DST set to "ECDSA Key Blind", L set to the value corresponding to the target curve, e.g., 48 for P-256 and 72 for P-384, expand_message_xmd with a hash function matching that used for the corresponding digital signature algorithm, and prime modulus equal to the order p of the corresponding curve. Letting HashToScalar denote this augmentation process, and blind_ctx = concat(bk, 0x00, ctx), BlindPublicKey and UnblindPublicKey are then implemented as follows:

BlindKeySign BlindKeySign transforms the signing key skS by the private key bk along with context ctx into a new signing key, skR, and then invokes the existing ECDSA signing procedure. More specifically, skR = skS * HashToScalar(blind_ctx) (mod p), where blind_ctx = concat(bk, 0x00, ctx).

Application Considerations Choice of the context string ctx is application-specific. For example, in Tor , the context string is set to the concatenation of the long-term signer public key and an integer epoch. This makes it so that unblinding a blinded public key requires knowledge of the long-term public key as well as the blinding key. Similarly, in a rate-limited version of Privacy Pass , the context is empty, thereby allowing unblinding by anyone in possession of the blinding key. Applications are RECOMMENDED to choose context strings that are distinct from other protocols as a way of enforcing domain separation. See for additional discussion around the construction of suitable domain separation values.

Security Considerations The signature scheme extensions in this document aim to achieve unforgeability and unlinkability. Informally, unforgeability means that one cannot produce a valid (message, signature) pair for any blinding key without access to the private signing key. Similarly, unlinkability means that one cannot distinguish between two signatures produced from two independent signing keys, and two signatures produced from the same signing key but with different blinds. Security analysis of the extensions in this document with respect to these two properties is currently underway. See for more detailed discussion of signature extensions with these properties. Preliminary analysis has been done for a variant of these extensions used for the identity key blinding routine used in Tor's Hidden Service feature . Further analysis exists in , which demonstrates that the extensions in this specification for EdDSA and ECDSA both achieve the desired security properties. The constructions in this document, as well as the analysis in , assume that both the signing and blinding keys are private, and, as such, not controlled by an attacker. demonstrate that ECDSA with attacker-controlled multiplicative blinding for producing related keys can be abused to produce forgeries. In particular, if an attacker can control the private blinding key used in BlindKeySign, they can construct a forgery over a different message that validates under a different public key. One mitigation to this problem is to change BlindKeySign such that the signature is computed over the input message as well as the blind public key. However, this would require verifiers to treat both the blind public key and message as input to their verification interface. The construction in does not require this change. However, further analysis is needed to determine whether or not this construction is safe.

IANA Considerations This document has no IANA actions.

Test Vectors This section contains test vectors for a subset of the signature schemes covered in this document.

Ed25519 Test Vectors This section contains test vectors for Ed25519 as described in . Each test vector lists the serialized signing key (skS), blind key (bk), and public key (pkS) encoded as hexadecimal strings; skS and bk are serialized as little-endian 32-byte encoding of the scalar value with the top three bits set to zero, whereas pkS is serialized as described in . Each test vector also includes the blinded public key (pkR) computed from skS and bk, serialized similarly to pkS and encoded as a hexadecimal string. Finally, each vector includes the message and signature values, each encoded as hexadecimal strings. The signature is encoded as specified in .

ECDSA(P-384, SHA-384) Test Vectors This section contains test vectors for ECDSA with P-384 and SHA-384, as described in . Each test vector lists the serialized signing key (skS), blind key (bk), and public key (pkS) encoded as hexadecimal strings; skS and bk are serialized using the Field-Element-to-Octet-String conversion according to , whereas pkS is serialized using the compressed Elliptic-Curve-Point-to-Octet-String method according to . Each test vector also includes the blinded public key (pkR) computed from skS and bk, serialized similarly to pkS and encoded as a hexadecimal string. Finally, each vector includes the message and signature values, each encoded as hexadecimal strings. The signature value is serialized as the concatenation of scalars (r, s), each serialized as skS and bk, and encoded as a hexadecimal string.

References Normative References American National Standards Institute This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Cloudflare, Inc. Cornell Tech Cloudflare, Inc. Stanford University Cloudflare, Inc. This document specifies a number of algorithms for encoding or hashing an arbitrary string to a point on an elliptic curve. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. Informative References Brave Software Brown University CISPA Helmholtz Center for Information Security NTT Social Informatics Laboratories AIT Austrian Institute of Technology National Research Council Canada Amazon Web Services Cloudflare, Inc. n.d. n.d. Google LLC Fastly Apple Inc. Google LLC Cloudflare This document specifies a variant of the Privacy Pass issuance protocol that allows for tokens to be rate-limited on a per-origin basis. This enables origins to use tokens for use cases that need to restrict access from anonymous clients. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tfpauly/privacy-proxy. Springer International Publishing Cloudflare, Inc. Cornell Tech Cloudflare, Inc. Stanford University Cloudflare, Inc. This document specifies a number of algorithms for encoding or hashing an arbitrary string to a point on an elliptic curve. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.

Acknowledgments The authors would like to thank Dennis Jackson and Cathie Yun for helpful discussions and input that informed and improved the development of this draft.