]>
Partially Blind RSA Signatures
Google
gamjad@google.com
Google
scott@shendrickson.com
Cloudflare
caw@heapingbits.net
Google
kwlyeo@cs.columbia.edu
InternetDraft
This document specifies a blind RSA signature protocol that supports public metadata.
It is an extension to the RSABSSA protocol recently specified by the CFRG.
Discussion Venues
Discussion of this document takes place on the
Crypto Forum Research Group mailing list (cfrg@ietf.org),
which is archived at .
Source for this draft and an issue tracker can be found at
.
Introduction
specifies the RSA blind
signature protocol, denoted RSABSSA. This is a twoparty protocol between
client and server (or signer) where they interact to compute
sig = Sign(sk, input_msg), where input_msg = Prepare(msg) is a prepared
version of the private message msg provided by the client, and sk is
the signing key provided by the server. 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 sk.
RSABSSA has a variety of applications, with
being a canonical example. While useful, this protocol is limited in that
it does not easily accommodate public metadata to be associated with
a (message, signature) pair. In this context, public metadata is information
that is publicly known to both client and server at the time of computation.
This has useful applications in practice. For example, metadata might be used
to encode expiration information for a (message, signature) pair. In practice,
metadata can be encoded using signing key pairs, e.g., by associating one
metadata value with one key pair, but this does not scale well for applications
that have large or arbitrary amounts of metadata.
This document specifies a variant of RSABSSA that supports public metadata, denoted
RSAPBSSA (RSA Partially Blind Signature with Appendix). Similar to RSABSSA in
, RSAPBSSSA is defined in such a way that the resulting (unblinded)
signature can be verified with a standard RSAPSS library that does not impose a
range limit on the public exponent.
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.
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 nonnegative 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 bigendian 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 coprime.

is_coprime(x, n): Return true if x and n are coprime, and false otherwise.

len(s): The length of a byte string, in bytes.

random(n): Generate n random bytes using a cryptographicallysecure 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.

random_prime(b): Return a random prime number of length b bits.

is_prime(p): Return true if the input integer p is prime, and false otherwise.
RSAPBSSA Protocol
The RSAPBSSA protocol consists of two helper functions  DeriveKeyPair and DerivePublicKey  and
four core 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, info be the public metadata shared between client and server, and (sk, pk)
be the server's private and public key pair. The REQUIRED key generation procedure for RSAPBSSA
is specified in .
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 blind_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 and metadata info
using the server public key pk by invoking the RSASSAPSSVERIFY 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(sk, blind_msg, info)
blind_sig
<
sig = Finalize(pk, input_msg, info, blind_sig, inv)
]]>
In the remainder of this section, we specify the Blind, BlindSign, and Finalize
functions that are used in this protocol. The Prepare function is as specified in
.
Key Generation
The protocol in this document requires signing key pairs to be generated such that
they satisfy a particular criteria. In particular, each RSA modulus for a key pair
MUST be the product of two safe primes p and q. A safe prime p is a prime number
such that p = 2p' + 1, where p' is also a prime number.
A signing key pair is a tuple (sk, pk), where each element is as follows:

sk = (n, p, q, phi, d), where phi = (p  1)(q  1), n = p * q, and d is the private exponent

pk = (n, e), where n = p * q, and e is the public exponent such that d * e == 1 mod phi
The procedure for generating a key pair satisfying this requirement is below.
The procedure for generating a safe prime, denoted SafePrime, is below.
Blind
The Blind function encodes an input message with the corresponding metadata value 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 EMSAPSSENCODE are as defined in Sections and of ,
respectively.
If this function fails with a "blinding error" error, implementations SHOULD retry
the function again. The probability of one or more such errors in sequence is negligible.
This function can also fail with an "invalid input" error, which indicates that one of
the inputs (likely the public key) was invalid. Implementations SHOULD update the public
key before calling this function again. 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. The function DerivePublicKey
is defined in .
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.
Note that pk_derived can be computed once during Blind and then passed to
Finalize directly, rather than being recomputed again.
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, along with metadata info.
Clients verify the signature over msg and info using the server's public
key pk as follows:

Compute pk_derived = DerivePublicKey(pk, info).

Compute msg_prime = concat("msg", int_to_bytes(len(info), 4), info, msg).

