Partially Blind RSA Signatures
draft-amjad-cfrg-partially-blind-rsa-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Ghous A. Amjad , Scott Hendrickson , Christopher A. Wood , Kevin W. L. Yeo | ||
| Last updated | 2023-03-13 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-amjad-cfrg-partially-blind-rsa-00
Network Working Group G. A. Amjad
Internet-Draft S. Hendrickson
Intended status: Informational Google
Expires: 14 September 2023 C. A. Wood
Cloudflare
K. W. L. Yeo
Google
13 March 2023
Partially Blind RSA Signatures
draft-amjad-cfrg-partially-blind-rsa-00
Abstract
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
This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the Crypto Forum Research
Group mailing list (cfrg@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/search/?email_list=cfrg.
Source for this draft and an issue tracker can be found at
https://github.com/chris-wood/draft-amjad-cfrg-partially-blind-rsa.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 14 September 2023.
Amjad, et al. Expires 14 September 2023 [Page 1]
Internet-Draft Partially Blind RSA Signatures March 2023
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. RSAPBSSA Protocol . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Key Generation . . . . . . . . . . . . . . . . . . . . . 5
4.2. Blind . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. BlindSign . . . . . . . . . . . . . . . . . . . . . . . . 9
4.4. Finalize . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5. Verification . . . . . . . . . . . . . . . . . . . . . . 10
4.6. Public Key Augmentation . . . . . . . . . . . . . . . . . 11
4.7. Private Key Augmentation . . . . . . . . . . . . . . . . 12
5. Implementation and Usage Considerations . . . . . . . . . . . 12
5.1. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Signing Key Generation and Usage . . . . . . . . . . . . 13
6. RSAPBSSA Variants . . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7.1. Strong RSA Modulus Key Generation . . . . . . . . . . . . 15
7.2. Domain Separation for Public Key Augmentation . . . . . . 15
7.3. Choosing Public Metadata . . . . . . . . . . . . . . . . 16
7.4. Denial of Service . . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 18
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
Amjad, et al. Expires 14 September 2023 [Page 2]
Internet-Draft Partially Blind RSA Signatures March 2023
1. Introduction
[RSABSSA] specifies the RSA blind signature protocol, denoted
RSABSSA. This is a two-party protocol between client and server (or
signer) 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. 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.
RSABSSA has a variety of applications, with [PRIVACY-PASS] 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's 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 [RSABSSA], RSAPBSSSA is defined in
such a way that the resulting (unblinded) signature can be verified
with a standard RSA-PSS library.
2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. 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 [RFC8017],
respectively. Note that these functions operate on byte strings
in big-endian byte order.
Amjad, et al. Expires 14 September 2023 [Page 3]
Internet-Draft Partially Blind RSA Signatures March 2023
* 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.
* is_coprime(x, n): Return true if x and n are co-prime, and false
otherwise.
* 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.
* 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.
4. RSAPBSSA Protocol
The RSAPBSSA protocol consists of two helper functions --
AugmentPrivateKey and AugmentPublicKey -- 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 (skS, pkS) be the server's private and public
key pair. The REQUIRED key generation procedure for RSAPBSSA is
specified in Section 4.1.
The protocol begins by the client preparing the message to be signed
by computing:
input_msg = Prepare(msg)
The client then initiates the blind signature protocol by computing:
Amjad, et al. Expires 14 September 2023 [Page 4]
Internet-Draft Partially Blind RSA Signatures March 2023
blinded_msg, inv = Blind(pkS, input_msg, info)
The client then sends blinded_msg to the server, which then processes
the message by computing:
blind_sig = BlindSign(skS, blinded_msg, info)
The server then sends blind_sig to the client, which then finalizes
the protocol by computing:
sig = Finalize(pkS, input_msg, info, blind_sig, inv)
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 metadata using the server
public key pkS by invoking the RSASSA-PSS-VERIFY routine defined in
Section 8.1.2 of [RFC8017]. The Finalize function performs this
check before returning the signature. See Section 4.5 for more
details about verifying signatures produced through this protocol.
In pictures, the protocol runs as follows:
Client(pkS, msg, metadata) Server(skS, pkS, metadata)
-------------------------------------------------------
input_msg = Prepare(msg)
blinded_msg, inv = Blind(pkS, input_msg, metadata)
blinded_msg
---------->
blind_sig = BlindSign(skS, blinded_msg, metadata)
blind_sig
<----------
sig = Finalize(pkS, input_msg, metadata, 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 Section 4.1 of [RSABSSA].
4.1. 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 = 2q + 1, where q is also a prime number.
Amjad, et al. Expires 14 September 2023 [Page 5]
Internet-Draft Partially Blind RSA Signatures March 2023
A signing key pair is a tuple (skS, pkS), where each element is as
follows:
* skS = (p, q, phi, d), where phi = (p - 1)(q - 1)
* pkS = (n, e), where n = p * q and d * e == 1 mod phi.
The procedure for generating a key pair satisfying this requirement
is below.
KeyGen(bits)
Inputs:
- bits, length in bits of the RSA modulus, a multiple of 2
Outputs:
- (skS, pkS), a signing key pair
Steps:
1. p = SafePrime(bits / 2)
2. q = SafePrime(bits / 2)
3. while p == q, go to step 2.
4. phi = (p - 1) * (q - 1)
5. e = 65537
6. d = inverse_mod(e, phi)
7. skS = (p, q, phi, d)
8. pkS = (p * q, e)
9. output (skS, pkS)
The procedure for generating a safe prime, denoted SafePrime, is
below.
SafePrime(bits)
Inputs:
- bits, length in bits of the safe prime
Outputs:
- p, a safe prime integer
Steps:
1. q = random_prime(bits - 1)
2. p = (2 * q) + 1
3. if is_prime(p) is True, output p, else go to step 1.
Amjad, et al. Expires 14 September 2023 [Page 6]
Internet-Draft Partially Blind RSA Signatures March 2023
4.2. 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
EMSA-PSS-ENCODE are as defined in Sections 5.2.2 and 9.1.1 of
[RFC8017], respectively.
If this function fails with an "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
Section 5.1 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.
Amjad, et al. Expires 14 September 2023 [Page 7]
Internet-Draft Partially Blind RSA Signatures March 2023
Blind(pkS, msg, metadata)
Parameters:
- kLen, the length in bytes of the RSA modulus n
- Hash, the hash function used to hash the message
- MGF, the mask generation function
- sLen, the length in bytes of the salt
Inputs:
- pkS, server public key (n, e)
- msg, message to be signed, a byte string
- metadata, public metadata, a byte string
Outputs:
- blinded_msg, a byte string of length kLen
- inv, an integer
Errors:
- "message too long": Raised when the input message is too long (raised by EMSA-PSS-ENCODE).
- "encoding error": Raised when the input message fails encoding (raised by EMSA-PSS-ENCODE).
- "blinding error": Raised when the inverse of r cannot be found.
- "invalid input": Raised when the message is not co-prime with n.
Steps:
1. msg_prime = concat("msg", int_to_bytes(len(metadata), 4), metadata, msg)
2. encoded_msg = EMSA-PSS-ENCODE(msg_prime, bit_len(n))
with Hash, MGF, and sLen as defined in the parameters
3. If EMSA-PSS-ENCODE raises an error, raise the error and stop
4. m = bytes_to_int(encoded_msg)
5. c = is_coprime(m, n)
6. If c is false, raise an "invalid input" error
and stop
7. r = random_integer_uniform(1, n)
8. inv = inverse_mod(r, n)
9. If inverse_mod fails, raise an "blinding error" error
and stop
10. pkM = AugmentPublicKey(pkS, metadata)
11. x = RSAVP1(pkM, r)
12. z = m * x mod n
13. blinded_msg = int_to_bytes(z, kLen)
14. output blinded_msg, inv
The blinding factor r MUST be randomly chosen from a uniform
distribution. This is typically done via rejection sampling. The
function AugmentPublicKey is defined in Section 4.6.
Amjad, et al. Expires 14 September 2023 [Page 8]
Internet-Draft Partially Blind RSA Signatures March 2023
4.3. 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 Section 5.2.1 of [RFC8017].
BlindSign(skS, blinded_msg, metadata)
Parameters:
- kLen, the length in bytes of the RSA modulus n
Inputs:
- skS, server private key
- blinded_msg, encoded and blinded message to be signed, a
byte string
- metadata, public metadata, a byte string
Outputs:
- blind_sig, a byte string of length kLen
Errors:
- "signing failure": Raised when the signing operation fails
- "message representative out of range": Raised when the message representative
to sign is not an integer between 0 and n - 1 (raised by RSASP1)
Steps:
1. m = bytes_to_int(blinded_msg)
2. skM = AugmentPrivateKey(skS, pkS, metadata)
3. pkM = AugmentPublicKey(pkS, metadata)
4. s = RSASP1(skM, m)
5. m' = RSAVP1(pkM, s)
6. If m != m', raise "signing failure" and stop
7. blind_sig = int_to_bytes(s, kLen)
8. output blind_sig
4.4. 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.
Amjad, et al. Expires 14 September 2023 [Page 9]
Internet-Draft Partially Blind RSA Signatures March 2023
Finalize(pkS, msg, metadata, blind_sig, inv)
Parameters:
- kLen, the length in bytes of the RSA modulus n
- Hash, the hash function used to hash the message
- MGF, the mask generation function
- sLen, the length in bytes of the salt
Inputs:
- pkS, server public key (n, e)
- msg, message to be signed, a byte string
- metadata, public metadata, a byte string
- blind_sig, signed and blinded element, a byte string of
length kLen
- inv, inverse of the blind, an integer
Outputs:
- sig, a byte string of length kLen
Errors:
- "invalid signature": Raised when the signature is invalid
- "unexpected input size": Raised when a byte string input doesn't
have the expected length.
Steps:
1. If len(blind_sig) != kLen, raise "unexpected input size" and stop
2. z = bytes_to_int(blind_sig)
3. s = z * inv mod n
4. sig = int_to_bytes(s, kLen)
5. msg_prime = concat("msg", int_to_bytes(len(metadata), 4), metadata, msg)
6. pkM = AugmentPublicKey(pkS, metadata)
7. result = RSASSA-PSS-VERIFY(pkM, msg_prime, sig) with
Hash, MGF, and sLen as defined in the parameters
8. If result = "valid signature", output sig, else
raise "invalid signature" and stop
Note that pkM can be computed once during Blind and then passed to
Finalize directly, rather than being recomputed again.
4.5. Verification
As described in Section 4, 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 metadata. Clients verify the signature over msg and
info using the server's public key pkS as follows:
1. Compute pkM = AugmentPublicKey(pkS, info).
Amjad, et al. Expires 14 September 2023 [Page 10]
Internet-Draft Partially Blind RSA Signatures March 2023
2. Compute msg_prime = concat("msg", int_to_bytes(len(metadata), 4),
metadata, msg).
3. Invoke and output the result of RSASSA-PSS-VERIFY (Section 8.1.2
of [RFC8017]) with (n, e) as pkM, 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.
4.6. Public Key Augmentation
The public key augmentation function (AugmentPublicKey) derives a
per-metadata public key that is used in the core protocol. The hash
function used for HKDF 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.
AugmentPublicKey(pkS, metadata)
Parameters:
- kLen, the length in bytes of the RSA modulus n
- Hash, the hash function used to hash the message
Inputs:
- pkS, server public key (n, e)
- metadata, public metadata, a byte string
Outputs:
- pkM, augmented server public key (n, e')
Steps:
1. hkdf_input = concat("key", metadata, 0x00)
2. hkdf_salt = int_to_bytes(n, kLen)
3. lambda_len = kLen / 2
4. hkdf_len = lambda_len + 16
5. expanded_bytes = HKDF(IKM=hkdf_input, salt=hkdf_salt, info="PBRSA", L=hkdf_len)
6. expanded_bytes[0] &= 0x3F // Clear two-most top bits
7. expanded_bytes[lambda_len-1] |= 0x01 // Set bottom-most bit
8. e' = bytes_to_int(slice(expanded_bytes, lambda_len))
9. output pkM = (n, e * e')
Amjad, et al. Expires 14 September 2023 [Page 11]
Internet-Draft Partially Blind RSA Signatures March 2023
4.7. Private Key Augmentation
The public key augmentation function (AugmentPrivateKey) derives a
per-metadata private signing key that is used by the server in the
core protocol.
AugmentPrivateKey(skS, pkS, metadata)
Parameters:
- kLen, the length in bytes of the RSA modulus n
- Hash, the hash function used to hash the message
Inputs:
- skS, server private key (p, q, phi, d)
- pkS, server public key (n, e)
- metadata, public metadata, a byte string
Outputs:
- skM, augmented server private key (p, q, phi, d')
Steps:
1. (n, e') = AugmentPublicKey(pkS, metadata)
2. d' = inverse_mod(e', phi)
3. output pkM = (p, q, phi, d')
5. 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.
5.1. Errors
The high-level functions specified in Section 4 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.
Amjad, et al. Expires 14 September 2023 [Page 12]
Internet-Draft Partially Blind RSA Signatures March 2023
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. Section 4.2
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.
5.2. Signing Key Generation and Usage
The RECOMMENDED method for generating the server signing key pair is
as specified in FIPS 186-4 [DSS].
A server signing key MUST NOT be reused for any other protocol beyond
RSAPBSSA. 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 RSASSA-PSS OID [RFC5756]. It MUST NOT use the rsaEncryption
OID [RFC5280].
6. RSAPBSSA Variants
In this section, we define named variants of RSAPBSSA. These
variants consider different sets of RSASSA-PSS parameters as defined
in Section 9.1.1 of [RFC8017] and explicitly specified in Section 5
of [RSABSSA]. For algorithms unique to RSAPBSSA, the choice of hash
function specifies the instantation of HKDF in AugmentPublicKey in
Section 4.6. The different types of Prepare functions are specified
in Section 4.1 of [RSABSSA].
1. RSAPBSSA-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. RSAPBSSA-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).
Amjad, et al. Expires 14 September 2023 [Page 13]
Internet-Draft Partially Blind RSA Signatures March 2023
3. RSAPBSSA-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. RSAPBSSA-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 RSAPBSSA-SHA384-PSS-Randomized or
RSAPBSSA-SHA384-PSSZERO-Randomized.
See Section 5 of [RSABSSA] for discussion about interoperability
considerations and deterministic signatures.
7. Security Considerations
Amjad et al. proved the following properties of RSAPBSSA:
* One-more-unforgeability: 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 one-more-unforgeability: 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 e-th root of n+1
random elements while using an e-th 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
Amjad, et al. Expires 14 September 2023 [Page 14]
Internet-Draft Partially Blind RSA Signatures March 2023
it can be the e_i-th root for the i-th 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 Section 8 of [RSABSSA]
also apply to RSAPBSSA here. We present additional security
considerations specific to RSAPBSSA below.
7.1. Strong RSA Modulus Key Generation
An essential component of RSAPBSSA is that the KeyGen algorithm in
Section 4.1 generates a RSA modulus that is the product of two strong
primes. This is essential to ensure that the resulting outputs of
AugmentPublicKey in Section 4.6 does cause errors in
AugmentPrivateKey in Section 4.7. We note that an error in
AugmentPrivateKey would incur if the output of AugmentPublicKey does
not have an inverse modulo phi. By choosing the RSA modulus as the
product of two strong primes, we guarantee the output of
AugmentPublicKey will never incur errors in AugmentPrivateKey.
It is integral that one uses the KeyGen algorithm for RSAPBSSA
instead of the standard RSA key generation algorithms (such as those
used in [RSABSSA]). If one uses standard RSA key generation, there
are no guarantees provided for the success of the AugmentPrivateKey
function and, thus, being able to correctly sign messages for certain
choices of public metadata.
7.2. Domain Separation for Public Key Augmentation
The purpose of domain separation is to guarantee that the security
analysis of any cryptographic protocol remain 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 AugmentPublicKey in Section 4.6 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.
Amjad, et al. Expires 14 September 2023 [Page 15]
Internet-Draft Partially Blind RSA Signatures March 2023
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 AugmentPublicKey. This domain
separation is done by prepending the inputs to each hash function
with a unique domain separation tag.
7.3. 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.
7.4. Denial of Service
RSAPBSSA is suspectible to Denial of Service (DoS) attacks due to the
flexibility of choosing public metadata used in AugmentPublicKey in
Section 4.6. In particular, an attacker can pick public metadata
such that the output of AugmentPublicKey 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 [RSABSSA]
with distinct keys for each metadata value. However, if the set of
possible metadata choices is large, rendering this approach
infeasible for key management and distribution reasons, other
mitigations are possible. As one possible mitigation, first recall
that there are only two requirements for the choice of e' in
AugmentPublicKey in Section 4.6. First, e' must be smaller than both
prime factors of phi. Secondly, the possible values of e' must be
large enough to avoid collisions such that two public metadata
choices will result in the same e' and, thus, the same augmented
Amjad, et al. Expires 14 September 2023 [Page 16]
Internet-Draft Partially Blind RSA Signatures March 2023
public key. During KeyGen in Section 4.1, the server (signer) can
pick the smallest length output for the HKDF in AugmentPublicKey such
that the output will be different for all relevant public metadata
choices while ensuring augmented public keys are smaller.
8. IANA Considerations
This document has no IANA actions.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC5756] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Updates for RSAES-OAEP and RSASSA-PSS Algorithm
Parameters", RFC 5756, DOI 10.17487/RFC5756, January 2010,
<https://www.rfc-editor.org/rfc/rfc5756>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016,
<https://www.rfc-editor.org/rfc/rfc8017>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
9.2. Informative References
[DSS] "Digital Signature Standard (DSS)", National Institute of
Standards and Technology report,
DOI 10.6028/nist.fips.186-4, July 2013,
<https://doi.org/10.6028/nist.fips.186-4>.
[PRIVACY-PASS]
Celi, S., Davidson, A., Faz-Hernandez, A., Valdez, S., and
C. A. Wood, "Privacy Pass Issuance Protocol", Work in
Progress, Internet-Draft, draft-ietf-privacypass-protocol-
10, 6 March 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-privacypass-protocol-10>.
Amjad, et al. Expires 14 September 2023 [Page 17]
Internet-Draft Partially Blind RSA Signatures March 2023
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
[RSABSSA] Denis, F., Jacobs, F., and C. A. Wood, "RSA Blind
Signatures", Work in Progress, Internet-Draft, draft-irtf-
cfrg-rsa-blind-signatures-11, 16 February 2023,
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
rsa-blind-signatures-11>.
Appendix A. Test Vectors
This section includes test vectors for the RSAPBSSA-SHA384-PSS-
Randomized variant defined in Section 4. 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.
* metadata: 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.
* rand: Message randomizer prefix, encoded as a hexadecimal string.
* blind: The message blinding value, encoded as a hexadecimal
string.
* salt: Randomly-generated salt used when computing the signature.
The length is 48 bytes.
* blinded_msg, blinded_sig: The protocol values exchanged during the
computation, encoded as hexadecimal strings.
* sig: The output message signature.
Amjad, et al. Expires 14 September 2023 [Page 18]
Internet-Draft Partially Blind RSA Signatures March 2023
// Test vector 1
p: dcd90af1be463632c0d5ea555256a20605af3db667475e190e3af12a34a332
4c46a3094062c59fb4b249e0ee6afba8bee14e0276d126c99f4784b23009bf616
8ff628ac1486e5ae8e23ce4d362889de4df63109cbd90ef93db5ae64372bfe1c5
5f832766f21e94ea3322eb2182f10a891546536ba907ad74b8d72469bea396f3
q: f8ba5c89bd068f57234a3cf54a1c89d5b4cd0194f2633ca7c60b91a795a56f
a8c8686c0e37b1c4498b851e3420d08bea29f71d195cfbd3671c6ddc49cf4c1db
5b478231ea9d91377ffa98fe95685fca20ba4623212b2f2def4da5b281ed0100b
651f6db32112e4017d831c0da668768afa7141d45bbc279f1e0f8735d74395b3
d: 4e21356983722aa1adedb084a483401c1127b781aac89eab103e1cfc522154
94981d18dd8028566d9d499469c25476358de23821c78a6ae43005e26b394e305
1b5ca206aa9968d68cae23b5affd9cbb4cb16d64ac7754b3cdba241b72ad6ddfc
000facdb0f0dd03abd4efcfee1730748fcc47b7621182ef8af2eeb7c985349f62
ce96ab373d2689baeaea0e28ea7d45f2d605451920ca4ea1f0c08b0f1f6711eaa
4b7cca66d58a6b916f9985480f90aca97210685ac7b12d2ec3e30a1c7b97b65a1
8d38a93189258aa346bf2bc572cd7e7359605c20221b8909d599ed9d38164c9c4
abf396f897b9993c1e805e574d704649985b600fa0ced8e5427071d7049d
e: 010001
N: d6930820f71fe517bf3259d14d40209b02a5c0d3d61991c731dd7da39f8d69
821552e2318d6c9ad897e603887a476ea3162c1205da9ac96f02edf31df049bd5
5f142134c17d4382a0e78e275345f165fbe8e49cdca6cf5c726c599dd39e09e75
e0f330a33121e73976e4facba9cfa001c28b7c96f8134f9981db6750b43a41710
f51da4240fe03106c12acb1e7bb53d75ec7256da3fddd0718b89c365410fce61b
c7c99b115fb4c3c318081fa7e1b65a37774e8e50c96e8ce2b2cc6b3b367982366
a2bf9924c4bafdb3ff5e722258ab705c76d43e5f1f121b984814e98ea2b2b8725
cd9bc905c0bc3d75c2a8db70a7153213c39ae371b2b5dc1dafcb19d6fae9
msg: 68656c6c6f20776f726c64
metadata: 6d65746164617461
eprime: 30584b72f5cb557085106232f051d039e23358feee9204cf30ea56762
0e90d79e4a7a81388b1f390e18ea5240a1d8cc296ce1325128b445c48aa5a3b34
fa07c324bf17bc7f1b3efebaff81d7e032948f1477493bc183d2f8d94c947c984
c6f0757527615bf2a2f0ef0db5ad80ce99905beed0440b47fa5cb9a2334fea40a
d88e6ef1
rand:
64b5c5d2b2ca672690df59bab774a389606d85d56f92a18a57c42eb4cb164d43
blind: d0261d61ce06309219fbac512db680b381a9fbf2cf08a11a0a1af9424d
cc639777872408c58821c4fc2aa8b607e519b37d79a2beb71ddf48ed9323c2fd0
c87fc0343d0d00e35f4601bb6f3462950437c7f9a42e7c1ae1a9d72e5090b9739
0f94b8764e11173aabcad5a8254e15d4f0e9b047ba0640a8ed4e340b5bcd4b005
12c1474ffae384934a72c7af9010ae147602238502469c6860ddbc43f35a73348
521501a32e7a40fdde6180718755a25de849b82f7dacaea05871a8122057d8726
1172ba8871f2bb8a2c16cd668ae0cfb1fc03b20d4fdf5046a15c59366f0ce631a
887a64c621a1fb1090584cdd6cc958b6af024c3bb8476f12d093d0df352f126e
salt: 59bfc4f4b56aaee9389ba95517a932900971c3417fa5fe4a309477d9c08
87f9b601be62557c67bc4e6f6eb0325eac46d
blinded_msg: 1b9e1057dd2d05a17ad2feba5f87a4083cc825fe06fc70f0b782
062ea0043fa65ec8096ce5d403cfa2aa3b11195b2a655d694386058f626645071
5a936b5764f42977c0a0933ff3054d456624734fd2c019def792f00d30b3ac2f2
Amjad, et al. Expires 14 September 2023 [Page 19]
Internet-Draft Partially Blind RSA Signatures March 2023
7859ea56d835f80564a3ba59f3c876dc926b2a785378ca83f177f7b378513b36a
074e7db59448fd4007b54c64791a33b61721ab3b5476165193af30f25164d4806
84d045a8d0782a53dd73774563e8d29e48b175534f696763abaab49fa03a055ec
9246c5e398a5563cc88d02eb57d725d3fc9231ae5139aa7fcb9941060b0bf0192
b8c81944fa0c54568b0ab4ea9c4c4c9829d6dbcbf8b48006b322ee51d784ac93e
4bf13
blinded_sig: 7ef75d9887f29f2232602acab43263afaea70313a0c90374388d
f5a7a7440d2584c4b4e5b886accc065bf4824b4b22370ddde7fea99d4cd67f8ed
2e4a6a2b7b5869e8d4d0c52318320c5bf7b9f02bb132af7365c471e799edd111c
a9441934c7db76c164b0515afc5607b8ceb584f5b1d2177d5180e57218265c07a
ec9ebde982f3961e7ddaa432e47297884da8f4512fe3dc9ab820121262e6a7385
0920299999c293b017cd800c6ec994f76b6ace35ff4232f9502e6a52262e19c03
de7cc27d95ccbf4c381d698fcfe1f200209814e04ae2d6279883015bbf36cabf3
e2350be1e175020ee9f4bb861ba409b467e23d08027a699ac36b2e5ab988390f3
c0ee9
sig: abd6813bb4bbe3bc8dc9f8978655b22305e5481b35c5bdc4869b60e2d5cc
74b84356416abaaca0ca8602cd061248587f0d492fee3534b19a3fe089de18e4d
f9f3a6ad289afb5323d7934487b8fafd25943766072bab873fa9cd69ce7328a57
344c2c529fe96983ca701483ca353a98a1a9610391b7d32b13e14e8ef87d04c0f
56a724800655636cfff280d35d6b468f68f09f56e1b3acdb46bc6634b7a1eab5c
25766cec3b5d97c37bbca302286c17ff557bcf1a4a0e342ea9b2713ab7f935c81
74377bace2e5926b39834079761d9121f5df1fad47a51b03eab3d84d050c99cf1
f68718101735267cca3213c0a46c0537887ffe92ca05371e26d587313cc3f4
// Test vector 2
p: dcd90af1be463632c0d5ea555256a20605af3db667475e190e3af12a34a332
4c46a3094062c59fb4b249e0ee6afba8bee14e0276d126c99f4784b23009bf616
8ff628ac1486e5ae8e23ce4d362889de4df63109cbd90ef93db5ae64372bfe1c5
5f832766f21e94ea3322eb2182f10a891546536ba907ad74b8d72469bea396f3
q: f8ba5c89bd068f57234a3cf54a1c89d5b4cd0194f2633ca7c60b91a795a56f
a8c8686c0e37b1c4498b851e3420d08bea29f71d195cfbd3671c6ddc49cf4c1db
5b478231ea9d91377ffa98fe95685fca20ba4623212b2f2def4da5b281ed0100b
651f6db32112e4017d831c0da668768afa7141d45bbc279f1e0f8735d74395b3
d: 4e21356983722aa1adedb084a483401c1127b781aac89eab103e1cfc522154
94981d18dd8028566d9d499469c25476358de23821c78a6ae43005e26b394e305
1b5ca206aa9968d68cae23b5affd9cbb4cb16d64ac7754b3cdba241b72ad6ddfc
000facdb0f0dd03abd4efcfee1730748fcc47b7621182ef8af2eeb7c985349f62
ce96ab373d2689baeaea0e28ea7d45f2d605451920ca4ea1f0c08b0f1f6711eaa
4b7cca66d58a6b916f9985480f90aca97210685ac7b12d2ec3e30a1c7b97b65a1
8d38a93189258aa346bf2bc572cd7e7359605c20221b8909d599ed9d38164c9c4
abf396f897b9993c1e805e574d704649985b600fa0ced8e5427071d7049d
e: 010001
N: d6930820f71fe517bf3259d14d40209b02a5c0d3d61991c731dd7da39f8d69
821552e2318d6c9ad897e603887a476ea3162c1205da9ac96f02edf31df049bd5
5f142134c17d4382a0e78e275345f165fbe8e49cdca6cf5c726c599dd39e09e75
e0f330a33121e73976e4facba9cfa001c28b7c96f8134f9981db6750b43a41710
f51da4240fe03106c12acb1e7bb53d75ec7256da3fddd0718b89c365410fce61b
c7c99b115fb4c3c318081fa7e1b65a37774e8e50c96e8ce2b2cc6b3b367982366
Amjad, et al. Expires 14 September 2023 [Page 20]
Internet-Draft Partially Blind RSA Signatures March 2023
a2bf9924c4bafdb3ff5e722258ab705c76d43e5f1f121b984814e98ea2b2b8725
cd9bc905c0bc3d75c2a8db70a7153213c39ae371b2b5dc1dafcb19d6fae9
msg: 68656c6c6f20776f726c64
metadata:
eprime: 2ed5a8d2592a11bbeef728bb39018ef5c3cf343507dd77dd156d5eec7
f06f04732e4be944c5d2443d244c59e52c9fa5e8de40f55ffd0e70fbe9093d3f7
be2aafd77c14b263b71c1c6b3ca2b9629842a902128fee4878392a950906fae35
d6194e0d2548e58bbc20f841188ca2fceb20b2b1b45448da5c7d1c73fb6e83fa5
8867397b
rand:
ebb56541b9a1758028033cfb085a4ffe048f072c6c82a71ce21d40842b5c0a89
blind: b8b99b94b48725b059cf26279a79e6cc00d6b98024621f69a6a80e7b74
5050da88ecd81eac3326c96b9ce3695fb7730c17f334d6e4d42088879a42fcb23
bacbc3e0329eab4e9cd3637de07fe64ff2d79fcb44fed2e978a2efb693e87fc9e
971a3a79f746d980d56a6701dcbb6b11a83c8b80d1321e7a4c8ccf541dfd0ceb7
cf71bb0c91be635c979c7a395849ce5c51dd5ab5e7910af1036ffd63da61a56e7
cce6863062ab168dab78ee561e5cc09f303d5aad1c4f6219a9fef85328a2eecb0
6c79272d18c6badfac24c83dac9928d96a2b53e08a60399a8daf656582d6eb7a6
c9fd7d87f5fc3b3752c755c76acb96c103d260690d3ca86383c0dba28c54bb50
salt: a4840382f7404877d0825bb254dd6038a0f3c9e90fb36120bd05fd126ab
c1327c9e00eb82ffb2cac58fa51c7f3a6f3e1
blinded_msg: d1fc97f30efbf116fadd9895130cdd55f939211f7db19ce9a852
87227a02b33fb698b52399f81be0e1f598482000202ec89968085753eae1810f1
4676b514e08238c8aa79d8b999af54e9f4282c6220d4d760716e48e5413f3228c
c59ce10b8252916640de7b9b5c7dc9c2bff9f53b4fb5eb4a5f8bab49af3fd1b95
5d34312073d15030e7fdb44bdb23460d1c5662597f9947092def7fff955a5f3e6
3419ae9858c6405f9609b63c4331e0cf90d24c196bee554f2b78e0d8f6da3d430
8c8d4ae9fbe18a8bb7fa4fc3b9cacd4263e5bd6e12ed891cfdfba8b50d0f37d7a
9abe065238367907c685ed2c224924caf5d8fe41f5db898b09a0501d318d9f65d
88cb8
blinded_sig: 400c1bcdfa56624f15d04f6954908b5605dbeff4cd56f384d753
1669970290d706529d44cde4c972a1399635525a2859ef1d914b4130068ed407c
fda3bd9d1259790a30f6d8c07d190aa98bf21ae9581e5d61801565d96e9eec134
335958b3d0b905739e2fd9f39074da08f869089fe34de2d218062afa16170c150
5c67b65af4dcc2f1aeccd48275c3dacf96116557b7f8c7044d84e296a0501c511
ba1e6201703e1dd834bf47a96e1ac4ec9b935233ed751239bd4b514b031522cd5
1615c1555e520312ed1fa43f55d4abeb222ee48b4746c79006966590004714039
bac7fd18cdd54761924d91a4648e871458937061ef6549dd12d76e37ed417634d
88914
sig: 4062960edb71cc071e7d101db4f595aae4a98e0bfe6843aca3e5f48c9dfb
46d505e8c19806ffa07f040313d44d0996ef9f69a86fa5946cb818a32627fe2df
2a0e80350288ae4fedfbee4193554cc1433d9d27639db8b4635265504d87dca70
54c85e0c882d32887534405e6cc4e7eb4b174383e5ce4eebbfffb217f353102f6
d1a0461ef89238de31b0a0c134dfac0d2a8c533c807ccdd557c6510637596a490
d5258b77410421be4076ecdf2d7e9044327e36e349751f3239681bba10fe633f1
b246f5a9f694706316898c900af2294f47267f2e9ad1e61c7f56bf64328025887
5d29f3745dfdb74b9bbcd5fe3dea62d9be85e2c6f5aed68bc79f8b4a27b3de
Amjad, et al. Expires 14 September 2023 [Page 21]
Internet-Draft Partially Blind RSA Signatures March 2023
// Test vector 3
p: dcd90af1be463632c0d5ea555256a20605af3db667475e190e3af12a34a332
4c46a3094062c59fb4b249e0ee6afba8bee14e0276d126c99f4784b23009bf616
8ff628ac1486e5ae8e23ce4d362889de4df63109cbd90ef93db5ae64372bfe1c5
5f832766f21e94ea3322eb2182f10a891546536ba907ad74b8d72469bea396f3
q: f8ba5c89bd068f57234a3cf54a1c89d5b4cd0194f2633ca7c60b91a795a56f
a8c8686c0e37b1c4498b851e3420d08bea29f71d195cfbd3671c6ddc49cf4c1db
5b478231ea9d91377ffa98fe95685fca20ba4623212b2f2def4da5b281ed0100b
651f6db32112e4017d831c0da668768afa7141d45bbc279f1e0f8735d74395b3
d: 4e21356983722aa1adedb084a483401c1127b781aac89eab103e1cfc522154
94981d18dd8028566d9d499469c25476358de23821c78a6ae43005e26b394e305
1b5ca206aa9968d68cae23b5affd9cbb4cb16d64ac7754b3cdba241b72ad6ddfc
000facdb0f0dd03abd4efcfee1730748fcc47b7621182ef8af2eeb7c985349f62
ce96ab373d2689baeaea0e28ea7d45f2d605451920ca4ea1f0c08b0f1f6711eaa
4b7cca66d58a6b916f9985480f90aca97210685ac7b12d2ec3e30a1c7b97b65a1
8d38a93189258aa346bf2bc572cd7e7359605c20221b8909d599ed9d38164c9c4
abf396f897b9993c1e805e574d704649985b600fa0ced8e5427071d7049d
e: 010001
N: d6930820f71fe517bf3259d14d40209b02a5c0d3d61991c731dd7da39f8d69
821552e2318d6c9ad897e603887a476ea3162c1205da9ac96f02edf31df049bd5
5f142134c17d4382a0e78e275345f165fbe8e49cdca6cf5c726c599dd39e09e75
e0f330a33121e73976e4facba9cfa001c28b7c96f8134f9981db6750b43a41710
f51da4240fe03106c12acb1e7bb53d75ec7256da3fddd0718b89c365410fce61b
c7c99b115fb4c3c318081fa7e1b65a37774e8e50c96e8ce2b2cc6b3b367982366
a2bf9924c4bafdb3ff5e722258ab705c76d43e5f1f121b984814e98ea2b2b8725
cd9bc905c0bc3d75c2a8db70a7153213c39ae371b2b5dc1dafcb19d6fae9
msg:
metadata: 6d65746164617461
eprime: 30584b72f5cb557085106232f051d039e23358feee9204cf30ea56762
0e90d79e4a7a81388b1f390e18ea5240a1d8cc296ce1325128b445c48aa5a3b34
fa07c324bf17bc7f1b3efebaff81d7e032948f1477493bc183d2f8d94c947c984
c6f0757527615bf2a2f0ef0db5ad80ce99905beed0440b47fa5cb9a2334fea40a
d88e6ef1
rand:
f2a4ed7c5aa338430c7026d7d92017f994ca1c8b123b236dae8666b1899059d0
blind: 5b9a334afde50dd24399d1ba9fc1e60be09c7e0cc9e8b8808dfcbc67fe
adeceb34effc9164903149e9de9fb545789fa9885064c58257397500bcaef4e1f
179b88af951636f5c45c1504e4989f9d5af4fb0b171804e2278d1ca85668cabec
6ed9c0f057d5b4f897522b623e5aa3674a4b5dac6174b871ff92f86c1cc81c8f1
d4446210f59219647dbe75bf3e42a17ebba99291e7c45acfa820badae10420c09
3b62e2805932da4e56b1a57a8e31f3a57e2bc59bc72e6ae3563386a7753afeaae
ba1e36a4ab8abe9d0609de4244ae3669157f78f5acd82007f187dc93498bfe3d1
d09ac62b2cb6e5bcd4a202995031690cde0c318ecc13ff5680119ed2773bc751
salt: 5bab5bfebba9eeaa5249e043fcaac352721937e1c3643f35bf815bfc362
73bf17933a0ebc0d0ae90f46077d0e5aadcd6
blinded_msg: 7756a1f89fa33cfc083567e02fd865d07d6e5cd4943f030a2f94
b5c23f3fe79c83c49c594247d02885e2cd161638cff60803184c9e802a659d76a
1c53340972e62e728cc70cf684ef03ce2d05cefc729e6eee2ae46afa17b6b27a6
Amjad, et al. Expires 14 September 2023 [Page 22]
Internet-Draft Partially Blind RSA Signatures March 2023
4f91e4c46cc12adc58d9cb61a4306dac732c9789199cfe8bd28359d1911678e97
09bc159dae34ac7aa59fd0c95962c9f4904bf04aaba8a7e774735bd03be4a02fb
0864a53354a2e2f3502506318a5b03961366005c7b120f0e6b87b44bc15658c3e
8985d69f6adea38c24fe5e7b4bafa1ad6dc7d729281c26dffc88bd34fcc5a5f9d
f9b9781f99ea47472ba8bd679aaada59525b978ebc8a3ea2161de84b7398e4878
b751b
blinded_sig: 2a13f73e4e255a9d5bc6f76cf48dfbf189581c2b170600fd3ab1
a3def148846213239b9d0a981537541cb4f481a602aeebca9ef28c9fcdc63d15d
4296f85d864f799edf08e9045180571ce1f1d3beff293b18aae9d8845068cc0d9
a05b822295042dc56a1a2b604c51aa65fd89e6d163fe1eac63cf603774797b793
6a8b7494d43fa37039d3777b8e57cf0d95227ab29d0bd9c01b3eae9dde5fca714
1919bd83a17f9b1a3b401507f3e3a8e8a2c8eb6c5c1921a781000fee65b6dd851
d53c89cba2c3375f0900001c04855949b7fa499f2a78089a6f0c9b4d36fdfcac2
d846076736c5eaedaf0ae70860633e51b0de21d96c8b43c600afa2e4cc64cd66d
77a8f
sig: 67985949f4e7c91edd5647223170d2a9b6611a191ca48ceadb6c568828b4
c415b6270b037cd8a68b5bca1992eb769aaef04549422889c8b156b9378c50e8a
31c07dc1fe0a80d25b870fadbcc1435197f0a31723740f3084ecb4e762c623546
f6bd7d072aa565bc2105b954244a2b03946c7d4093ba1216ec6bb65b8ca8d2f3f
3c43468e80b257c54a2c2ea15f640a08183a00488c7772b10df87232ee7879bee
93d17e194d6b703aeceb348c1b02ec7ce202086b6494f96a0f2d800f12e855f9c
33dcd3abf6bd8044efd69d4594a974d6297365479fe6c11f6ecc5ea333031c57d
eb6e14509777963a25cdf8db62d6c8c68aa038555e4e3ae4411b28e43c8f57
// Test vector 4
p: dcd90af1be463632c0d5ea555256a20605af3db667475e190e3af12a34a332
4c46a3094062c59fb4b249e0ee6afba8bee14e0276d126c99f4784b23009bf616
8ff628ac1486e5ae8e23ce4d362889de4df63109cbd90ef93db5ae64372bfe1c5
5f832766f21e94ea3322eb2182f10a891546536ba907ad74b8d72469bea396f3
q: f8ba5c89bd068f57234a3cf54a1c89d5b4cd0194f2633ca7c60b91a795a56f
a8c8686c0e37b1c4498b851e3420d08bea29f71d195cfbd3671c6ddc49cf4c1db
5b478231ea9d91377ffa98fe95685fca20ba4623212b2f2def4da5b281ed0100b
651f6db32112e4017d831c0da668768afa7141d45bbc279f1e0f8735d74395b3
d: 4e21356983722aa1adedb084a483401c1127b781aac89eab103e1cfc522154
94981d18dd8028566d9d499469c25476358de23821c78a6ae43005e26b394e305
1b5ca206aa9968d68cae23b5affd9cbb4cb16d64ac7754b3cdba241b72ad6ddfc
000facdb0f0dd03abd4efcfee1730748fcc47b7621182ef8af2eeb7c985349f62
ce96ab373d2689baeaea0e28ea7d45f2d605451920ca4ea1f0c08b0f1f6711eaa
4b7cca66d58a6b916f9985480f90aca97210685ac7b12d2ec3e30a1c7b97b65a1
8d38a93189258aa346bf2bc572cd7e7359605c20221b8909d599ed9d38164c9c4
abf396f897b9993c1e805e574d704649985b600fa0ced8e5427071d7049d
e: 010001
N: d6930820f71fe517bf3259d14d40209b02a5c0d3d61991c731dd7da39f8d69
821552e2318d6c9ad897e603887a476ea3162c1205da9ac96f02edf31df049bd5
5f142134c17d4382a0e78e275345f165fbe8e49cdca6cf5c726c599dd39e09e75
e0f330a33121e73976e4facba9cfa001c28b7c96f8134f9981db6750b43a41710
f51da4240fe03106c12acb1e7bb53d75ec7256da3fddd0718b89c365410fce61b
c7c99b115fb4c3c318081fa7e1b65a37774e8e50c96e8ce2b2cc6b3b367982366
Amjad, et al. Expires 14 September 2023 [Page 23]
Internet-Draft Partially Blind RSA Signatures March 2023
a2bf9924c4bafdb3ff5e722258ab705c76d43e5f1f121b984814e98ea2b2b8725
cd9bc905c0bc3d75c2a8db70a7153213c39ae371b2b5dc1dafcb19d6fae9
msg:
metadata:
eprime: 2ed5a8d2592a11bbeef728bb39018ef5c3cf343507dd77dd156d5eec7
f06f04732e4be944c5d2443d244c59e52c9fa5e8de40f55ffd0e70fbe9093d3f7
be2aafd77c14b263b71c1c6b3ca2b9629842a902128fee4878392a950906fae35
d6194e0d2548e58bbc20f841188ca2fceb20b2b1b45448da5c7d1c73fb6e83fa5
8867397b
rand:
ba3ea4b1e475eebe11d4bfe3a48521d3ba8cd62f3baed9ec29fbbf7ff0478bc0
blind: 910f6bcd2329245a244e7f1d81c4827d85c2687fd458fcf0bb4b7af6ae
81a79e00ab4f2c150a5215dd251cc3a5ed9c5bb2b0dde67dee87477d2786e55fe
f21ee74c8c6cd14208a81579ddf811f30b21595c6ef8e94f63599981da5f01638
a5d6345fab6c95acee5ba0e4e2d43ad77a3b9e4294a30df1db3294e5ca0c092e7
012bbc6cea7a83e73c0ea1a33c3fbf5015d2e4dc7bcbfd051c302eb6a7753d01c
2264f779020989e38206c4600365273323a763357b7819b8ff9e585610828c0ec
542caa68bf2f73f8fb981377699d750512cb66bd693d5e6784f95f86c43f72e9f
9be6b9201a85f1639311dd7e44a7565a3b7fe4b375c5a35cf3444059b05b3863
salt: 4b4ac879a22b5394d4259c817a2cc78713b0438a8de91ffb065f0d66829
e4048367be0278631d8178c3c0d48ad61b665
blinded_msg: 99d725c5613ff87d16464b0375b0976bf4d47319d6946e85f0d0
c2ca79eb02a4c0c282642e090a910b80fee288f0b3b6777e517b757fc6c96ea44
ac570216c8fcd868e15da4b389b0c70898c5a2ed25c1d13451e4d407fe1301c23
1b4dc76826b1d4cc5e64b0e28fb9c71f928ba48c87e308d851dd07fb5a7e0aa5d
0dce61d1348afb4233355374e5898f63adbd5ba215332d3329786fb7c30ef04c1
81b267562828d8cf1295f2ef4a05ef1e03ed8fee65efb7725d8c8ae476f61a359
87e40efc481bcb4b89cb363addfb2adacf690aff5425107d29b2a75b4665d49f2
55c5caa856cdc0c5667de93dbf3f500db8fcce246a70a159526729d82c34df69c
926a8
blinded_sig: a9678acee80b528a836e4784f0690fdddce147e5d4ac506e9ec5
1c11b16ee2fd5a32e382a3c3d276a681bb638b63040388d53894afab79249e159
835cd6bd65849e5d1397666f03d1351aaec3eae8d3e7cba3135e7ec4e7b478ef8
4d79d81039693adc6b130b0771e3d6f0879723a20b7f72b476fe6fef6f21e00b9
e3763a364ed918180f939c3510bb5f46b35c06a00e51f049ade9e47a8e1c3d568
9bd5a43df20b73d70dcacfeed9fa23cabfbe750779997da6bc7269d08b2620aca
a3daa0d9e9d4b87ef841ebcc06a4c0af13f1d13f0808f512c50898586b4fc76d2
b32858a7ddf715a095b7989d8df50654e3e05120a83cec275709cf79571d8f46a
f2b8e
sig: ba57951810dbea7652209eb73e3b8edafc56ca7061475a048751cbfb995a
eb4ccda2e9eb309698b7c61012accc4c0414adeeb4b89cd29ba2b49b1cc661d5e
7f30caee7a12ab36d6b52b5e4d487dbff98eb2d27d552ecd09ca022352c9480ae
27e10c3a49a1fd4912699cc01fba9dbbfd18d1adcec76ca4bc44100ea67b9f1e0
0748d80255a03371a7b8f2c160cf632499cea48f99a6c2322978bd29107d0dffd
d2e4934bb7dc81c90dd63ae744fd8e57bff5e83f98014ca502b6ace876b455d1e
3673525ba01687dce998406e89100f55316147ad510e854a064d99835554de894
9d3662708d5f1e43bca473c14a8b1729846c6092f18fc0e08520e9309a32de
Amjad, et al. Expires 14 September 2023 [Page 24]
Internet-Draft Partially Blind RSA Signatures March 2023
Acknowledgments
Authors' Addresses
Ghous A. Amjad
Google
Email: ghous_amjad@alumni.brown.edu
Scott Hendrickson
Google
Email: scott@shendrickson.com
Christopher A. Wood
Cloudflare
Email: caw@heapingbits.net
Kevin W. L. Yeo
Google
Email: kwlyeo@cs.columbia.edu
Amjad, et al. Expires 14 September 2023 [Page 25]