]> Fastly Inc.

fd@00f.net

Apple Inc.

frederic.jacobs@apple.com

Cloudflare

caw@heapingbits.net

Internet-Draft This document specifies the RSA-based blind signature protocol with appendix (RSA-BSSA). RSA blind signatures were first introduced by Chaum for untraceable payments . It extends RSA-PSS encoding specified in to enable blind signature support. 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 electric voting schemes to authentication mechanisms. Recently, interest in blind signatures has grown to address operational shortcomings from VOPRFs such as . Specifically, VOPRF evaluation requires access to the private key, and is therefore required for both issuance and redemption of tokens in anonymous authentication protocols such as Privacy Pass . This limitation complicates deployments where it is not desirable to distribute secret keys to entities performing token 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 the private key is only required for issuance of the tokens. In contrast, cryptographic 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 (deterministic) blind signature-message pair. This document specifies a protocol for the RSA Blind Signature Scheme with Appendix (RSABSSA). In order to facilitate deployment, we define it in such a way that the resulting (unblinded) signature can be verified with a standard RSA-PSS library.

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 such that M <= R < N.
• inverse_mod(x, n): Compute the multiplicative inverse of x mod n. This function fails if x and n are not co-prime.
• len(s): The length of a byte string, in octets.
• random(n): Generate n random octets using a cryptographically-secure pseudorandom number generator.

Blind Signature Protocol Overview In this section, we sketch the blind signature protocol wherein a client and server interact to compute sig = Sign(skS, msg), where msg is the private message to be signed, and skS is the server's private key. In this protocol, the server learns nothing of msg, whereas the client learns sig and nothing of skS. The core issuance protocol runs as follows: blind_sig = BlindSign(skS, blinded_msg) blind_sig <---------- sig = Finalize(pkS, msg, blind_sig, inv) ]]> Upon completion, correctness requires that clients can verify signature sig over private input message msg using the server public key pkS by invoking the RSASSA-PSS-VERIFY routine defined in . The finalization function performs that check before returning the signature.

RSABSSA Signature Instantiation Section 8.1 of defines RSASSA-PSS RSAE, which is a signature algorithm using RSASSA-PSS with mask generation function 1. In this section, we define RSABSSA, a blinded variant of this algorithm.

Signature Generation As outlined in , signature generation involves three subroutines: Blind, BlindSign, and Finalize. The output from Finalize is a signature over the input to Blind. A specification of these subroutines is below.

Blind rsabssa_blind encodes an input message and blinds it with the server's public key. It outputs the blinded message to be sent to the server and the corresponding inverse, both encoded as octet strings. RSAVP1 and EMSA-PSS-ENCODE are as defined in . The blinding factor r must be randomly chosen from a uniform distribution. This is typically done via rejection sampling.

BlindSign rsabssa_blind_sign performs the RSA private key operation on the client's blinded message input and returns the output encoded as an octet string. RSASP1 is as defined in . = n, raise "invalid message length" and stop 4. s = RSASP1(skS, m) 5. blind_sig = int_to_bytes(s, kLen) 6. output blind_sig ]]>

Finalize rsabssa_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 rsabssa_blind.

External Application Interface This section presents an application interface for blinding, finalizing, and verifying messages that is build on the internal functions described in . This interface injects additional entropy into application messages by choosing a random salt of length 32 bytes, prepending the salt to the input message, and then invoking the internal functions in . Note that this only changes what is passed to rsabssa_blind and rsabssa_finalize, as the application message is not provided as input to rsabssa_blindsign. Applications that provide high-entropy input messages can expose the internal rsabssa_blind and rsabssa_finalize directly, as the additional message randomization does not offer security advantages. See , , and for more information.

Salted Blind rsabssa_salted_blind invokes rsabssa_blind with a salted input message and outputs the blinded message to be sent to the server and the corresponding inverse, both encoded as octet strings, as well as the fresh message salt, which is 32 random bytes.

Salted Finalize rsabssa_salted_finalize invokes rsabssa_finalize directly with the salted message and outputs the result.

Salted Verify rsabssa_salted_verify validates the resulting unblinded signature computed over a salted message. It invokes RSASSA-PSS-VERIFY directly by augmenting the input message with the message salt.