Invoke and output the result of RSASSAPSSVERIFY ()
with (n, e) as pk_derived, M as msg_prime, 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.
Public Key Derivation
The public key derivation function (DerivePublicKey) derives a permetadata public
key that is used in the core protocol. The hash function used for HKDF as defined in is that which
is associated with the RSAPBSSA instance and denoted by the Hash parameter. Note that
the input to HKDF is expanded to account for bias in the output distribution.
Key Pair Derivation
The key pair derivation function (DeriveKeyPair) derives a pair of private
and public keys specific to a metadata value that are used by the server
in the core protocol.
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 highlevel 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 implementers. 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, "blinding error" is generated in Blind when the client produces 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 Usage
A server signing key MUST NOT be reused for any other protocol beyond RSAPBSSA. In particular,
the same signing key MUST NOT be used for both the RSAPBSSA and RSABSSA protocols. Moreover, a
server signing key MUST NOT be reused for different RSAPBSSA 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 RSASSAPSS
OID . It MUST NOT use the rsaEncryption OID .
RSAPBSSA Variants
In this section, we define named variants of RSAPBSSA. These variants consider
different sets of RSASSAPSS parameters as defined in and explicitly
specified in . For algorithms unique
to RSAPBSSA, the choice of hash function specifies the instantiation of HKDF in DerivePublicKey in
. The different types of Prepare functions are specified in
.

RSAPBSSASHA384PSSRandomized: This named variant uses SHA384 as the hash function,
MGF1 with SHA384 as the PSS mask generation function, a 48byte salt length, and uses
the randomized preparation function (PrepareRandomize).

RSAPBSSASHA384PSSZERORandomized: This named variant uses SHA384 as the hash
function, MGF1 with SHA384 as the PSS mask generation function, an empty PSS salt, and
uses the randomized preparation function (PrepareRandomize).

RSAPBSSASHA384PSSDeterministic: This named variant uses SHA384 as the hash function,
MGF1 with SHA384 as the PSS mask generation function, 48byte salt length, and uses the
identity preparation function (PrepareIdentity).

RSAPBSSASHA384PSSZERODeterministic: This named variant uses SHA384 as the hash
function, MGF1 with SHA384 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 RSAPBSSASHA384PSSRandomized or
RSAPBSSASHA384PSSZERORandomized.
See for discussion about
interoperability considerations and deterministic signatures.
Security Considerations
Amjad et al. proved the following properties of RSAPBSSA:

Onemoreunforgeability: For any adversary interacting with the server (i.e., the signer) as a client
that interacts with the server at most n times is unable to output n+1 valid message and signature
tuples (i.e., the signature verifies for the corresponding message). This holds for any n that is polynomial
in the security parameter of the scheme.

Concurrent onemoreunforgeability: The above holds even in the setting when an adversarial client is interacting
with multiple servers (signers) simultaneously.

