]> Fastly Inc.

fd@00f.net

Apple Inc.

frederic.jacobs@apple.com

Cloudflare

caw@heapingbits.net

Internet-Draft This document specifies an RSA-based blind signature protocol. RSA blind signatures were first introduced by Chaum for untraceable payments. A signature that is output from this protocol can be verified as an RSA-PSS signature. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. Discussion Venues Source for this draft and an issue tracker can be found at .

Introduction Originally introduced in the context of digital cash systems by Chaum for untraceable payments , RSA blind signatures turned out to have a wide range of applications ranging from privacy-preserving digital payments to authentication mechanisms . Recently, interest in blind signatures has grown to address operational shortcomings from applications that use Verifiable Oblivious Pseudorandom Functions (VOPRFs) , such as Privacy Pass . Specifically, VOPRFs are not necessarily publicly verifiable, meaning that a verifier needs access to the VOPRF private key to verify that the output of a VOPRF protocol is valid for a given input. This limitation complicates deployments where it is not desirable to distribute private keys to entities performing verification. Additionally, if the private key is kept in a Hardware Security Module, the number of operations on the key is doubled compared to a scheme where only the public key is required for verification. In contrast, digital signatures provide a primitive that is publicly verifiable and does not require access to the private key for verification. Moreover, shows that one can realize a VOPRF in the Random Oracle Model by hashing a signature-message pair, where the signature is computed using a deterministic blind signature protocol. This document specifies a protocol for computing the RSA blind signatures using RSA-PSS encoding, and a family of variants for this protocol, denoted RSABSSA. In order to facilitate deployment, it is defined in such a way that the resulting (unblinded) signature can be verified with a standard RSA-PSS library. This document represents the consensus of the Crypto Forum Research Group (CFRG). It is not an IETF product and is not a standard.

Requirements Notation 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.

Notation The following terms are used throughout this document to describe the protocol operations in this document:

• bytes_to_int and int_to_bytes: Convert a byte string to and from a non-negative integer. bytes_to_int and int_to_bytes are implemented as OS2IP and I2OSP as described in , respectively. Note that these functions operate on byte strings in big-endian byte order.
• random_integer_uniform(M, N): Generate a random, uniformly distributed integer R between M inclusive and N exclusive, i.e., M <= R < N.
• bit_len(n): Compute the minimum number of bits needed to represent the positive integer n.
• inverse_mod(x, n): Compute the multiplicative inverse of x mod n or fail if x and n are not co-prime.
• len(s): The length of a byte string, in bytes.
• random(n): Generate n random bytes using a cryptographically-secure random number generator.
• concat(x0, ..., xN): Concatenation of byte strings. For example, concat(0x01, 0x0203, 0x040506) = 0x010203040506.
• slice(x, i, j): Return bytes in the byte string x starting from offset i and ending at offset j, inclusive. For example, slice(0x010203040506, 1, 5) = 0x0203040506.

Blind Signature Protocol The RSA Blind Signature Protocol is a two-party protocol between a client and server where they interact to compute sig = Sign(skS, input_msg), where input_msg = Prepare(msg) is a prepared version of the private message msg provided by the client, and skS is the signing key provided by the server. See for details on how skS is generated and used in this protocol. Upon completion of this protocol, the server learns nothing, whereas the client learns sig. In particular, this means the server learns nothing of msg or input_msg and the client learns nothing of skS. The protocol consists of four functions -- Prepare, Blind, BlindSign, and Finalize -- and requires one round of interaction between client and server. Let msg be the client's private input message, and (skS, pkS) be the server's private and public key pair. The protocol begins by the client preparing the message to be signed by computing: The client then initiates the blind signature protocol by computing: The client then sends blinded_msg to the server, which then processes the message by computing: The server then sends blind_sig to the client, which then finalizes the protocol by computing: The output of the protocol is input_msg and sig. Upon completion, correctness requires that clients can verify signature sig over the prepared message input_msg using the server public key pkS by invoking the RSASSA-PSS-VERIFY routine defined in . The Finalize function performs this check before returning the signature. See for more details about verifying signatures produced through this protocol. In pictures, the protocol runs as follows: blind_sig = BlindSign(skS, blinded_msg) blind_sig <---------- sig = Finalize(pkS, input_msg, blind_sig, inv) ]]> In the remainder of this section, we specify the Prepare, Blind, BlindSign, and Finalize functions that are used in this protocol.

Prepare Message preparation, denoted by the Prepare function, is the process by which the message to be signed and verified is prepared for input to the blind signing protocol. There are two types of preparation functions: an identity preparation function, and a randomized preparation function. The identity preparation function returns the input message without transformation, i.e., msg = PrepareIdentity(msg). The randomized preparation function augments the input message with fresh randomness. We denote this process by the function PrepareRandomize(msg), which takes as input a message msg and produces a randomized message input_msg. Its implementation is shown below.