Encoding Options The RSASSA-PSS parameters, defined as in , are as follows:

• Hash: hash function
• MGF: mask generation function
• sLen: intended length in octets of the salt

Implementations that expose the interface in are RECOMMENDED to support SHA-384 as Hash and MGF functions and sLen = 48, as described in . Implementations that expose the internal interface in are also RECOMMENDED to support SHA-384 as Hash and MGF functions and sLen = 0. Note that setting sLen = 0 has the result of making the signature deterministic. The blinded functions in are orthogonal to the choice of these encoding options.

Public Key Certification 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 .

Implementation 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 rsabssa_blind, rsabssa_blind_sign, and rsabssa_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.

API Considerations It is NOT RECOMMENDED that APIs allow clients to specify RSA-PSS parameters directly, e.g., to set the PSS salt value or its length. Instead, it is RECOMMENDED that implementations generate the PSS salt using the same source of randomness used to produce the blinding factor. If implementations need support for randommized and deterministic signatures, they should offer separate abstractions for each. Allowing callers to control the PSS salt value or length may have security consequences. See for more information about details.

Security Considerations Bellare et al. proved the following properties of Chaum's original blind signature protocol based on RSA-FDH:

• One-more-forgery polynomial security. This means the adversary, interacting with the server (signer) as a client, cannot output n+1 valid message and signature tuples after only interacting with the server n times, for some n which is polynomial in the protocol's security parameter.
• Concurrent polynomial security. This means that servers can engage in polynomially many invocations of the protocol without compromising security.

Both results rely upon the RSA Known Target Inversion Problem being hard. The design in this document differs from the analysis in only in message encoding, i.e., using PSS instead of FDH. Note, importantly, that an empty salt effectively reduces PSS to FDH, so the same results apply.

Timing Side Channels rsabssa_blind_sign 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 MUST implement RSA blinding as a side channel attack mitigation. One mechanism is described in Section 10 of . Failure to do so may lead to side channel attacks that leak the private signing key.

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. This can be done, for example, by keeping blind signature keys distinct from signature keys used for other protocols, such as TLS. 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 unblinded 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 unblinded messages adhere to this form.

Message Entropy As discussed in , the choice of blinding mechanism has security implications on the blindness properties of the blind RSA protocol. In particular, a malicious signer can construct an invalid public and use it to learn information about low-entropy with 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. Based on this fact, using the internal functions in is possibly unsafe, unless one of the following conditions are met:

1. The client has proof that the signer's public key is honestly generated. presents some (non-interactive) honest-verifier zero-knoweldge proofs of various statements about the public key.
2. The client input message has high entropy.

The interface in is designed to explicitly inject fresh entropy alongside each message to satisfy condition (2). As such, this interface is safe for all application use cases. Note that this interface effectively means that the resulting signature is always randomized. As such, this interface is not suitable for applications that require deterministic signatures. See for more details.

Randomized and Deterministic Signatures When sLen > 0, the PSS salt is a randomly generated string chosen when a message is encoded. This means the resulting signature is non-deterministic. As a result, two signatures over the same message will be different. If the salt is not generated randomly, or is otherwise constructed maliciously, it might be possible for the salt to encode information that is not present in the signed message. For example, the salt might be maliciously constructed to encode the local IP address of the client. As a result, APIs SHOULD NOT allow clients to provide the salt directly; see for API considerations. When sLen = 0, the PSS salt is empty and the resulting signature is deterministic. Such signatures may be useful for applications wherein the only desired source of entropy is the input message. Applications that use deterministic signatures SHOULD carefully analyze the security implications. When the required signature protocol is not clear, applications SHOULD default to randomized signatures, and the salted interface described in SHOULD be used.

Key Substitution Attacks RSA is well known to permit key substitution attacks, wherein an attacker generates a key pair (skA, pkA) that verify 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.

Alternative Blind Signature Protocols RSA has some advantages as a signature protocol, particularly around verification efficiency. However, the protocol in this document is not without shortcomings, including:

• RSA key and signature sizes are larger than those of alternative blind signature protocols;
• No evaluation batching support, which means that the cost of the protocol scales linearly with the number of invocations; and
• Extensions for features such as threshold signing are more complex to instantiate compared to other protocols based on, for example, Schnorr signatures.