Unlinkability: Consider any adversary acting as the server (signer) interacting with n clients using the same
public metadata. Afterwards, the adversary randomly receives one of the n resulting signatures as a challenge.
Then, the adversary cannot guess which of the n interactions created the challenge signature better than
a random guess.
The first two unforgeability properties rely on the Strong RSA Known Target Inversion Problem. This is
slightly stronger assumption that the RSA Known Target Inversion Problem used in RSABSSA. In the RSA Known
Target Inversion Problem, the challenger is given a fixed public exponent e with the goal of computing
the eth root of n+1 random elements while using an eth oracle at most n times. In comparison, the
Strong RSA Known Target Inversion Problem enables the challenger to choose any public exponents
e_1,...,e_n+1 > 1 such that it can be the e_ith root for the ith random element. One can view the
difference between the Strong RSA Known Target Inversion and RSA Known Target Inversion problems identical
to the differences between the Strong RSA and RSA problems.
The final property of unlinkability relies only on the fact that the underlying hash functions are modelled
as random oracles.
All the security considerations of RSABSSA in
also apply to RSAPBSSA here. We present additional security considerations specific to RSAPBSSA below.
Strong RSA Modulus Key Generation
An essential component of RSAPBSSA is that the KeyGen algorithm in generates a RSA
modulus that is the product of two strong primes. This is essential to ensure that the resulting outputs
of DerivePublicKey in do cause errors in DeriveKeyPair in .
We note that an error in DeriveKeyPair would incur if the output of DerivePublicKey does not have an
inverse modulo phi. By choosing the RSA modulus as the product of two strong primes, we guarantee the output of
DerivePublicKey will never incur errors in DeriveKeyPair.
It is integral that one uses the KeyGen algorithm for RSAPBSSA instead of the standard RSA key generation algorithms
(such as those used in ). If one uses standard RSA key generation, there are no guarantees provided
for the success of the DeriveKeyPair function and, thus, being able to correctly sign messages for certain choices
of public metadata.
Domain Separation for Public Key Augmentation
The purpose of domain separation is to guarantee that the security analysis of any cryptographic protocol remains true
even if multiple instances of the protocol or multiple hash functions in a single instance of the protocol
are instantiated based on one underlying hash function.
The DerivePublicKey function in of this document already provide domain separation by using the RSA modulus
as input to the underlying HKDF as the info argument. As each instance of RSAPBSSA will have a different RSA modulus, this
effectively ensures that the outputs of the underlying hash functions for multiple instances will be different
even for the same input.
Additionally, the hash function invocation used for computing the message digest is domain separated from the hash function
invocation used for augmenting the public key in DerivePublicKey. This domain separation is done by prepending the inputs
to each hash function with a unique domain separation tag.
Choosing Public Metadata
The unlinkability property of RSAPBSSA guarantees anonymity for any signature amongst the set of all interactions with the
server (signer) with the same choice of public metadata. In other words, the server is unable to identify the interaction
that created the signature. The unlinkability guarantee of RSAPBSSA is only useful when there are a significant number of
server (signer) interactions for any value of public metadata. In the extreme case where each server interaction is performed
with a different value of public metadata, then the server can uniquely identify the server interaction that created the
given signature.
Applications that use RSAPBSSA MUST guarantee that the choice of public metadata is limited such that there is a significant
number of server (signer) interactions across many clients for any individual value of public metadata that is signed. This
should be contextualized to an application's user population size.
Denial of Service
RSAPBSSA is susceptible to Denial of Service (DoS) attacks due to the flexibility of choosing public metadata used in
DerivePublicKey in . In particular, an attacker can pick public metadata such that
the output of DerivePublicKey is very large, leading to more computational cost when verifying signatures.
Thus, if attackers can force verification with metadata of their choosing, DoS attacks are possible.
For applications where the values of potential public metadata choices are fixed ahead of time, it is possible
to try and mitigate DoS attacks. If the set of possible metadata choices is small, then applications
SHOULD use one of the protocol variants in with distinct keys for each metadata value.
IANA Considerations
This document has no IANA actions.
References
Normative References
RSA Blind Signatures
Fastly Inc.
Apple Inc.
Cloudflare
This document specifies an RSAbased 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 RSAPSS signature.
This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.
Key words for use in RFCs to Indicate Requirement Levels
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.
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
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.
PKCS #1: RSA Cryptography Specifications Version 2.2
This document provides recommendations for the implementation of publickey 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' PublicKey Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF.
This document also obsoletes RFC 3447.
HMACbased ExtractandExpand Key Derivation Function (HKDF)
This document specifies a simple Hashed Message Authentication Code (HMAC)based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes.
Updates for RSAESOAEP and RSASSAPSS Algorithm Parameters
This document updates RFC 4055. It updates the conventions for using the RSA Encryption Scheme  Optimal Asymmetric Encryption Padding (RSAESOAEP) 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. [STANDARDSTRACK]
Informative References
Privacy Pass Issuance Protocol
Brave Software
Brave Software
Google LLC
Cloudflare
This document specifies two variants of the twomessage 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.
Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
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 Internetspecific 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 Internetspecific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDSTRACK]
Acknowledgments
The authors would like to thank Nikita Borisov for pointing out an issue with a prior attempt at mitigating DoS attacks.
Test Vectors
This section includes test vectors for the RSAPBSSASHA384PSSDeterministic variant defined in .
The following parameters are specified for each test vector, where each hexidecimal value uses an unsigned bigendian convention:

p, q, d, e, N: RSA private and public key parameters, each encoded as a hexadecimal string.

msg: Input message being signed, encoded as a hexadecimal string. The hash is computed using SHA384.

info: Public metadata bound to the signature, encoded as a hexadecimal string.

eprime: The augmented public key exponent corresponding to e and metadata, encoded as a hexadecimal string.

r: The message blinding value, encoded as a hexadecimal string.

salt: Randomlygenerated salt used when computing the signature. The length is 48 bytes.

blind_msg, blind_sig: The protocol values exchanged during the computation,
encoded as hexadecimal strings.

sig: The output message signature.