Blind The Blind function encodes an input message and blinds it with the server's public key. It outputs the blinded message to be sent to the server, encoded as a byte string, and the corresponding inverse, an integer. RSAVP1 and EMSA-PSS-ENCODE are as defined in Sections and of , respectively. If this function fails with an "invalid blind" error, implementations SHOULD retry the function again. The probability of one or more such errors in sequence is negligible. See for more information about dealing with such errors. Note that this function invokes RSAVP1, which is defined to throw an optional error for invalid inputs. However, this error cannot occur based on how RSAVP1 is invoked, so this error is not included in the list of errors for Blind. The blinding factor r MUST be randomly chosen from a uniform distribution. This is typically done via rejection sampling.

BlindSign BlindSign performs the RSA private key operation on the client's blinded message input and returns the output encoded as a byte string. RSASP1 is as defined in .

Finalize Finalize validates the server's response, unblinds the message to produce a signature, verifies it for correctness, and outputs the signature upon success. Note that this function will internally hash the input message as is done in Blind.

Verification As described in , the output of the protocol is the prepared message input_msg and the signature sig. The message that applications consume is msg, from which input_msg is derived. Clients verify the msg signature using the server's public key pkS by invoking the RSASSA-PSS-VERIFY routine defined in with (n, e) as pkS, M as input_msg, and S as sig. Verification and the message that applications consume therefore depends on which preparation function is used. In particular, if the PrepareIdentity function is used, then the application message is input_msg. In contrast, if the PrepareRandomize function is used, then the application message is slice(input_msg, 32, len(input_msg)), i.e., the prepared message with the random prefix removed.

RSABSSA Variants In this section we define different named variants of RSABSSA. Each variant specifies RSASSA-PSS parameters as defined in and the type of message preparation function applied (as described in ). Each variant uses the MGF1 Mask Generation Function defined in . Future specifications can introduce other variants as desired. The named variants are as follows:

1. RSABSSA-SHA384-PSS-Randomized: This named variant uses SHA-384 as the hash function, MGF1 with SHA-384 as the PSS mask generation function, a 48-byte salt length, and uses the randomized preparation function (PrepareRandomize).
2. RSABSSA-SHA384-PSSZERO-Randomized: This named variant uses SHA-384 as the hash function, MGF1 with SHA-384 as the PSS mask generation function, an empty PSS salt, and uses the randomized preparation function (PrepareRandomize).
3. RSABSSA-SHA384-PSS-Deterministic: This named variant uses SHA-384 as the hash function, MGF1 with SHA-384 as the PSS mask generation function, 48-byte salt length, and uses the identity preparation function (PrepareIdentity).
4. RSABSSA-SHA384-PSSZERO-Deterministic: This named variant uses SHA-384 as the hash function, MGF1 with SHA-384 as the PSS mask generation function, an empty PSS salt, and uses the identity preparation function (PrepareIdentity). This is the only variant that produces deterministic signatures over the client's input message msg.

The RECOMMENDED variants are RSABSSA-SHA384-PSS-Randomized or RSABSSA-SHA384-PSSZERO-Randomized. Not all named variants can be used interchangeably. In particular, applications that provide high-entropy input messages can safely use named variants without randomized message preparation, as the additional message randomization does not offer security advantages. See and for more information. For all other applications, the variants that use the randomized preparation function protect clients from malicious signers. A verifier that accepts randomized messages needs to remove the random component from the signed part of messages before processing. Applications that require deterministic signatures can use the RSABSSA-SHA384-PSSZERO-Deterministic variant, but only if their input messages have high entropy. Applications that use RSABSSA-SHA384-PSSZERO-Deterministic SHOULD carefully analyze the security implications, taking into account the possibility of adversarially generated signer keys as described in . When it is not clear whether an application requires deterministic or randomized signatures, applications SHOULD use one of the variants with randomized message preparation.

Implementation and Usage Considerations This section documents considerations for interfaces to implementations of the protocol in this document. This includes error handling and API considerations.

Errors The high-level functions specified in are all fallible. The explicit errors generated throughout this specification, along with the conditions that lead to each error, are listed in the definitions for Blind, BlindSign, and Finalize. These errors are meant as a guide for implementors. They are not an exhaustive list of all the errors an implementation might emit. For example, implementations might run out of memory. Moreover, implementations can handle errors as needed or desired. Where applicable, this document provides guidance for how to deal with explicit errors that are generated in the protocol. For example, the "invalid blind" error that is generated in Blind occurs when the client generates a prime factor of the server's public key. indicates that implementations SHOULD retry the Blind function when this error occurs, but an implementation could also handle this exceptional event differently, e.g., by informing the server that the key has been factored.