There are a number of blind signature protocols beyond blind RSA. This section summarizes these at a high level, and discusses why an RSA-based variant was chosen for the basis of this specification, despite the shortcomings above.

• Blind Schnorr : This is a three-message protocol based on the classical Schnorr signature protocol over elliptic curve groups. Although simple, the hardness problem upon which this is based -- Random inhomogeneities in a Overdetermined Solvable system of linear equations, or ROS -- can be broken in polynomial time when a small number of concurrent signing sessions are invoked , leading to signature forgeries. Even with small concurrency limits, Wagner's generalized attack leads to subexponential forgery speedup. For example, a limit of 15 parallel sessions yields an attack runtime of approximately 2^55, which is substantially lower than acceptable security levels. In contrast, the variant in this specification has no such concurrency limit.
• Clause Blind Schnorr : This is a three-message protocol based on a variant of the blind Schnorr signature protocol. This variant of the protocol is not known to be vulnerable to the attack in , though the protocol is still new and under consideration. In the future, this may be a candidate for future blind signatures based on blind signatures. However, the three-message flow necessarily requires two round trips between the client and server, which may be prohibitive for large-scale signature generation. Further analysis and experimentation with this protocol is needed.
• BSA : This is a three-message protocol based on elliptic curve groups similar to blind Schnorr. It is also not known to be vulnerable to the ROS attack in . Kastner et al. proved concurrent security with a polynomial number of sessions. For similar reasons to the clause blind Schnorr protocol above, the additional number of round trips requires further analysis and experimentation.
• Blind BLS : The Boneh-Lynn-Shacham protocol can incorporate message blinding when properly instantiated with Type III pairing group. This is a two-message protocol similar to the RSA variant, though it requires pairing support, which is not common in widely deployed cryptographic libraries backing protocols such as TLS. In contrast, the specification in this document relies upon widely deployed cryptographic primitives.

Beyond blind signature protocols, anonymous credential schemes with public verifiability such as U-Prove may be used instead of blind signature protocols. Anonymous credentials may even be constructed with blind signature protocols. However, anonymous credentials are higher-level constructions that present a richer feature set.

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 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. 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 memo represents a republication of PKCS #1 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document is taken directly from the PKCS #1 v2.1 document, with certain corrections made during the publication process. This memo provides information for the Internet community. The CBOR Object Signing and Encryption (COSE) specification defines cryptographic message encodings using Concise Binary Object Representation (CBOR). This specification defines algorithm encodings and representations enabling RSA algorithms to be used for COSE messages. Encodings are specified for the use of RSA Probabilistic Signature Scheme (RSASSA-PSS) signatures, RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) encryption, and RSA keys. 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. 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. Cloudflare This document specifies the Privacy Pass protocol. This protocol provides anonymity-preserving authorization of clients to servers. In particular, client re-authorization events cannot be linked to any previous initial authorization. Privacy Pass is intended to be used as a performant protocol in the application-layer. 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] 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 Stanford University University of Waterloo Carnegie Mellon University NTT Research and ENS, Paris Cloudflare, Inc. Algorand BLS is a digital signature scheme with aggregation properties. Given set of signatures (signature_1, ..., signature_n) anyone can produce an aggregated signature. Aggregation can also be done on secret keys and public keys. Furthermore, the BLS signature scheme is deterministic, non-malleable, and efficient. Its simplicity and cryptographic properties allows it to be useful in a variety of use- cases, specifically when minimal storage space or bandwidth are required.

Test Vectors This section includes test vectors for the blind signature protocol defined in . It does not include test vectors based on the external interface 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: Messsage being signed, encoded as a hexadecimal string. The hash is computed using SHA-384.
• salt: Randomly-generated salt used when computing the signature. The length (sLen) is either 48 or 0 bytes.
• inv: The message blinding inverse, encoded as a hexadecimal string.
• encoded_msg: EMSA-PSS encoded message. The mask generation function is MGF1 with SHA-384.
• blinded_msg, blind_sig: The protocol values exchanged during the computation, encoded as hexadecimal strings.
• sig: The output message signature.

Test vector for probabilistic signatures (sLen=48): Test vector for deterministic signatures (sLen=0):