Internet DRAFT - draft-amjad-cfrg-partially-blind-rsa

draft-amjad-cfrg-partially-blind-rsa







Network Working Group                                        G. A. Amjad
Internet-Draft                                            S. Hendrickson
Intended status: Informational                                    Google
Expires: 14 July 2024                                         C. A. Wood
                                                              Cloudflare
                                                            K. W. L. Yeo
                                                                  Google
                                                         11 January 2024


                     Partially Blind RSA Signatures
                draft-amjad-cfrg-partially-blind-rsa-02

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 July 2024.





Amjad, et al.             Expires 14 July 2024                  [Page 1]

Internet-Draft       Partially Blind RSA Signatures         January 2024


Copyright Notice

   Copyright (c) 2024 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  . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Blind . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.3.  BlindSign . . . . . . . . . . . . . . . . . . . . . . . .   9
     4.4.  Finalize  . . . . . . . . . . . . . . . . . . . . . . . .   9
     4.5.  Verification  . . . . . . . . . . . . . . . . . . . . . .  10
     4.6.  Public Key Derivation . . . . . . . . . . . . . . . . . .  11
     4.7.  Key Pair Derivation . . . . . . . . . . . . . . . . . . .  12
   5.  Implementation and Usage Considerations . . . . . . . . . . .  12
     5.1.  Errors  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     5.2.  Signing Key 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 . . . . . . . . . . . . . . . . . . . . .  16
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  17
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  17
   Appendix B.  Test Vectors . . . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24











Amjad, et al.             Expires 14 July 2024                  [Page 2]

Internet-Draft       Partially Blind RSA Signatures         January 2024


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(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 [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 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 [RSABSSA], RSAPBSSSA is defined in
   such a way that the resulting (unblinded) signature can be verified
   with a standard RSA-PSS library that does not impose a range limit on
   the public exponent.

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:








Amjad, et al.             Expires 14 July 2024                  [Page 3]

Internet-Draft       Partially Blind RSA Signatures         January 2024


   *  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.

   *  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 --
   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 Section 4.1.





Amjad, et al.             Expires 14 July 2024                  [Page 4]

Internet-Draft       Partially Blind RSA Signatures         January 2024


   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:

   blind_msg, inv = Blind(pk, input_msg, info)

   The client then sends blind_msg to the server, which then processes
   the message by computing:

   blind_sig = BlindSign(sk, blind_msg, info)

   The server then sends blind_sig to the client, which then finalizes
   the protocol by computing:

   sig = Finalize(pk, 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 info using the server public
   key pk 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(pk, msg, info)          Server(sk, pk, info)
     -------------------------------------------------------
     input_msg = Prepare(msg)
     blind_msg, inv = Blind(pk, input_msg, info)

                           blind_msg
                           ---------->

               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 Section 4.1 of [RSABSSA].




Amjad, et al.             Expires 14 July 2024                  [Page 5]

Internet-Draft       Partially Blind RSA Signatures         January 2024


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 = 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.

   KeyGen(bits)

   Inputs:
   - bits, length in bits of the RSA modulus, a multiple of 2

   Outputs:
   - sk, metadata-specific private key (n, p, q, phi, d)
   - pk, metadata-specific public key (n, e)

   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. n = p * q
   7. sk = (n, p, q, phi, d)
   8. pk = (n, e)
   9. output (sk, pk)

   The procedure for generating a safe prime, denoted SafePrime, is
   below.








Amjad, et al.             Expires 14 July 2024                  [Page 6]

Internet-Draft       Partially Blind RSA Signatures         January 2024


   SafePrime(bits)

   Inputs:
   - bits, length in bits of the safe prime

   Outputs:
   - p, a safe prime integer

   Steps:
   1. p' = random_prime(bits - 1)
   2. p = (2 * p') + 1
   3. if is_prime(p) is True, output p, else go to step 1.

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 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 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 July 2024                  [Page 7]

Internet-Draft       Partially Blind RSA Signatures         January 2024


Blind(pk, msg, info)

Parameters:
- modulus_len, the length in bytes of the RSA modulus n
- Hash, the hash function used to hash the message
- MGF, the mask generation function
- salt_len, the length in bytes of the salt

Inputs:
- pk, public key (n, e)
- msg, message to be signed, a byte string
- info, public metadata, a byte string

Outputs:
- blind_msg, a byte string of length modulus_len
- 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(info), 4), info, msg)
2. encoded_msg = EMSA-PSS-ENCODE(msg_prime, bit_len(n) - 1)
   with Hash, MGF, and salt_len 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. pk_derived = DerivePublicKey(pk, info)
11. x = RSAVP1(pk_derived, r)
12. z = m * x mod n
13. blind_msg = int_to_bytes(z, modulus_len)
14. output blind_msg, inv

   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 Section 4.6.






Amjad, et al.             Expires 14 July 2024                  [Page 8]

Internet-Draft       Partially Blind RSA Signatures         January 2024


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(sk, blind_msg, info)

Parameters:
- modulus_len, the length in bytes of the RSA modulus n

Inputs:
- sk, private key (n, p, q, phi, d)
- blind_msg, encoded and blinded message to be signed, a
  byte string
- info, public metadata, a byte string

Outputs:
- blind_sig, a byte string of length modulus_len

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(blind_msg)
2. sk_derived, pk_derived = DeriveKeyPair(sk, info)
3. s = RSASP1(sk_derived, m)
4. m' = RSAVP1(pk_derived, s)
5. If m != m', raise "signing failure" and stop
6. blind_sig = int_to_bytes(s, modulus_len)
7. 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 July 2024                  [Page 9]

Internet-Draft       Partially Blind RSA Signatures         January 2024


Finalize(pk, msg, info, blind_sig, inv)

Parameters:
- modulus_len, the length in bytes of the RSA modulus n
- Hash, the hash function used to hash the message
- MGF, the mask generation function
- salt_len, the length in bytes of the salt

Inputs:
- pk, public key (n, e)
- msg, message to be signed, a byte string
- info, public metadata, a byte string
- blind_sig, signed and blinded element, a byte string of
  length modulus_len
- inv, inverse of the blind, an integer

Outputs:
- sig, a byte string of length modulus_len

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) != modulus_len, 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, modulus_len)
5. msg_prime = concat("msg", int_to_bytes(len(info), 4), info, msg)
6. pk_derived = DerivePublicKey(pk, info)
7. result = RSASSA-PSS-VERIFY(pk_derived, msg_prime, sig) with
   Hash, MGF, and salt_len as defined in the parameters