Signing Key Generation and Usage The RECOMMENDED method for generating the server signing key pair is as specified in FIPS 186-4 . A server signing key MUST NOT be reused for any other protocol beyond RSABSSA. Moreover, a server signing key MUST NOT be reused for different RSABSSA encoding options. That is, if a server supports two different encoding options, then it MUST have a distinct key pair for each option. If the server public key is carried in an X.509 certificate, it MUST use the RSASSA-PSS OID . It MUST NOT use the rsaEncryption OID .

Security Considerations Lysyanskaya proved one-more-forgery polynomial security of RSABSSA variants in the random oracle model under the one-more-RSA assumption in . This means the adversary cannot output n+1 valid message and signature tuples, where all messages are distinct, after interacting with the server (signer) as a client only n times, for some n which is polynomial in the protocol's security parameter. Lysyanskaya also proved that the RSABSSA variants which use the PrepareRandomize function achieve blindness in . Blindness means that the malicious signer learns nothing about the client input and output after the protocol execution. However, additional assumptions on the message inputs are required for blindness to hold for RSABSSA variants that use the PrepareIdentity function; see for more discussion on those results.

Timing Side Channels and Fault Attacks BlindSign is functionally a remote procedure call for applying the RSA private key operation. As such, side channel resistance is paramount to protect the private key from exposure . Implementations SHOULD implement some form of side channel attack mitigation, such as RSA blinding as described in Section 10 of . Failure to apply such mitigations can lead to side channel attacks that leak the private signing key. Moreover, we assume that the server does not initiate the protocol and therefore has no knowledge of when the Prepare and Blind operations take place. If this were not the case, additional side-channel mitigations might be required to prevent timing side channels through Prepare and Blind. Beyond timing side channels, describes the importance of implementation safeguards that protect against fault attacks that can also leak the private signing key. These safeguards require that implementations check that the result of the private key operation when signing is correct, i.e., given s = RSASP1(skS, m), verify that m = RSAVP1(pkS, s), as is required by BlindSign. Applying this (or equivalent) safeguard is necessary to mitigate fault attacks, even for implementations that are not based on the Chinese remainder theorem.

Message Robustness An essential property of blind signature protocols is that the signer learns nothing of the message being signed. In some circumstances, this may raise concerns of arbitrary signing oracles. Applications using blind signature protocols should take precautions to ensure that such oracles do not cause cross-protocol attacks. Ensuring that the signing key used for RSABSSA is distinct from other protocols prevents such cross-protocol attacks. An alternative solution to this problem of message blindness is to give signers proof that the message being signed is well-structured. Depending on the application, zero knowledge proofs could be useful for this purpose. Defining such a proof is out of scope for this document. Verifiers should check that, in addition to signature validity, the signed message is well-structured for the relevant application. For example, if an application of this protocol requires messages to be structures of a particular form, then verifiers should check that messages adhere to this form.

Message Entropy As discussed in , a malicious signer can construct an invalid public key and use it to learn information about low-entropy input messages. Note that some invalid public keys may not yield valid signatures when run with the protocol, e.g., because the signature fails to verify. However, if an attacker can coerce the client to use these invalid public keys with low-entropy inputs, they can learn information about the client inputs before the protocol completes. A client that uses this protocol might be vulnerable to attack from a malicious signer unless it is able to ensure that either:

1. The client has proof that the signer's public key is honestly generated. presents some (non-interactive) honest-verifier zero-knowledge proofs of various statements about the public key.
2. The input message has a value that the signer is unable to guess. That is, the client has added a high-entropy component that was not available to the signer prior to them choosing their signing key.

The named variants that use the PrepareRandomize function -- RSABSSA-SHA384-PSS-Randomized and RSABSSA-SHA384-PSSZERO-Randomized -- explicitly inject fresh entropy alongside each message to satisfy condition (2). As such, these variants are safe for all application use cases. Note that these variants effectively mean that the resulting signature is always randomized. As such, this interface is not suitable for applications that require deterministic signatures.

Randomness Generation All random values in the protocol, including the salt, message randomizer prefix, and random blind value in Blind, MUST be generated from a cryptographically secure random number generator . If these values are not generated randomly, or are otherwise constructed maliciously, it might be possible for them to encode information that is not present in the signed message. For example, the PSS salt might be maliciously constructed to encode the local IP address of the client. As a result, implementations SHOULD NOT allow clients to provide these values directly. Note that malicious implementations could also encode client information in the message being signed, but since clients can verify the resulting message signature using the public key this can be detected.

Key Substitution Attacks RSA is well known to permit key substitution attacks, wherein an attacker generates a key pair (skA, pkA) that verifies some known (message, signature) pair produced under a different (skS, pkS) key pair . This means it may be possible for an attacker to use a (message, signature) pair from one context in another. Entities that verify signatures must take care to ensure a (message, signature) pair verifies with a valid public key from the expected issuer.

Alternative RSA Encoding Functions This document document uses PSS encoding as specified in for a number of reasons. First, it is recommended in recent standards, including TLS 1.3 , X.509v3 , and even PKCS#1 itself. According to , "Although no attacks are known against RSASSA-PKCS#1 v1.5, in the interest of increased robustness, RSA-PSS is recommended for eventual adoption in new applications." While RSA-PSS is more complex than RSASSA-PKCS#1 v1.5 encoding, ubiquity of RSA-PSS support influenced the design decision in this draft, despite PKCS#1 v1.5 having equivalent security properties for digital signatures . Full Domain Hash (FDH) encoding is also possible, and this variant has equivalent security to PSS . However, FDH is less standard and not used widely in related technologies. Moreover, FDH is deterministic, whereas PSS supports deterministic and probabilistic encodings.

Post-Quantum Readiness The blind signature protocol specified in this document is not post-quantum ready since it is based on RSA. Shor's polynomial-time factorization algorithm readily applies.

IANA Considerations This document makes no IANA requests.

References Normative References 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. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes. This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 3447. This document updates RFC 4055. It updates the conventions for using the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm in the Internet X.509 Public Key Infrastructure (PKI). Specifically, it updates the conventions for algorithm parameters in an X.509 certificate's subjectPublicKeyInfo field. [STANDARDS-TRACK] Informative References n.d. n.d. n.d. International Workshop on Public Key Cryptography UC Irvine, CA, USA University of Athens, Greece IBM Research, NY, USA n.d. University of California, Santa Barbara, USA Stanford University Stanford University 12th Usenix Security Symposium University of Washington University of Washington Microsoft Brave Software Cloudflare, Inc. Cloudflare, Inc. Cloudflare, Inc. An Oblivious Pseudorandom Function (OPRF) is a two-party protocol between client and server for computing the output of a Pseudorandom Function (PRF). The server provides the PRF secret key, and the client provides the PRF input. At the end of the protocol, the client learns the PRF output without learning anything about the PRF secret key, and the server learns neither the PRF input nor output. An OPRF can also satisfy a notion of 'verifiability', called a VOPRF. A VOPRF ensures clients can verify that the server used a specific private key during the execution of the protocol. A VOPRF can also be partially-oblivious, called a POPRF. A POPRF allows clients and servers to provide public input to the PRF computation. This document specifies an OPRF, VOPRF, and POPRF instantiated within standard prime-order groups, including elliptic curves. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. Brave Software Brave Software Cloudflare Google LLC Cloudflare This document specifies two variants of the two-message issuance protocol for Privacy Pass tokens: one that produces tokens that are privately verifiable using the issuance private key, and another that produces tokens that are publicly verifiable using the issuance public key. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document supplements RFC 3279. It describes the conventions for using the RSA Probabilistic Signature Scheme (RSASSA-PSS) signature algorithm, the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm and additional one-way hash functions with the Public-Key Cryptography Standards (PKCS) #1 version 1.5 signature algorithm in the Internet X.509 Public Key Infrastructure (PKI). Encoding formats, algorithm identifiers, and parameter formats are specified. [STANDARDS-TRACK] Paderborn Uninversity, Paderborn, Germany Paderborn University, Paderborn, Germany Ruhr-University Bochum, Bochum, Germany

Test Vectors This section includes test vectors for the blind signature protocol defined in . The following parameters are specified for each test vector:

• p, q, n, e, d: RSA private and public key parameters, each encoded as a hexadecimal string.
• msg: Input messsage being signed, encoded as a hexadecimal string. The hash is computed using SHA-384.
• msg_prefix: Message randomizer prefix, encoded as a hexadecimal string. This is only present for variants that use the randomization preparation function.
• random_msg: The message actually signed. If the variant does not use the randomization preparation function, this is equal to msg.
• salt: Randomly-generated salt used when computing the signature. The length is either 48 or 0 bytes.
• encoded_msg: EMSA-PSS encoded message. The mask generation function is MGF1 with SHA-384.
• inv: The message blinding inverse, encoded as a hexadecimal string.
• blinded_msg, blind_sig: The protocol values exchanged during the computation, encoded as hexadecimal strings.
• sig: The output message signature.

RSABSSA-SHA384-PSS-Randomized Test Vector

RSABSSA-SHA384-PSSZERO-Randomized Test Vector

RSABSSA-SHA384-PSS-Deterministic Test Vector

RSABSSA-SHA384-PSSZERO-Deterministic Test Vector

Acknowledgments We would like to thank Bjoern Tackmann who provided an editorial and security review of this document.