8. If result = "valid signature", output sig, else
   raise "invalid signature" and stop

   Note that pk_derived 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 info.  Clients verify the signature over msg and info
   using the server's public key pk as follows:

   1.  Compute pk_derived = DerivePublicKey(pk, info).



Amjad, et al.             Expires 14 July 2024                 [Page 10]

Internet-Draft       Partially Blind RSA Signatures         January 2024


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

   3.  Invoke and output the result of RSASSA-PSS-VERIFY (Section 8.1.2
       of [RFC8017]) 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.

4.6.  Public Key Derivation

   The public key derivation function (DerivePublicKey) derives a per-
   metadata public key that is used in the core protocol.  The hash
   function used for HKDF as defined in [RFC5869] 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.

DerivePublicKey(pk, info)

Parameters:
- modulus_len, the length in bytes of the RSA modulus n. This MUST be a power of 2.
- Hash, the hash function used to hash the message

Inputs:
- pk, public key (n, e)
- info, public metadata, a byte string

Outputs:
- pk_derived, metadata-specific public key (n, e')

Steps:
1. hkdf_input = concat("key", info, 0x00)
2. hkdf_salt = int_to_bytes(n, modulus_len)
3. lambda_len = modulus_len / 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 pk_derived = (n, e')





Amjad, et al.             Expires 14 July 2024                 [Page 11]

Internet-Draft       Partially Blind RSA Signatures         January 2024


4.7.  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.

   DeriveKeyPair(sk, info)

   Parameters:
   - modulus_len, the length in bytes of the RSA modulus n
   - Hash, the hash function used to hash the message

   Inputs:
   - sk, private key (n, p, q, phi, d)
   - info, public metadata, a byte string

   Outputs:
   - sk_derived, metadata-specific private key (n, p, q, phi, d')
   - pk_derived, metadata-specific public key (n, e')

   Steps:
   1. (n, e') = DerivePublicKey(n, info)
   2. d' = inverse_mod(e', phi)
   3. sk_derived = (n, p, q, phi, d')
   4. pk_derived = (n, e')
   5. Output (sk_derived, pk_derived)

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 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.  Section 4.2



Amjad, et al.             Expires 14 July 2024                 [Page 12]

Internet-Draft       Partially Blind RSA Signatures         January 2024


   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 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 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 instantiation of HKDF in DerivePublicKey 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).

   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).









Amjad, et al.             Expires 14 July 2024                 [Page 13]

Internet-Draft       Partially Blind RSA Signatures         January 2024


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




Amjad, et al.             Expires 14 July 2024                 [Page 14]

Internet-Draft       Partially Blind RSA Signatures         January 2024


   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 7 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
   DerivePublicKey in Section 4.6 do cause errors in DeriveKeyPair in
   Section 4.7.  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 [RSABSSA]).  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.

7.2.  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 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.

   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.





Amjad, et al.             Expires 14 July 2024                 [Page 15]

Internet-Draft       Partially Blind RSA Signatures         January 2024


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 susceptible to Denial of Service (DoS) attacks due to the
   flexibility of choosing public metadata used in DerivePublicKey in
   Section 4.6.  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 [RSABSSA]
   with distinct keys for each metadata value.

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




Amjad, et al.             Expires 14 July 2024                 [Page 16]

Internet-Draft       Partially Blind RSA Signatures         January 2024


   [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>.

   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", RFC 5869,
              DOI 10.17487/RFC5869, May 2010,
              <https://www.rfc-editor.org/rfc/rfc5869>.

   [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>.

   [RSABSSA]  Denis, F., Jacobs, F., and C. A. Wood, "RSA Blind
              Signatures", Work in Progress, Internet-Draft, draft-irtf-
              cfrg-rsa-blind-signatures-14, 10 July 2023,
              <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
              rsa-blind-signatures-14>.

9.2.  Informative References

   [PRIVACY-PASS]
              Celi, S., Davidson, A., Valdez, S., and C. A. Wood,
              "Privacy Pass Issuance Protocol", Work in Progress,
              Internet-Draft, draft-ietf-privacypass-protocol-16, 3
              October 2023, <https://datatracker.ietf.org/doc/html/
              draft-ietf-privacypass-protocol-16>.

   [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>.

Appendix A.  Acknowledgments

   The authors would like to thank Nikita Borisov for pointing out an
   issue with a prior attempt at mitigating DoS attacks.







Amjad, et al.             Expires 14 July 2024                 [Page 17]

Internet-Draft       Partially Blind RSA Signatures         January 2024


Appendix B.  Test Vectors

   This section includes test vectors for the RSAPBSSA-SHA384-PSS-
   Deterministic variant defined in Section 4.  The following parameters
   are specified for each test vector, where each hexidecimal value uses
   an unsigned big-endian 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 SHA-384.

   *  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: Randomly-generated 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.

   // 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



Amjad, et al.             Expires 14 July 2024                 [Page 18]

Internet-Draft       Partially Blind RSA Signatures         January 2024


   821552e2318d6c9ad897e603887a476ea3162c1205da9ac96f02edf31df049bd5
   5f142134c17d4382a0e78e275345f165fbe8e49cdca6cf5c726c599dd39e09e75
   e0f330a33121e73976e4facba9cfa001c28b7c96f8134f9981db6750b43a41710
   f51da4240fe03106c12acb1e7bb53d75ec7256da3fddd0718b89c365410fce61b
   c7c99b115fb4c3c318081fa7e1b65a37774e8e50c96e8ce2b2cc6b3b367982366
   a2bf9924c4bafdb3ff5e722258ab705c76d43e5f1f121b984814e98ea2b2b8725
   cd9bc905c0bc3d75c2a8db70a7153213c39ae371b2b5dc1dafcb19d6fae9
   msg: 68656c6c6f20776f726c64
   info: 6d65746164617461
   eprime: 30581b1adab07ac00a5057e2986f37caaa68ae963ffbc4d36c16ea5f3
   689d6f00db79a5bee56053adc53c8d0414d4b754b58c7cc4abef99d4f0d0b2e29
   cbddf746c7d0f4ae2690d82a2757b088820c0d086a40d180b2524687060d768ad
   5e431732102f4bc3572d97e01dcd6301368f255faae4606399f91fa913a6d699d
   6ef1
   r: d55491221c9a9ce5687b84669880abbc4db57c8f82864a450a5bf7c3f0
   902884fa418c74bf663f3bfcff74a4792356f3ce052f128b084f8b028cf432533
   27514f4b38430c69f19f155634429803badd1f6849d8603882eb9b648b697cb2f
   2c4069b504562e19bb9f1cf99da47c198c2ae04f4bd3add78025e80f146edce48
   dc3e9dc0ba3ee14bc97489050e26dc8935f3ecfcaea07c9c1a3d8e41be1e49dc8
   aa171ac4cec9d1cddd8066b13767901dcb339e2cce40d11f5cff6c870012bca49
   109ce6e81e165d3831531cbf8503f3cfde68340789979cba96602e70613a13869
   aff57f2170e31ebe85564e3f026d8cd1835e59144fb8c008391c55d2fb1a5488
   salt: 648ea74482fbab69876817ee3c2055a6921a458648c802c09a23f8825b2
   59724e41c960ef29febe16a04e120c8b1cc1a
   blind_msg: cfd613e27b8eb15ee0b1df0e1bdda7809a61a29e9b6e9f3ec7c3
   45353437638e85593a7309467e36396b0515686fe87330b312b6f89df26dc1cc8
   8dd222186ca0bfd4ffa0fd16a9749175f3255425eb299e1807b76235befa57b28
   f50db02f5df76cf2f8bcb55c3e2d39d8c4b9a0439e71c5362f35f3db768a5865b
   864fdf979bc48d4a29ae9e7c2ea259dc557503e2938b9c3080974bd86ad8b0daa
   f1d103c31549dcf767798079f88833b579424ed5b3d700162136459dc29733256
   f18ceb74ccf0bc542db8829ca5e0346ad3fe36654715a3686ceb69f73540efd20
   530a59062c13880827607c68d00993b47ad6ba017b95dfc52e567c4bf65135072
   b12a4
   blind_sig: ca7d4fd21085de92b514fbe423c5745680cace6ddfa864a9bd97
   d29f3454d5d475c6c1c7d45f5da2b7b6c3b3bc68978bb83929317da25f491fee8
   6ef7e051e7195f3558679b18d6cd3788ac989a3960429ad0b7086945e8c4d38a1
   b3b52a3903381d9b1bf9f3d48f75d9bb7a808d37c7ecebfd2fea5e89df59d4014
   a1a149d5faecfe287a3e9557ef153299d49a4918a6dbdef3e086eeb264c0c3621
   bcd73367195ae9b14e67597eaa9e3796616e30e264dc8c86897ae8a6336ed2cd9
   3416c589a058211688cf35edbd22d16e31c28ff4a5c20f1627d09a71c71af372e
   dc18d2d7a6e39df9365fe58a34605fa1d9dc53efd5a262de849fb083429e20586
   e210e
   sig: cdc6243cd9092a8db6175b346912f3cc55e0cf3e842b4582802358dddf6f
   61decc37b7a9ded0a108e0c857c12a8541985a6efad3d17f7f6cce3b5ee20016e
   5c36c7d552c8e8ff6b5f3f7b4ed60d62eaec7fc11e4077d7e67fc6618ee092e20
   05964b8cf394e3e409f331dca20683f5a631b91cae0e5e2aa89eeef4504d24b45
   127abdb3a79f9c71d2f95e4d16c9db0e7571a7f524d2f64438dfb32001c00965f
   f7a7429ce7d26136a36ebe14644559d3cefc477859dcd6908053907b325a34aaf



Amjad, et al.             Expires 14 July 2024                 [Page 19]

Internet-Draft       Partially Blind RSA Signatures         January 2024


   654b376fade40df4016ecb3f5e1c89fe3ec500a04dfe5c8a56cad5b086047d2f9
   63ca73848e74cf24bb8bf1720cc9de4c78c64449e8af3e7cddb0dab1821998

   // 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
   a2bf9924c4bafdb3ff5e722258ab705c76d43e5f1f121b984814e98ea2b2b8725
   cd9bc905c0bc3d75c2a8db70a7153213c39ae371b2b5dc1dafcb19d6fae9
   msg: 68656c6c6f20776f726c64
   info:
   eprime: 2ed579fcdf2d328ebc686c52ccaec247018832acd530a2ac72c0ec2b9
   2db5d6bd578e91b6341c1021142b45b9e6e5bf031f3dd62226ec4a0f9ef99e45d
   d9ccd60aa60a0c59aac271a8caf9ee68a9d9ff281367dae09d588d3c7bca7f18d
   e48b6981bbc729c4925c65e4b2a7f054facbb7e5fc6e4c6c10110c62ef0b94eec
   397b
   r: 532103acf62670e3176eb1cfee7c2c46c7986704b869387924c33e8358
   8c7cac67882570aede836b51b44a565c872a91bbf4f0f8396019113ef382963d3
   a51b91429993e821217d3e85b2253e0daa0e9cfc440c37a37707f7aed383d98b3
   150f21e1146c58c28d4a49046b8e97f834e4cb95e5483dfc42eaa17bdce947631
   7f710b7488cc06cf61a1c449faa1d34119f2c3cd6ead79f9de14358b1c750bf2c
   312fcbba3c511341fd4952ba2fcd486a9e81fd829e47cd8a0ac0273d7594c69eb
   4aebfaec3c59aa1a016582410d9f4be14dac4b1a66f61eeb3e108af3868e410f7
   7436765ba1df7c9a5cf37d8ec3dced6f5689da9703618a5cc7bf6d60f7b4209c
   salt: 134520fb9ae6076594b4488fa31cae4e8e3efaca5ae4377bd586aac58e9
   0f8925826b4b4fff2e21fdb933c4fbb6467a2
   blind_msg: 5e6568cd0bf7ea71ad91e0a9708abb5e97661c41812eb994b672
   f10aa8983151113aeaabcf1306fa5a493e3dbdd58fc8bdb61aac934fae832676b



Amjad, et al.             Expires 14 July 2024                 [Page 20]

Internet-Draft       Partially Blind RSA Signatures         January 2024


   cab7abacdcc1b9c1f2af3586ae009042293b6945fee0aeffb2d2b8a24f82614b8
   be39bab71a535f6d65f1631e927dbd471b0753e7a63a201c7ecd26e7fbbb5e21e
   02f865b64e20731004c395b0e059a92fffa4c636ac4c00db9aa086b5dd1a3dd10
   1bb04970b12ca3f4936f246e32d394f328cea2510554060e8d291acdbee04b8bc
   91e967241ba45f3509d63ded5f9b358f4216f37a885e563b7baa93a717ca7cdbe
   10e398d14bb2d5a1376b4a5f83226ce2c575087bc28d743caeff9c1b11cc8bd02
   f5f14
   blind_sig: 72c4e0f4f677aa1dbb686e23b5944b3afdc7f824711a1f7486d1
   ed6fa20aad255a1412885aee04c64359964e694a713da2a1684325c1c31401cac
   1ea39a9e454675b55f743ff144ac605d0ed254b12d9bdd43b0e8a17c0d4711239
   732e45e4166261d0b16d2f29403c5f2584a29b225daa7530ba15fc9af15ed2ce8
   fcb126ad0b0758fd522fbf99a83e4cfe0539aa264d06a1633deee0053f45fc8a9
   44f1468a0c0c449155139779a3230c8fa41a81858418151fa195f57ea645699f5
   50d3cb37c549542d436071d1af74e629f938fa4717ca9def382fc35089e4caec9
   e5d740c38ecb2aa88c90176d2f322866acfd50e2b92313161e81327f889aca0c9
   4bcb8
   sig: a7ace477c1f416a40e93ddf8a454f9c626b33c5a20067d81bdfef7b88bc1
   5de2b04624478b2134b4b23d91285d72ca4eb9c6c911cd7be2437f4e3b24426bc
   e1a1cb52e2c8a4d13f7fd5c9b0f943b92b8bbcba805b847a0ea549dbc249f2e81
   2bf03dd6b2588c8af22bf8b6bba56ffd8d2872b2f0ebd42ac8bd8339e5e638061
   99deec3cf392c078f66e72d9be817787d4832c45c1f192465d87f6f6c333ce1e8
   c5641c7069280443d2227f6f28ff2045acdc368f2f94c38a3c909591a27c93e17
   78630aeeeb623805f37c575213091f096be14ffa739ee55b3f264450210a4b2e6
   1a9b12141ca36dd45e3b81116fc286e469b707864b017634b8a409ae99c9f1

   // 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



Amjad, et al.             Expires 14 July 2024                 [Page 21]

Internet-Draft       Partially Blind RSA Signatures         January 2024


   c7c99b115fb4c3c318081fa7e1b65a37774e8e50c96e8ce2b2cc6b3b367982366
   a2bf9924c4bafdb3ff5e722258ab705c76d43e5f1f121b984814e98ea2b2b8725
   cd9bc905c0bc3d75c2a8db70a7153213c39ae371b2b5dc1dafcb19d6fae9
   msg:
   info: 6d65746164617461
   eprime: 30581b1adab07ac00a5057e2986f37caaa68ae963ffbc4d36c16ea5f3
   689d6f00db79a5bee56053adc53c8d0414d4b754b58c7cc4abef99d4f0d0b2e29
   cbddf746c7d0f4ae2690d82a2757b088820c0d086a40d180b2524687060d768ad
   5e431732102f4bc3572d97e01dcd6301368f255faae4606399f91fa913a6d699d
   6ef1
   r: 6e1de89fc58417836aa76fefe4876b8b311af2eb94a8226d5796273171
   48551d90b6f9db614b590e7f66f34644a2f6a3568ec78852b7f45876f576a7ee6
   0c19bb0fbbdf1c85d7b36cf7bdf80fb925830c07285efae69e0c019d8d99fd5c6
   20f83361c9411541fddf4bfe27e73f756bf594742a8253119d134e1ad67f02228
   59c4ab243868bb23a6468c01ead9a617657056685f19fcd423b9e916c5e3e3b21
   f92d0e12667d695084a42ae97a548d5982a51b67dd09c188c051d20236e24b231
   e80a96449390e9032bad350645f5d4a162ddf3d61506ef6737b4f9fe6064a1d2f
   afc7849e5039a98ebf14a800dc2423fccc1293f28a2c66ec22983cab922c1cc6
   salt: 1ade5e965d1946a69dc495e78c8524910094f08405471664d4898fa3612
   bf03fd03b3ae8140a737cb13e223e35219b58
   blind_msg: 92d5456738e0cfe0fa770b51e6a72d633d7cec3a945459f1db96
   dbc500a5d1bca34a839059579759301c098231b102fb1e114bf9f892f42f902a3
   36f4a3585b23efa906dfcb94213f4d3b39951551cedecbf51efa213ad030cf821
   ee3fa46a57d67429f838ff728f47111f7f1b22000a979c0f56cc581396935780d
   76173410d2a8a5688cd59622903008fe50af1fcc5e7cf96affad7e60fbed67996
   c7a377effa0f08d9273cd33536b2625c9575d10636cc964636a1500f4fcb22aab
   bef77fe415cbc7245c1032d34bd480ee338f55be0a79c0076d9cf9c94c0db3003
   a33b23c62dbd1a85f2b15db5d153b318cca53c6d68e1e63bafa39c9a43be72f36
   d2569
   blind_sig: a76a1c53566a9781de04d87e8c3a0bc902b47819e7b900580654
   215b0a710cb563b085b5e9fff150791f759da03a139dfc9159c21410f1e3d345b
   8c5dcca35211772900f85c5eec065987cbdbf303e9651196223263a713e4135d6
   b20bfa8fb8212341665647a9a7e07a831ccbf9e62d9366ec9ac0bbe96228e6fbb
   848f8f6f474cce68e3556dc882847e9e61b5b5e02bbfd6152aeca74e8782a54ff
   e6552d63fb837738a05044b38f7e908c4989b202bd858695c61e12cf9d47ef276
   a17917e39f942871defd9747541957b1e2f8950da43c9a05ba4835bded23c24cf
   64edfee10dd0c70b071427cfcbb8b5eb225daf149a6b4d42bebcc536380a9d753
   a8b1e
   sig: 02bc0f2728e2b8cd1c1b9873d4b7f5a62017430398165a6f8964842eaa19
   c1de292207b74dc25ee0aa90493216d3fbf8e1b2947fd64335277b34767f987c4
   82c69262967c8a8aaf180a4006f456c804cdc7b92d956a351ad89703cc76f69ed
   45f24d68e1ae0361479e0f6faf10c3b1582de2dcd2af432d57c0c89c8efb1cf3a
   c5f991fe9c4f0ad24473939b053674a2582518b4bd57da109f4f37bc91a2f806e
   82bb2b80d486d0694e663992c9517c946607b978f557bbb769d4cd836d693c77d
   a480cd89b916e5e4190f317711d9c7e64528a314a14bf0b9256f4c60e9ddb5505
   83c21755ab882bdfdf22dc840249389b1e0a2189f58e19b41c5f313cddce29

   // Test vector 4



Amjad, et al.             Expires 14 July 2024                 [Page 22]

Internet-Draft       Partially Blind RSA Signatures         January 2024


   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:
   info:
   eprime: 2ed579fcdf2d328ebc686c52ccaec247018832acd530a2ac72c0ec2b9
   2db5d6bd578e91b6341c1021142b45b9e6e5bf031f3dd62226ec4a0f9ef99e45d
   d9ccd60aa60a0c59aac271a8caf9ee68a9d9ff281367dae09d588d3c7bca7f18d
   e48b6981bbc729c4925c65e4b2a7f054facbb7e5fc6e4c6c10110c62ef0b94eec
   397b
   r: 35deeb769ae3dce60033cbaeceeec511cd980307f53810c1b33934eeee
   c194283834419fb190881213cfc0d91ff6307862ce143586ad9580057e3af6bb4
   a405075ed9abf1f3b5a5cfb0c7fc59b952401cb28c04f9f85a9a3708fd51c74af
   a1a1028a821beb2f8165678657f0d2effb7a1add5421216f3c50253a6f8d0d8ed
   492f947d58b42527a2249b08e5ab05c25362ad8112bdea931544711b2a3d30e61
   e2c8a130ea7f90fe915b5c3adaa24a6c300c23d8f670d330b592a7c05f7588324
   688ae10e06290ab160096ce132a5ed220d2fbe6b4722cc30e05316b30f500b2ac
   15038555289ea405025740a1d2a3098d34d094b566d0b973e661d855fb90be3c
   salt: df4fbdf415184c20fad0418f27c35974db8c321e84c54b21e1e2619dbfa
   0ad70db62c01783ffe796e8474596d7eb3fd8
   blind_msg: ba562cba0e69070dc50384456391defa410d36fa853fd235902f
   f5d015d688a44def6b6a7e71a69bff8ee510f5a9aa44e9afddd3e766f2423b3fc
   783fd1a9ab618586110987c1b3ddce62d25cae500aa92a6b886cb609829d06e67
   fbf28fbbf3ee7d5cc125481dd002b908097732e0df06f288cc6eb54565f8153d4
   80085b56ab6cb5801b482d12f50558eb3cb0eb7a4ff8fcc54d4d7fcc2f8913a40
   1ae1d1303ead7964f2746e4804e2848bba87f53cf1412afedc82d9c383dd095e0



Amjad, et al.             Expires 14 July 2024                 [Page 23]

Internet-Draft       Partially Blind RSA Signatures         January 2024


   eb6f90cc74bc4bb5ea7529ded9cde2d489575d549b884379abe6d7b71969e6a9c
   09f1963d2719eefccd5f2a407845961ccc1fa580a93c72902b2499d96f89e6c53
   fc888
   blind_sig: 280c5934022fd17f7f810d4f7adf1d29ced47d098834411d6721
   63cc793bcaad239d07c4c45048a682995950ce84703064cd8c16d6f2579f7a65b
   66c274faccc6c73c9d299dcf35c96338c9b81af2f93554a78528551e04be931c8
   502ee6a21ef65d1fa3cd049a993e261f85c841b75857d6bf02dd4532e14702f8f
   5e1261f7543535cdf9379243b5b8ca5cd69d2576276a6c25b78ab7c69d2b0c568
   eb57cf1731983016dece5b59e75301ca1a148154f2592c8406fee83a434f7b319
   2649c5be06000866ff40bf09b558c7af4bbb9a79d5d13151e7b6e602e30c4ab70
   bbbce9c098c386e51b98aefab67b8efc03f048210a785fd538ee6b75ecd484c13
   40d91
   sig: b7d45ec4db11f9b74a6b33806e486f7ee5f87c4fa7c57d08caf0ca6d3ba5
   5e66bf0769c84b9187b9a86e49ba0cb58348f01156ac5bc2e9570fe0a8c33d0ad
   049a965aeb2a8d8a3cbb30f89a3da6732a9bb3d9415141be4e9052f49d422301a
   9cfce49947db7d52a1c620b7106ae43afbcb7cb29b9c215e0c2b4cf8d62db6722
   4dd3de9f448f7b6607977c608595d29380b591a2bff2dff57ea2c77e9cdf69c18
   21ff183a7626d45bbe1197767ac577715473d18571790b1cf59ee35e64362c826
   246ae83923d749117b7ec1b4478ee15f990dc200745a45f175d23c8a13d2dbe58
   b1f9d10db71917708b19eeeab230fe6026c249342216ee785d9422c3a8dc89

Authors' Addresses

   Ghous A. Amjad
   Google
   Email: gamjad@google.com


   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 July 2024                 [Page 24]