rfc9474.original   rfc9474.txt 
Network Working Group F. Denis Internet Research Task Force (IRTF) F. Denis
Internet-Draft Fastly Inc. Request for Comments: 9474 Fastly Inc.
Intended status: Informational F. Jacobs Category: Informational F. Jacobs
Expires: 11 January 2024 Apple Inc. ISSN: 2070-1721 Apple Inc.
C. A. Wood C. A. Wood
Cloudflare Cloudflare
10 July 2023 October 2023
RSA Blind Signatures RSA Blind Signatures
draft-irtf-cfrg-rsa-blind-signatures-14
Abstract Abstract
This document specifies an RSA-based blind signature protocol. RSA This document specifies an RSA-based blind signature protocol. RSA
blind signatures were first introduced by Chaum for untraceable blind signatures were first introduced by Chaum for untraceable
payments. A signature that is output from this protocol can be payments. A signature that is output from this protocol can be
verified as an RSA-PSS signature. verified as an RSA-PSS signature.
This document is a product of the Crypto Forum Research Group (CFRG) This document is a product of the Crypto Forum Research Group (CFRG)
in the IRTF. in the IRTF.
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
https://github.com/chris-wood/draft-wood-cfrg-blind-signatures.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This document is a product of the Internet Research Task Force
and may be updated, replaced, or obsoleted by other documents at any (IRTF). The IRTF publishes the results of Internet-related research
time. It is inappropriate to use Internet-Drafts as reference and development activities. These results might not be suitable for
material or to cite them other than as "work in progress." deployment. This RFC represents the consensus of the Crypto Forum
Research Group of the Internet Research Task Force (IRTF). Documents
approved for publication by the IRSG are not candidates for any level
of Internet Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on 11 January 2024. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9474.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document.
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation
3. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Notation
4. Blind Signature Protocol . . . . . . . . . . . . . . . . . . 4 4. Blind Signature Protocol
4.1. Prepare . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Prepare
4.2. Blind . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Blind
4.3. BlindSign . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. BlindSign
4.4. Finalize . . . . . . . . . . . . . . . . . . . . . . . . 8 4.4. Finalize
4.5. Verification . . . . . . . . . . . . . . . . . . . . . . 9 4.5. Verification
5. RSABSSA Variants . . . . . . . . . . . . . . . . . . . . . . 10 5. RSABSSA Variants
6. Implementation and Usage Considerations . . . . . . . . . . . 11 6. Implementation and Usage Considerations
6.1. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Errors
6.2. Signing Key Generation and Usage . . . . . . . . . . . . 11 6.2. Signing Key Generation and Usage
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations
7.1. Timing Side Channels and Fault Attacks . . . . . . . . . 12 7.1. Timing Side Channels and Fault Attacks
7.2. Message Robustness . . . . . . . . . . . . . . . . . . . 13 7.2. Message Robustness
7.3. Message Entropy . . . . . . . . . . . . . . . . . . . . . 13 7.3. Message Entropy
7.4. Randomness Generation . . . . . . . . . . . . . . . . . . 14 7.4. Randomness Generation
7.5. Key Substitution Attacks . . . . . . . . . . . . . . . . 14 7.5. Key Substitution Attacks
7.6. Alternative RSA Encoding Functions . . . . . . . . . . . 14 7.6. Alternative RSA Encoding Functions
7.7. Post-Quantum Readiness . . . . . . . . . . . . . . . . . 15 7.7. Post-Quantum Readiness
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.1. Normative References
9.2. Informative References . . . . . . . . . . . . . . . . . 15 9.2. Informative References
Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Test Vectors
A.1. RSABSSA-SHA384-PSS-Randomized Test Vector . . . . . . . . 19 A.1. RSABSSA-SHA384-PSS-Randomized Test Vector
A.2. RSABSSA-SHA384-PSSZERO-Randomized Test Vector . . . . . . 22 A.2. RSABSSA-SHA384-PSSZERO-Randomized Test Vector
A.3. RSABSSA-SHA384-PSS-Deterministic Test Vector . . . . . . 25 A.3. RSABSSA-SHA384-PSS-Deterministic Test Vector
A.4. RSABSSA-SHA384-PSSZERO-Deterministic Test Vector . . . . 28 A.4. RSABSSA-SHA384-PSSZERO-Deterministic Test Vector
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31 Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses
1. Introduction 1. Introduction
Originally introduced in the context of digital cash systems by Chaum Originally introduced in the context of digital cash systems by Chaum
for untraceable payments [Chaum83], RSA blind signatures turned out for untraceable payments [Chaum83], RSA blind signatures turned out
to have a wide range of applications ranging from privacy-preserving to have a wide range of applications ranging from privacy-preserving
digital payments to authentication mechanisms [GoogleVPN] digital payments to authentication mechanisms [GoogleVPN]
[ApplePrivateRelay] [PrettyGoodPhonePrivacy]. [ApplePrivateRelay] [PrettyGoodPhonePrivacy].
Recently, interest in blind signatures has grown to address Recently, interest in blind signatures has grown to address
skipping to change at page 3, line 29 skipping to change at line 110
valid for a given input. This limitation complicates deployments valid for a given input. This limitation complicates deployments
where it is not desirable to distribute private keys to entities where it is not desirable to distribute private keys to entities
performing verification. Additionally, if the private key is kept in performing verification. Additionally, if the private key is kept in
a Hardware Security Module, the number of operations on the key is a Hardware Security Module, the number of operations on the key is
doubled compared to a scheme where only the public key is required doubled compared to a scheme where only the public key is required
for verification. for verification.
In contrast, digital signatures provide a primitive that is publicly In contrast, digital signatures provide a primitive that is publicly
verifiable and does not require access to the private key for verifiable and does not require access to the private key for
verification. Moreover, [JKK14] shows that one can realize a VOPRF verification. Moreover, [JKK14] shows that one can realize a VOPRF
in the Random Oracle Model by hashing a signature-message pair, where in the random oracle model by hashing a (message, signature) pair,
the signature is computed using a deterministic blind signature where the signature is computed using a deterministic blind signature
protocol. protocol.
This document specifies a protocol for computing RSA blind signatures This document specifies (1) a protocol for computing RSA blind
using RSA-PSS encoding, and a family of variants for this protocol, signatures using RSA-PSS encoding and (2) a family of variants
denoted RSABSSA (RSA Blind Signature with Appendix). In order to (Section 5) for this protocol, denoted RSABSSA (RSA Blind Signature
facilitate deployment, it is defined in such a way that the resulting with Appendix). In order to facilitate deployment, it is defined in
(unblinded) signature can be verified with a standard RSA-PSS such a way that the resulting (unblinded) signature can be verified
library. with a standard RSA-PSS library.
This document represents the consensus of the Crypto Forum Research This document represents the consensus of the Crypto Forum Research
Group (CFRG). It is not an IETF product and is not a standard. Group (CFRG). It is not an IETF product and is not a standard.
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Notation 3. Notation
The following terms are used throughout this document to describe the The following terms, which describe different protocol operations,
protocol operations in this document: are used throughout this document:
* bytes_to_int and int_to_bytes: Convert a byte string to and from a bytes_to_int and int_to_bytes:
non-negative integer. bytes_to_int and int_to_bytes are Convert a byte string to and from a non-negative
implemented as OS2IP and I2OSP as described in [RFC8017], integer. bytes_to_int and int_to_bytes are implemented as OS2IP
respectively. Note that these functions operate on byte strings and I2OSP -- as described in [RFC8017] -- respectively. Note that
in big-endian byte order. these functions operate on byte strings in big-endian byte order.
* random_integer_uniform(M, N): Generate a random, uniformly random_integer_uniform(M, N):
distributed integer R between M inclusive and N exclusive, i.e., M Generate a random, uniformly distributed integer R between M
<= R < N. inclusive and N exclusive, i.e., M <= R < N.
* bit_len(n): Compute the minimum number of bits needed to represent bit_len(n):
the positive integer 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 inverse_mod(x, n):
or fail if x and n are not co-prime. 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 is_coprime(x, n): Return true if x and n are co-prime, and false
otherwise. otherwise.
* len(s): The length of a byte string, in bytes. len(s): The length of a byte string, in bytes.
* random(n): Generate n random bytes using a cryptographically- random(n):
secure random number generator. Generate n random bytes using a cryptographically secure random
number generator.
* concat(x0, ..., xN): Concatenation of byte strings. For example, concat(x0, ..., xN):
concat(0x01, 0x0203, 0x040506) = 0x010203040506. Concatenation of byte strings. For example, concat(0x01, 0x0203,
0x040506) = 0x010203040506.
* slice(x, i, j): Return bytes in the byte string x starting from slice(x, i, j): Return bytes in the byte string x starting from
offset i and ending at offset j, inclusive. For example, offset i and ending at offset j, inclusive. For example,
slice(0x010203040506, 1, 5) = 0x0203040506. slice(0x010203040506, 1, 5) = 0x0203040506.
4. Blind Signature Protocol 4. Blind Signature Protocol
The RSA Blind Signature Protocol is a two-party protocol between a The RSA Blind Signature Protocol is a two-party protocol between a
client and server where they interact to compute sig = Sign(sk, client and server where they interact to compute sig = Sign(sk,
input_msg), where input_msg = Prepare(msg) is a prepared version of input_msg), where input_msg = Prepare(msg) is a prepared version of
the private message msg provided by the client, and sk is the private the private message msg provided by the client, and sk is the private
signing key provided by the server. See Section 6.2 for details on signing key provided by the server. See Section 6.2 for details on
how sk is generated and used in this protocol. Upon completion of how sk is generated and used in this protocol. Upon completion of
this protocol, the server learns nothing, whereas the client learns this protocol, the server learns nothing, whereas the client learns
sig. In particular, this means the server learns nothing of msg or sig. In particular, this means the server learns nothing of msg or
input_msg and the client learns nothing of sk. input_msg and the client learns nothing of sk.
The protocol consists of four functions -- Prepare, Blind, BlindSign, The protocol consists of four functions -- Prepare, Blind, BlindSign,
and Finalize -- and requires one round of interaction between client and Finalize -- and requires one round of interaction between client
and server. Let msg be the client's private input message, and (sk, and server. Let msg be the client's private input message, and let
pk) be the server's private and public key pair. (sk, pk) be the server's private and public key pair.
The protocol begins by the client preparing the message to be signed The protocol begins by the client preparing the message to be signed
by computing: by computing:
input_msg = Prepare(msg) input_msg = Prepare(msg)
The client then initiates the blind signature protocol by computing: The client then initiates the blind signature protocol by computing:
blinded_msg, inv = Blind(pk, input_msg) blinded_msg, inv = Blind(pk, input_msg)
skipping to change at page 5, line 37 skipping to change at line 216
sig = Finalize(pk, input_msg, blind_sig, inv) sig = Finalize(pk, input_msg, blind_sig, inv)
The output of the protocol is input_msg and sig. Upon completion, The output of the protocol is input_msg and sig. Upon completion,
correctness requires that clients can verify signature sig over the correctness requires that clients can verify signature sig over the
prepared message input_msg using the server public key pk by invoking prepared message input_msg using the server public key pk by invoking
the RSASSA-PSS-VERIFY routine defined in Section 8.1.2 of [RFC8017]. the RSASSA-PSS-VERIFY routine defined in Section 8.1.2 of [RFC8017].
The Finalize function performs this check before returning the The Finalize function performs this check before returning the
signature. See Section 4.5 for more details about verifying signature. See Section 4.5 for more details about verifying
signatures produced through this protocol. signatures produced through this protocol.
In pictures, the protocol runs as follows: Shown graphically, the protocol runs as follows:
Client(pk, msg) Server(sk, pk) Client(pk, msg) Server(sk, pk)
----------------------------------------------------- -----------------------------------------------------
input_msg = Prepare(msg) input_msg = Prepare(msg)
blinded_msg, inv = Blind(pk, input_msg) blinded_msg, inv = Blind(pk, input_msg)
blinded_msg blinded_msg
----------> ---------->
blind_sig = BlindSign(sk, blinded_msg) blind_sig = BlindSign(sk, blinded_msg)
skipping to change at page 6, line 13 skipping to change at line 241
sig = Finalize(pk, input_msg, blind_sig, inv) sig = Finalize(pk, input_msg, blind_sig, inv)
In the remainder of this section, we specify the Prepare, Blind, In the remainder of this section, we specify the Prepare, Blind,
BlindSign, and Finalize functions that are used in this protocol. BlindSign, and Finalize functions that are used in this protocol.
4.1. Prepare 4.1. Prepare
Message preparation, denoted by the Prepare function, is the process Message preparation, denoted by the Prepare function, is the process
by which the message to be signed and verified is prepared for input by which the message to be signed and verified is prepared for input
to the blind signing protocol. There are two types of preparation to the blind signing protocol. There are two types of preparation
functions: an identity preparation function, and a randomized functions: an identity preparation function and a randomized
preparation function. The identity preparation function returns the preparation function. The identity preparation function returns the
input message without transformation, i.e., msg = input message without transformation, i.e., msg =
PrepareIdentity(msg). PrepareIdentity(msg).
The randomized preparation function augments the input message with The randomized preparation function augments the input message with
fresh randomness. We denote this process by the function fresh randomness. We denote this process by the function
PrepareRandomize(msg), which takes as input a message msg and PrepareRandomize(msg), which takes as input a message msg and
produces a randomized message input_msg. Its implementation is shown produces a randomized message input_msg. Its implementation is shown
below. below.
skipping to change at page 6, line 42 skipping to change at line 270
Steps: Steps:
1. msg_prefix = random(32) 1. msg_prefix = random(32)
2. input_msg = concat(msg_prefix, msg) 2. input_msg = concat(msg_prefix, msg)
3. output input_msg 3. output input_msg
4.2. Blind 4.2. Blind
The Blind function encodes an input message and blinds it with the The Blind function encodes an input message and blinds it with the
server's public key. It outputs the blinded message to be sent to server's public key. It outputs the blinded message to be sent to
the server, encoded as a byte string, and the corresponding inverse, the server, encoded as a byte string, and the corresponding inverse,
an integer. RSAVP1 and EMSA-PSS-ENCODE are as defined in Sections an integer. RSAVP1 and EMSA-PSS-ENCODE are as defined in
5.2.2 and 9.1.1 of [RFC8017], respectively. Sections 5.2.2 and 9.1.1 of [RFC8017], respectively.
If this function fails with an "blinding error" error, If this function fails with a "blinding error" error, implementations
implementations SHOULD retry the function again. The probability of SHOULD try the function again. The probability of one or more such
one or more such errors in sequence is negligible. This function can errors in sequence is negligible. This function can also fail with
also fail with an "invalid input" error, which indicates that one of an "invalid input" error, which indicates that one of the inputs
the inputs (likely the public key) was invalid. Implementations (likely the public key) was invalid. Implementations SHOULD update
SHOULD update the public key before calling this function again. See the public key before calling this function again. See Section 6.1
Section 6.1 for more information about dealing with such errors. for more information about dealing with such errors.
Note that this function invokes RSAVP1, which is defined to throw an Note that this function invokes RSAVP1, which is defined to throw an
optional error for invalid inputs. However, this error cannot occur optional error for invalid inputs. However, this error cannot occur
based on how RSAVP1 is invoked, so this error is not included in the based on how RSAVP1 is invoked, so this error is not included in the
list of errors for Blind. list of errors for Blind.
Blind(pk, msg) Blind(pk, msg)
Parameters: Parameters:
- modulus_len, the length in bytes of the RSA modulus n - modulus_len, the length in bytes of the RSA modulus n
- Hash, the hash function used to hash the message - Hash, the hash function used to hash the message
- MGF, the mask generation function - MGF, the mask generation function
- salt_len, the length in bytes of the salt (denoted sLen in RFC8017) - salt_len, the length in bytes of the salt (denoted sLen
in RFC 8017)
Inputs: Inputs:
- pk, server public key (n, e) - pk, server public key (n, e)
- msg, message to be signed, a byte string - msg, message to be signed, a byte string
Outputs: Outputs:
- blinded_msg, a byte string of length modulus_len - blinded_msg, a byte string of length modulus_len
- inv, an integer used to unblind the signature in Finalize - inv, an integer used to unblind the signature in Finalize
Errors: Errors:
- "message too long": Raised when the input message is too long (raised by EMSA-PSS-ENCODE). - "message too long": Raised when the input message is too long
- "encoding error": Raised when the input message fails encoding (raised by EMSA-PSS-ENCODE). (raised by EMSA-PSS-ENCODE)
- "blinding error": Raised when the inverse of r cannot be found. - "encoding error": Raised when the input message fails encoding
- "invalid input": Raised when the message is not co-prime with n. (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: Steps:
1. encoded_msg = EMSA-PSS-ENCODE(msg, bit_len(n)) 1. encoded_msg = EMSA-PSS-ENCODE(msg, bit_len(n))
with Hash, MGF, and salt_len as defined in the parameters with Hash, MGF, and salt_len as defined in the parameters
2. If EMSA-PSS-ENCODE raises an error, raise the error and stop 2. If EMSA-PSS-ENCODE raises an error, re-raise the error and stop
3. m = bytes_to_int(encoded_msg) 3. m = bytes_to_int(encoded_msg)
4. c = is_coprime(m, n) 4. c = is_coprime(m, n)
5. If c is false, raise an "invalid input" error 5. If c is false, raise an "invalid input" error and stop
and stop 6. r = random_integer_uniform(1, n)
6. r = random_integer_uniform(1, n) 7. inv = inverse_mod(r, n)
7. inv = inverse_mod(r, n) 8. If inverse_mod fails, raise a "blinding error" error and stop
8. If inverse_mod fails, raise an "blinding error" error 9. x = RSAVP1(pk, r)
and stop 10. z = (m * x) mod n
9. x = RSAVP1(pk, r) 11. blinded_msg = int_to_bytes(z, modulus_len)
10. z = (m * x) mod n 12. output blinded_msg, inv
11. blinded_msg = int_to_bytes(z, modulus_len)
12. output blinded_msg, inv
The blinding factor r MUST be randomly chosen from a uniform The blinding factor r MUST be randomly chosen from a uniform
distribution. This is typically done via rejection sampling. distribution. This is typically done via rejection sampling.
4.3. BlindSign 4.3. BlindSign
BlindSign performs the RSA private key operation on the client's BlindSign performs the RSA private key operation on the client's
blinded message input and returns the output encoded as a byte blinded message input and returns the output encoded as a byte
string. RSASP1 is as defined in Section 5.2.1 of [RFC8017]. string. RSASP1 is as defined in Section 5.2.1 of [RFC8017].
BlindSign(sk, blinded_msg) BlindSign(sk, blinded_msg)
Parameters: Parameters:
- modulus_len, the length in bytes of the RSA modulus n - modulus_len, the length in bytes of the RSA modulus n
Inputs: Inputs:
- sk, server private key - sk, server private key
- blinded_msg, encoded and blinded message to be signed, a - blinded_msg, encoded and blinded message to be signed, a
byte string byte string
Outputs: Outputs:
- blind_sig, a byte string of length modulus_len - blind_sig, a byte string of length modulus_len
Errors: Errors:
- "signing failure": Raised when the signing operation fails - "signing failure": Raised when the signing operation fails
- "message representative out of range": Raised when the message representative - "message representative out of range": Raised when the
to sign is not an integer between 0 and n - 1 (raised by RSASP1) message representative to sign is not an integer between 0
and n - 1 (raised by RSASP1)
Steps: Steps:
1. m = bytes_to_int(blinded_msg) 1. m = bytes_to_int(blinded_msg)
2. s = RSASP1(sk, m) 2. s = RSASP1(sk, m)
3. m' = RSAVP1(pk, s) 3. m' = RSAVP1(pk, s)
4. If m != m', raise "signing failure" and stop 4. If m != m', raise a "signing failure" error and stop
5. blind_sig = int_to_bytes(s, modulus_len) 5. blind_sig = int_to_bytes(s, modulus_len)
6. output blind_sig 6. output blind_sig
4.4. Finalize 4.4. Finalize
Finalize validates the server's response, unblinds the message to Finalize validates the server's response, unblinds the message to
produce a signature, verifies it for correctness, and outputs the produce a signature, verifies it for correctness, and outputs the
signature upon success. Note that this function will internally hash signature upon success. Note that this function will internally hash
the input message as is done in Blind. the input message as is done in Blind.
Finalize(pk, msg, blind_sig, inv) Finalize(pk, msg, blind_sig, inv)
Parameters: Parameters:
- modulus_len, the length in bytes of the RSA modulus n - modulus_len, the length in bytes of the RSA modulus n
- Hash, the hash function used to hash the message - Hash, the hash function used to hash the message
- MGF, the mask generation function - MGF, the mask generation function
- salt_len, the length in bytes of the salt (denoted sLen in RFC8017) - salt_len, the length in bytes of the salt (denoted sLen
in RFC 8017)
Inputs: Inputs:
- pk, server public key (n, e) - pk, server public key (n, e)
- msg, message to be signed, a byte string - msg, message to be signed, a byte string
- blind_sig, signed and blinded element, a byte string of - blind_sig, signed and blinded element, a byte string of
length modulus_len length modulus_len
- inv, inverse of the blind, an integer - inv, inverse of the blind, an integer
Outputs: Outputs:
- sig, a byte string of length modulus_len - sig, a byte string of length modulus_len
Errors: Errors:
- "invalid signature": Raised when the signature is invalid - "invalid signature": Raised when the signature is invalid
- "unexpected input size": Raised when a byte string input doesn't - "unexpected input size": Raised when a byte string input doesn't
have the expected length. have the expected length
Steps: Steps:
1. If len(blind_sig) != modulus_len, raise "unexpected input size" and stop 1. If len(blind_sig) != modulus_len, raise an "unexpected input size"
2. z = bytes_to_int(blind_sig) error and stop
3. s = (z * inv) mod n 2. z = bytes_to_int(blind_sig)
4. sig = int_to_bytes(s, modulus_len) 3. s = (z * inv) mod n
5. result = RSASSA-PSS-VERIFY(pk, msg, sig) with 4. sig = int_to_bytes(s, modulus_len)
Hash, MGF, and salt_len as defined in the parameters 5. result = RSASSA-PSS-VERIFY(pk, msg, sig) with
6. If result = "valid signature", output sig, else Hash, MGF, and salt_len as defined in the parameters
raise "invalid signature" and stop 6. If result = "valid signature", output sig, else
raise an "invalid signature" error and stop
4.5. Verification 4.5. Verification
As described in Section 4, the output of the protocol is the prepared As described in Section 4, the output of the protocol is the prepared
message input_msg and the signature sig. The message that message input_msg and the signature sig. The message that
applications consume is msg, from which input_msg is derived. applications consume is msg, from which input_msg is derived.
Clients verify the msg signature using the server's public key pk by Clients verify the msg signature using the server's public key pk by
invoking the RSASSA-PSS-VERIFY routine defined in Section 8.1.2 of invoking the RSASSA-PSS-VERIFY routine defined in Section 8.1.2 of
[RFC8017] with (n, e) as pk, M as input_msg, and S as sig. [RFC8017] with (n, e) as pk, M as input_msg, and S as sig.
Verification and the message that applications consume therefore Verification and the message that applications consume therefore
depends on which preparation function is used. In particular, if the depend on which preparation function is used. In particular, if the
PrepareIdentity function is used, then the application message is PrepareIdentity function is used, then the application message is
input_msg. In contrast, if the PrepareRandomize function is used, input_msg. In contrast, if the PrepareRandomize function is used,
then the application message is slice(input_msg, 32, len(input_msg)), then the application message is slice(input_msg, 32, len(input_msg)),
i.e., the prepared message with the random prefix removed. i.e., the prepared message with the message randomizer prefix
removed.
5. RSABSSA Variants 5. RSABSSA Variants
In this section we define different named variants of RSABSSA. Each In this section, we define different named variants of RSABSSA. Each
variant specifies RSASSA-PSS parameters as defined in Section 9.1.1 variant specifies EMSA-PSS options Hash, MGF, and sLen as defined in
of [RFC8017] and the type of message preparation function applied (as Section 9.1.1 of [RFC8017], as well as the type of message
described in Section 4.1). Each variant uses the MGF1 Mask preparation function applied (as described in Section 4.1). Each
Generation Function defined in Appendix B.2.1. of [RFC8017]. Future variant uses the mask generation function 1 (MGF1) defined in
specifications can introduce other variants as desired. The named Appendix B.2.1. of [RFC8017]. Future specifications can introduce
variants are as follows: other variants as desired. The named variants are as follows:
1. RSABSSA-SHA384-PSS-Randomized: This named variant uses SHA-384 as RSABSSA-SHA384-PSS-Randomized:
the hash function, MGF1 with SHA-384 as the PSS mask generation This named variant uses SHA-384 as the EMSA-PSS Hash option, MGF1
function, a 48-byte salt length, and uses the randomized with SHA-384 as the EMSA-PSS MGF option, and 48 as the EMSA-PSS
preparation function (PrepareRandomize). sLen option (48-byte salt length); it also uses the randomized
preparation function (PrepareRandomize).
2. RSABSSA-SHA384-PSSZERO-Randomized: This named variant uses RSABSSA-SHA384-PSSZERO-Randomized:
SHA-384 as the hash function, MGF1 with SHA-384 as the PSS mask This named variant uses SHA-384 as the EMSA-PSS Hash option, MGF1
generation function, an empty PSS salt, and uses the randomized with SHA-384 as the EMSA-PSS MGF option, and 0 as the EMSA-PSS
preparation function (PrepareRandomize). sLen option (0-byte salt length); it also uses the randomized
preparation function (PrepareRandomize).
3. RSABSSA-SHA384-PSS-Deterministic: This named variant uses SHA-384 RSABSSA-SHA384-PSS-Deterministic:
as the hash function, MGF1 with SHA-384 as the PSS mask This named variant uses SHA-384 as the EMSA-PSS Hash option, MGF1
generation function, 48-byte salt length, and uses the identity with SHA-384 as the EMSA-PSS MGF option, and 48 as the EMSA-PSS
preparation function (PrepareIdentity). sLen option (48-byte salt length); it also uses the identity
preparation function (PrepareIdentity).
4. RSABSSA-SHA384-PSSZERO-Deterministic: This named variant uses RSABSSA-SHA384-PSSZERO-Deterministic:
SHA-384 as the hash function, MGF1 with SHA-384 as the PSS mask This named variant uses SHA-384 as the EMSA-PSS Hash option, MGF1
generation function, an empty PSS salt, and uses the identity with SHA-384 as the EMSA-PSS MGF option, and 0 as the EMSA-PSS
preparation function (PrepareIdentity). This is the only variant sLen option (0-byte salt length); it also uses the identity
that produces deterministic signatures over the client's input preparation function (PrepareIdentity). This is the only variant
message msg. that produces deterministic signatures over the client's input
message msg.
The RECOMMENDED variants are RSABSSA-SHA384-PSS-Randomized or The RECOMMENDED variants are RSABSSA-SHA384-PSS-Randomized or
RSABSSA-SHA384-PSSZERO-Randomized. RSABSSA-SHA384-PSSZERO-Randomized.
Not all named variants can be used interchangeably. In particular, Not all named variants can be used interchangeably. In particular,
applications that provide high-entropy input messages can safely use applications that provide high-entropy input messages can safely use
named variants without randomized message preparation, as the named variants without randomized message preparation, as the
additional message randomization does not offer security advantages. additional message randomization does not offer security advantages.
See [Lys22] and Section 7.3 for more information. For all other See [Lys22] and Section 7.3 for more information. For all other
applications, the variants that use the randomized preparation applications, the variants that use the randomized preparation
skipping to change at page 11, line 14 skipping to change at line 483
PSSZERO-Deterministic SHOULD carefully analyze the security PSSZERO-Deterministic SHOULD carefully analyze the security
implications, taking into account the possibility of adversarially implications, taking into account the possibility of adversarially
generated signer keys as described in Section 7.3. When it is not generated signer keys as described in Section 7.3. When it is not
clear whether an application requires deterministic or randomized clear whether an application requires deterministic or randomized
signatures, applications SHOULD use one of the variants with signatures, applications SHOULD use one of the variants with
randomized message preparation. randomized message preparation.
6. Implementation and Usage Considerations 6. Implementation and Usage Considerations
This section documents considerations for interfaces to This section documents considerations for interfaces to
implementations of the protocol in this document. This includes implementations of the protocol defined in this document. This
error handling and API considerations. includes error handling and API considerations.
6.1. Errors 6.1. Errors
The high-level functions specified in Section 4 are all fallible. The high-level functions specified in Section 4 are all fallible.
The explicit errors generated throughout this specification, along The explicit errors generated throughout this specification, along
with the conditions that lead to each error, are listed in the with the conditions that lead to each error, are listed in the
definitions for Blind, BlindSign, and Finalize. These errors are definitions for Blind, BlindSign, and Finalize. These errors are
meant as a guide for implementors. They are not an exhaustive list meant as a guide for implementors. They are not an exhaustive list
of all the errors an implementation might emit. For example, of all the errors an implementation might emit. For example,
implementations might run out of memory. implementations might run out of memory.
Moreover, implementations can handle errors as needed or desired. Moreover, implementations can handle errors as needed or desired.
Where applicable, this document provides guidance for how to deal Where applicable, this document provides guidance for how to deal
with explicit errors that are generated in the protocol. For with explicit errors that are generated in the protocol. For
example, "blinding error" is generated in Blind when the client example, a "blinding error" error is generated in Blind when the
produces a prime factor of the server's public key. Section 4.2 client produces a prime factor of the server's public key.
indicates that implementations SHOULD retry the Blind function when Section 4.2 indicates that implementations SHOULD retry the Blind
this error occurs, but an implementation could also handle this function when this error occurs, but an implementation could also
exceptional event differently, e.g., by informing the server that the handle this exceptional event differently, e.g., by informing the
key has been factored. server that the key has been factored.
6.2. Signing Key Generation and Usage 6.2. Signing Key Generation and Usage
The RECOMMENDED method for generating the server signing key pair is The RECOMMENDED method for generating the server signing key pair is
as specified in FIPS 186-4 [DSS]. as specified in FIPS 186-5 [DSS].
A server signing key MUST NOT be reused for any other protocol beyond A server signing key MUST NOT be reused for any other protocol beyond
RSABSSA. Moreover, a server signing key MUST NOT be reused for RSABSSA. Moreover, a server signing key MUST NOT be reused for
different RSABSSA encoding options. That is, if a server supports different RSABSSA encoding options. That is, if a server supports
two different encoding options, then it MUST have a distinct key pair two different encoding options, then it MUST have a distinct key pair
for each option. for each option.
If the server public key is carried in an X.509 certificate, it MUST 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 use the id-RSASSA-PSS OID [RFC5756]. It MUST NOT use the
OID [RFC5280]. rsaEncryption OID [RFC5280].
7. Security Considerations 7. Security Considerations
Lysyanskaya proved one-more-forgery polynomial security of RSABSSA Lysyanskaya proved one-more-forgery polynomial security of RSABSSA
variants in the random oracle model under the one-more-RSA assumption variants in the random oracle model under the one-more-RSA
in [Lys22]. This means the adversary cannot output n+1 valid message assumption; see [Lys22]. This means the adversary cannot output n+1
and signature tuples, where all messages are distinct, after valid message and signature tuples, where all messages are distinct,
interacting with the server (signer) as a client only n times, for after interacting with the server (signer) as a client only n times,
some n which is polynomial in the protocol's security parameter. for some n that is polynomial in the protocol's security parameter.
Lysyanskaya also proved that the RSABSSA variants which use the Lysyanskaya also proved that the RSABSSA variants, which use the
PrepareRandomize function achieve blindness in [Lys22]. Blindness PrepareRandomize function, achieve blindness (see version B of the
means that the malicious signer learns nothing about the client input protocol and related proofs in [Lys22]). Blindness means that the
and output after the protocol execution. However, additional malicious signer learns nothing about the client input and output
assumptions on the message inputs are required for blindness to hold after the protocol execution. However, additional assumptions on the
for RSABSSA variants that use the PrepareIdentity function; see message inputs are required for blindness to hold for RSABSSA
Section 7.3 for more discussion on those results. variants that use the PrepareIdentity function; see Section 7.3 for
more discussion on those results.
7.1. Timing Side Channels and Fault Attacks 7.1. Timing Side Channels and Fault Attacks
BlindSign is functionally a remote procedure call for applying the BlindSign is functionally a remote procedure call for applying the
RSA private key operation. As such, side channel resistance is RSA private key operation. As such, side-channel resistance is
paramount to protect the private key from exposure paramount to protect the private key from exposure
[RemoteTimingAttacks]. Implementations SHOULD implement some form of [RemoteTimingAttacks]. Implementations SHOULD implement some form of
side channel attack mitigation, such as RSA blinding as described in side-channel attack mitigation, such as RSA blinding as described in
Section 10 of [TimingAttacks]. Failure to apply such mitigations can Section 10 of [TimingAttacks]. Failure to apply such mitigations can
lead to side channel attacks that leak the private signing key. lead to side-channel attacks that leak the private signing key.
Moreover, we assume that the server does not initiate the protocol Moreover, we assume that the server does not initiate the protocol
and therefore has no knowledge of when the Prepare and Blind and therefore has no knowledge of when the Prepare and Blind
operations take place. If this were not the case, additional side- operations take place. If this were not the case, additional side-
channel mitigations might be required to prevent timing side channels channel mitigations might be required to prevent timing side channels
through Prepare and Blind. through Prepare and Blind.
Beyond timing side channels, [FAULTS] describes the importance of Beyond timing side channels, [FAULTS] describes the importance of
implementation safeguards that protect against fault attacks that can implementation safeguards that protect against fault attacks that can
also leak the private signing key. These safeguards require that also leak the private signing key. These safeguards require that
implementations check that the result of the private key operation implementations check that the result of the private key operation
when signing is correct, i.e., given s = RSASP1(sk, m), verify that m when signing is correct, i.e., given s = RSASP1(sk, m), verify that m
= RSAVP1(pk, s), as is required by BlindSign. Applying this (or = RSAVP1(pk, s), as is required by BlindSign. Applying this (or an
equivalent) safeguard is necessary to mitigate fault attacks, even equivalent) safeguard is necessary to mitigate fault attacks, even
for implementations that are not based on the Chinese remainder for implementations that are not based on the Chinese remainder
theorem. theorem.
7.2. Message Robustness 7.2. Message Robustness
An essential property of blind signature protocols is that the signer An essential property of blind signature protocols is that the signer
learns nothing of the message being signed. In some circumstances, learns nothing of the message being signed. In some circumstances,
this may raise concerns of arbitrary signing oracles. Applications this may raise concerns regarding arbitrary signing oracles.
using blind signature protocols should take precautions to ensure Applications using blind signature protocols should take precautions
that such oracles do not cause cross-protocol attacks. Ensuring that to ensure that such oracles do not cause cross-protocol attacks.
the signing key used for RSABSSA is distinct from other protocols Ensuring that the signing key used for RSABSSA is distinct from other
prevents such cross-protocol attacks. protocols prevents such cross-protocol attacks.
An alternative solution to this problem of message blindness is to An alternative solution to this problem of message blindness is to
give signers proof that the message being signed is well-structured. give signers proof that the message being signed is well structured.
Depending on the application, zero knowledge proofs could be useful Depending on the application, zero-knowledge proofs could be useful
for this purpose. Defining such a proof is out of scope for this for this purpose. Defining such proofs is out of scope for this
document. document.
Verifiers should check that, in addition to signature validity, the Verifiers should check that, in addition to signature validity, the
signed message is well-structured for the relevant application. For signed message is well structured for the relevant application. For
example, if an application of this protocol requires messages to be example, if an application of this protocol requires messages to be
structures of a particular form, then verifiers should check that structures of a particular form, then verifiers should check that
messages adhere to this form. messages adhere to this form.
7.3. Message Entropy 7.3. Message Entropy
As discussed in [Lys22], a malicious signer can construct an invalid As discussed in [Lys22], a malicious signer can construct an invalid
public key and use it to learn information about low-entropy input public key and use it to learn information about low-entropy input
messages. Note that some invalid public keys may not yield valid messages. Note that some invalid public keys may not yield valid
signatures when run with the protocol, e.g., because the signature signatures when run with the protocol, e.g., because the signature
fails to verify. However, if an attacker can coerce the client to fails to verify. However, if an attacker can coerce the client to
use these invalid public keys with low-entropy inputs, they can learn use these invalid public keys with low-entropy inputs, they can learn
information about the client inputs before the protocol completes. information about the client inputs before the protocol completes.
A client that uses this protocol might be vulnerable to attack from a A client that uses this protocol might be vulnerable to attack from a
malicious signer unless it is able to ensure that either: malicious signer unless it is able to ensure that one of the
following conditions is satisfied:
1. The client has proof that the signer's public key is honestly (1) The client has proof that the signer's public key is honestly
generated. [GRSB19] presents some (non-interactive) honest- generated. [GRSB19] presents some (non-interactive) honest-
verifier zero-knowledge proofs of various statements about the verifier zero-knowledge proofs of various statements about the
public key. public key.
2. The input message has a value that the signer is unable to guess. (2) The input message has a value that the signer is unable to
That is, the client has added a high-entropy component that was guess. That is, the client has added a high-entropy component
not available to the signer prior to them choosing their signing that was not available to the signer prior to them choosing
key. their signing key.
The named variants that use the PrepareRandomize function -- RSABSSA- The named variants that use the PrepareRandomize function -- RSABSSA-
SHA384-PSS-Randomized and RSABSSA-SHA384-PSSZERO-Randomized -- SHA384-PSS-Randomized and RSABSSA-SHA384-PSSZERO-Randomized --
explicitly inject fresh entropy alongside each message to satisfy explicitly inject fresh entropy alongside each message to satisfy
condition (2). As such, these variants are safe for all application condition (2). As such, these variants are safe for all application
use cases. use cases. In contrast, the named variants that use the
PrepareIdentity function do not inject fresh entropy and therefore
could be a problem with low-entropy inputs.
Note that these variants effectively mean that the resulting Note that these variants effectively mean that the resulting
signature is always randomized. As such, this interface is not signature is always randomized. As such, this interface is not
suitable for applications that require deterministic signatures. suitable for applications that require deterministic signatures.
7.4. Randomness Generation 7.4. Randomness Generation
All random values in the protocol, including the salt, message All random values in the protocol, including the salt, message
randomizer prefix, and random blind value in Blind, MUST be generated randomizer prefix (msg_prefix; see Appendix A), and random blind
from a cryptographically secure random number generator [RFC4086]. value in Blind, MUST be generated from a cryptographically secure
If these values are not generated randomly, or are otherwise random number generator [RFC4086]. If these values are not generated
constructed maliciously, it might be possible for them to encode randomly or are otherwise constructed maliciously, it might be
information that is not present in the signed message. For example, possible for them to encode information that is not present in the
the PSS salt might be maliciously constructed to encode the local IP signed message. For example, the PSS salt might be maliciously
address of the client. As a result, implementations SHOULD NOT allow constructed to encode the local IP address of the client. As a
clients to provide these values directly. result, implementations SHOULD NOT allow clients to provide these
values directly.
Note that malicious implementations could also encode client Note that malicious implementations could also encode client
information in the message being signed, but since clients can verify information in the message being signed, but since clients can verify
the resulting message signature using the public key this can be the resulting message signature using the public key, this can be
detected. detected.
7.5. Key Substitution Attacks 7.5. Key Substitution Attacks
RSA is well known to permit key substitution attacks, wherein an RSA is well known for permitting key substitution attacks, wherein an
attacker generates a key pair (skA, pkA) that verifies some known attacker generates a key pair (skA, pkA) that verifies some known
(message, signature) pair produced under a different (sk, pk) key (message, signature) pair produced under a different (sk, pk) key
pair [WM99]. This means it may be possible for an attacker to use a pair [WM99]. This means it may be possible for an attacker to use a
(message, signature) pair from one context in another. Entities that (message, signature) pair from one context in another. Entities that
verify signatures must take care to ensure a (message, signature) verify signatures must take care to ensure that a (message,
pair verifies with a valid public key from the expected issuer. signature) pair verifies with a valid public key from the expected
issuer.
7.6. Alternative RSA Encoding Functions 7.6. Alternative RSA Encoding Functions
This document document uses PSS encoding as specified in [RFC8017] This document uses PSS encoding as specified in [RFC8017] for a
for a number of reasons. First, it is recommended in recent number of reasons. First, it is recommended in recent standards,
standards, including TLS 1.3 [RFC8446], X.509v3 [RFC4055], and even including TLS 1.3 [RFC8446], X.509 [RFC4055], and even PKCS #1
PKCS#1 itself. According to [RFC8017], "Although no attacks are itself. According to [RFC8017], "Although no attacks are known
known against RSASSA-PKCS#1 v1.5, in the interest of increased against RSASSA-PKCS1-v1_5, in the interest of increased robustness,
robustness, RSA-PSS [RFC8017] is recommended for eventual adoption in RSASSA-PSS is REQUIRED in new applications." While RSA-PSS is more
new applications." While RSA-PSS is more complex than RSASSA-PKCS#1 complex than RSASSA-PKCS1-v1_5 encoding, ubiquity of RSA-PSS support
v1.5 encoding, ubiquity of RSA-PSS support influenced the design influenced the design decision in this document, despite PKCS #1 v1.5
decision in this draft, despite PKCS#1 v1.5 having equivalent having equivalent security properties for digital signatures [JKM18].
security properties for digital signatures [JKM18].
Full Domain Hash (FDH) [RSA-FDH] encoding is also possible, and this Full Domain Hash (FDH) encoding [RSA-FDH] is also possible. This
variant has equivalent security to PSS [KK18]. However, FDH is less variant provides security equivalent to that of PSS [KK18]. However,
standard and not used widely in related technologies. Moreover, FDH FDH is less standard and is not used widely in related technologies.
is deterministic, whereas PSS supports deterministic and Moreover, FDH is deterministic, whereas PSS supports deterministic
probabilistic encodings. and probabilistic encodings.
7.7. Post-Quantum Readiness 7.7. Post-Quantum Readiness
The blind signature protocol specified in this document is not post- The blind signature protocol specified in this document is not post-
quantum ready since it is based on RSA. Shor's polynomial-time quantum ready, since it is based on RSA. Shor's polynomial-time
factorization algorithm readily applies. factorization algorithm readily applies.
8. IANA Considerations 8. IANA Considerations
This document makes no IANA requests. This document has no IANA actions.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5756] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, [RFC5756] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Updates for RSAES-OAEP and RSASSA-PSS Algorithm "Updates for RSAES-OAEP and RSASSA-PSS Algorithm
Parameters", RFC 5756, DOI 10.17487/RFC5756, January 2010, Parameters", RFC 5756, DOI 10.17487/RFC5756, January 2010,
<https://www.rfc-editor.org/rfc/rfc5756>. <https://www.rfc-editor.org/info/rfc5756>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2", "PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016, RFC 8017, DOI 10.17487/RFC8017, November 2016,
<https://www.rfc-editor.org/rfc/rfc8017>. <https://www.rfc-editor.org/info/rfc8017>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References 9.2. Informative References
[ApplePrivateRelay] [ApplePrivateRelay]
"iCloud Private Relay Overview", n.d., "iCloud Private Relay Overview", December 2021,
<https://www.apple.com/icloud/docs/ <https://www.apple.com/icloud/docs/
iCloud_Private_Relay_Overview_Dec2021.pdf>. iCloud_Private_Relay_Overview_Dec2021.pdf>.
[BLS-Proposal]
Ladd, W., "[Privacy-pass] External verifiability: a
concrete proposal", July 2020,
<https://mailarchive.ietf.org/arch/msg/privacy-pass/
BDOOhSLwB3uUJcfBiss6nUF5sUA/>.
[Chaum83] Chaum, D., "Blind Signatures for Untraceable Payments", [Chaum83] Chaum, D., "Blind Signatures for Untraceable Payments",
1983, <http://sceweb.sce.uhcl.edu/yang/teaching/ Springer-Verlag, 1998,
<https://sceweb.sce.uhcl.edu/yang/teaching/
csci5234WebSecurityFall2011/Chaum-blind-signatures.PDF>. csci5234WebSecurityFall2011/Chaum-blind-signatures.PDF>.
[DSS] "Digital Signature Standard (DSS)", National Institute of [DSS] "Digital Signature Standard (DSS)", National Institute of
Standards and Technology report, Standards and Technology report,
DOI 10.6028/nist.fips.186-4, July 2013, DOI 10.6028/nist.fips.186-5, February 2023,
<https://doi.org/10.6028/nist.fips.186-4>. <https://doi.org/10.6028/NIST.FIPS.186-5>.
[FAULTS] Boneh, D., DeMillo, R., and R. Lipton, "On the Importance [FAULTS] Boneh, D., DeMillo, R. A., and R. J. Lipton, "On the
of Checking Cryptographic Protocols for Faults", Advances Importance of Checking Cryptographic Protocols for
in Cryptology - EUROCRYPT '97 pp. 37-51, Faults", Advances in Cryptology - EUROCRYPT '97, pp.
DOI 10.1007/3-540-69053-0_4, 1997, 37-51, DOI 10.1007/3-540-69053-0_4, 1997,
<https://doi.org/10.1007/3-540-69053-0_4>. <https://doi.org/10.1007/3-540-69053-0_4>.
[GoogleVPN] [GoogleVPN]
"VPN by Google One White Paper", n.d., "VPN by Google One, explained",
<https://one.google.com/about/vpn/howitworks>. <https://one.google.com/about/vpn/howitworks>.
[GRSB19] Goldberg, S., Reyzin, L., Sagga, O., and F. Baldimtsi, [GRSB19] Goldberg, S., Reyzin, L., Sagga, O., and F. Baldimtsi,
"Efficient Noninteractive Certification of RSA Moduli and "Efficient Noninteractive Certification of RSA Moduli and
Beyond", October 2019, Beyond", October 2019,
<https://eprint.iacr.org/2018/057.pdf>. <https://eprint.iacr.org/2018/057.pdf>.
[JKK14] Jarecki, S., Kiayias, A., and H. Krawczyk, "Round-Optimal [JKK14] Jarecki, S., Kiayias, A., and H. Krawczyk, "Round-Optimal
Password-Protected Secret Sharing and T-PAKE in the Password-Protected Secret Sharing and T-PAKE in the
Password-Only model", August 2014, Password-Only Model", August 2014,
<https://eprint.iacr.org/2014/650>. <https://eprint.iacr.org/2014/650>.
[JKM18] Jager, T., Kakvi, S., and A. May, "On the Security of the [JKM18] Jager, T., Kakvi, S. A., and A. May, "On the Security of
PKCS#1 v1.5 Signature Scheme", Proceedings of the 2018 ACM the PKCS#1 v1.5 Signature Scheme", Proceedings of the 2018
SIGSAC Conference on Computer and Communications Security, ACM SIGSAC Conference on Computer and Communications
DOI 10.1145/3243734.3243798, October 2018, Security, pp. 1195-1208, DOI 10.1145/3243734.3243798,
<https://doi.org/10.1145/3243734.3243798>. September 2018, <https://eprint.iacr.org/2018/855>.
[KK18] Kakvi, S. and E. Kiltz, "Optimal Security Proofs for Full
Domain Hash, Revisited", Journal of Cryptology vol. 31,
no. 1, pp. 276-306, DOI 10.1007/s00145-017-9257-9, April
2017, <https://doi.org/10.1007/s00145-017-9257-9>.
[KLRX20] Kastner, J., Loss, J., Rosenberg, M., and J. Xu, "On
Pairing-Free Blind Signature Schemes in the Algebraic
Group Model", September 2020,
<https://eprint.iacr.org/2020/1071>.
[Lys22] Lysyanskaya, A., "Security Analysis of RSA-BSSA", n.d., [KK18] Kakvi, S. A. and E. Kiltz, "Optimal Security Proofs for
<https://eprint.iacr.org/2022/895>. Full Domain Hash, Revisited", Journal of Cryptology, vol.
31, no. 1, pp. 276-306, DOI 10.1007/s00145-017-9257-9,
April 2017, <https://doi.org/10.1007/s00145-017-9257-9>.
[PolytimeROS] [Lys22] Lysyanskaya, A., "Security Analysis of RSA-BSSA", March
Benhamouda, F., Lepoint, T., Loss, J., Orru, M., and M. 2023, <https://eprint.iacr.org/2022/895>.
Raykova, "On the (in)security of ROS", July 2020,
<https://eprint.iacr.org/2020/945>.
[PrettyGoodPhonePrivacy] [PrettyGoodPhonePrivacy]
Schmitt, P. and B. Raghavan, "Pretty Good Phone Privacy", Schmitt, P. and B. Raghavan, "Pretty Good Phone Privacy",
n.d., <https://www.usenix.org/conference/usenixsecurity21/ Proceedings of the 30th USENIX Security Symposium, August
2021, <https://www.usenix.org/conference/usenixsecurity21/
presentation/schmitt>. presentation/schmitt>.
[PRIVACY-PASS] [PRIVACY-PASS]
Celi, S., Davidson, A., Valdez, S., and C. A. Wood, Celi, S., Davidson, A., Valdez, S., and C. A. Wood,
"Privacy Pass Issuance Protocol", Work in Progress, "Privacy Pass Issuance Protocol", Work in Progress,
Internet-Draft, draft-ietf-privacypass-protocol-11, 26 Internet-Draft, draft-ietf-privacypass-protocol-16, 3
June 2023, <https://datatracker.ietf.org/doc/html/draft- October 2023, <https://datatracker.ietf.org/doc/html/
ietf-privacypass-protocol-11>. draft-ietf-privacypass-protocol-16>.
[RemoteTimingAttacks] [RemoteTimingAttacks]
Boneh, D. and D. Brumley, "Remote Timing Attacks are Brumley, D. and D. Boneh, "Remote Timing Attacks are
Practical", 12th Usenix Security Symposium, May 2003, Practical", Proceedings of the 12th USENIX Security
<https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf>. Symposium, August 2003,
<https://www.usenix.org/legacy/events/sec03/tech/brumley/
brumley.pdf>.
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
Algorithms and Identifiers for RSA Cryptography for use in Algorithms and Identifiers for RSA Cryptography for use in
the Internet X.509 Public Key Infrastructure Certificate the Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile", RFC 4055, and Certificate Revocation List (CRL) Profile", RFC 4055,
DOI 10.17487/RFC4055, June 2005, DOI 10.17487/RFC4055, June 2005,
<https://www.rfc-editor.org/rfc/rfc4055>. <https://www.rfc-editor.org/info/rfc4055>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/rfc/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RSA-FDH] Bellare, M. and P. Rogaway, "Random Oracles are Practical: [RSA-FDH] Bellare, M. and P. Rogaway, "Random oracles are practical:
A Paradigm for Designing Efficient Protocols", October a paradigm for designing efficient protocols", CCS '93:
1995, <https://cseweb.ucsd.edu/~mihir/papers/ro.pdf>. Proceedings of the 1st ACM conference on Computer and
communications security, pp. 62-73,
DOI 10.1145/168588.168596, December 1993,
<https://dl.acm.org/doi/abs/10.1145/168588.168596>.
[TimingAttacks] [TimingAttacks]
Kocher, P., "Timing Attacks on Implementations of Diffie- Kocher, P. C., "Timing Attacks on Implementations of
Hellman, RSA, DSS, and Other Systems", Advances in Diffie-Hellman, RSA, DSS, and Other Systems", Advances in
Cryptology - CRYPTO '96 pp. 104-113, Cryptology - CRYPTO '96, pp. 104-113,
DOI 10.1007/3-540-68697-5_9, 1996, DOI 10.1007/3-540-68697-5_9, 1996,
<https://doi.org/10.1007/3-540-68697-5_9>. <https://doi.org/10.1007/3-540-68697-5_9>.
[TZ22] Tessaro, S. and C. Zhu, "Short Pairing-Free Blind
Signatures with Exponential Security", January 2022,
<https://eprint.iacr.org/2022/047>.
[UProve] Microsoft, "U-Prove", February 2012,
<https://www.microsoft.com/en-us/research/project/
u-prove/>.
[VOPRF] Davidson, A., Faz-Hernandez, A., Sullivan, N., and C. A. [VOPRF] Davidson, A., Faz-Hernandez, A., Sullivan, N., and C. A.
Wood, "Oblivious Pseudorandom Functions (OPRFs) using Wood, "Oblivious Pseudorandom Functions (OPRFs) using
Prime-Order Groups", Work in Progress, Internet-Draft, Prime-Order Groups", Work in Progress, Internet-Draft,
draft-irtf-cfrg-voprf-21, 21 February 2023, draft-irtf-cfrg-voprf-21, 21 February 2023,
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg- <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
voprf-21>. voprf-21>.
[WM99] Blake-Wilson, S. and A. Menezes, "Unknown key-share [WM99] Blake-Wilson, S. and A. Menezes, "Unknown Key-Share
attacks on the station-to-station (STS) protocol", Attacks on the Station-to-Station (STS) Protocol",
International Workshop on Public Key Cryptography, October International Workshop on Public Key Cryptography, PKC
1999. 1999, pp. 154-170, DOI 10.1007/3-540-49162-7_12, October
1999, <https://link.springer.com/
chapter/10.1007/3-540-49162-7_12>.
Appendix A. Test Vectors Appendix A. Test Vectors
This section includes test vectors for the blind signature protocol This section includes test vectors for the blind signature protocol
defined in Section 4. The following parameters are specified for defined in Section 4. The following parameters are specified for
each test vector: each test vector:
* p, q, n, e, d: RSA private and public key (sk and pk) parameters, p, q, n, e, d:
each encoded as a hexadecimal string. RSA private and public key (sk and pk) parameters, each encoded as
a hexadecimal string.
* msg: Input messsage being signed, encoded as a hexadecimal string. msg:
The hash is computed using SHA-384. Input message being signed, encoded as a hexadecimal string. The
hash is computed using SHA-384.
* msg_prefix: Message randomizer prefix, encoded as a hexadecimal msg_prefix:
string. This is only present for variants that use the Message randomizer prefix, encoded as a hexadecimal string. This
randomization preparation function. is only present for variants that use the randomization
preparation function.
* prepared_msg: The message actually signed. If the variant does prepared_msg:
not use the randomization preparation function, this is equal to The message actually signed. If the variant does not use the
msg. randomization preparation function, this is equal to msg.
* salt: Randomly-generated salt used when computing the signature. salt:
The length is either 48 or 0 bytes. Randomly generated salt used when computing the signature. The
length is either 48 or 0 bytes.
* encoded_msg: EMSA-PSS encoded message. The mask generation encoded_msg:
function is MGF1 with SHA-384. EMSA-PSS encoded message. The mask generation function is MGF1
with SHA-384.
* inv: The message blinding inverse, encoded as a hexadecimal inv: The message blinding inverse, encoded as a hexadecimal string.
string.
* blinded_msg, blind_sig: The protocol values exchanged during the blinded_msg, blind_sig:
computation, encoded as hexadecimal strings. The protocol values exchanged during the computation, encoded as
hexadecimal strings.
* sig: The output message signature. sig: The output message signature.
A.1. RSABSSA-SHA384-PSS-Randomized Test Vector A.1. RSABSSA-SHA384-PSS-Randomized Test Vector
p = e1f4d7a34802e27c7392a3cea32a262a34dc3691bd87f3f310dc756734889305 p = e1f4d7a34802e27c7392a3cea32a262a34dc3691bd87f3f310dc756734889305
59c120fd0410194fb8a0da55bd0b81227e843fdca6692ae80e5a5d414116d4803fca 59c120fd0410194fb8a0da55bd0b81227e843fdca6692ae80e5a5d414116d4803fca
7d8c30eaaae57e44a1816ebb5c5b0606c536246c7f11985d731684150b63c9a3ad9e 7d8c30eaaae57e44a1816ebb5c5b0606c536246c7f11985d731684150b63c9a3ad9e
41b04c0b5b27cb188a692c84696b742a80d3cd00ab891f2457443dadfeba6d6daf10 41b04c0b5b27cb188a692c84696b742a80d3cd00ab891f2457443dadfeba6d6daf10
8602be26d7071803c67105a5426838e6889d77e8474b29244cefaf418e381b312048 8602be26d7071803c67105a5426838e6889d77e8474b29244cefaf418e381b312048
b457d73419213063c60ee7b0d81820165864fef93523c9635c22210956e53a8d9632 b457d73419213063c60ee7b0d81820165864fef93523c9635c22210956e53a8d9632
2493ffc58d845368e2416e078e5bcb5d2fd68ae6acfa54f9627c42e84a9d3f277401 2493ffc58d845368e2416e078e5bcb5d2fd68ae6acfa54f9627c42e84a9d3f277401
skipping to change at page 31, line 10 skipping to change at line 1422
1126e93686635d4766aedf5103cf7978f3856ccac9e28d21a850dbb03c811128616d 1126e93686635d4766aedf5103cf7978f3856ccac9e28d21a850dbb03c811128616d
315d717be1c2b6254f8509acae862042c034530329ce15ca2e2f6b1f5fd59272746e 315d717be1c2b6254f8509acae862042c034530329ce15ca2e2f6b1f5fd59272746e
3918c748c0eb810bf76884fa10fcf749326bbfaa5ba285a0186a22e4f628dbf178d3 3918c748c0eb810bf76884fa10fcf749326bbfaa5ba285a0186a22e4f628dbf178d3
bb5dc7e165ca73f6a55ecc14c4f5a26c4693ce5da032264cbec319b12ddb9787d0ef bb5dc7e165ca73f6a55ecc14c4f5a26c4693ce5da032264cbec319b12ddb9787d0ef
a4fcf1e5ccee35ad85ecd453182df9ed735893f830b570faae8be0f6fe2e571a4e0d a4fcf1e5ccee35ad85ecd453182df9ed735893f830b570faae8be0f6fe2e571a4e0d
927cba4debd368d3b4fca33ec6251897a137cf75474a32ac8256df5e5ffa518b88b4 927cba4debd368d3b4fca33ec6251897a137cf75474a32ac8256df5e5ffa518b88b4
3fb6f63a24 3fb6f63a24
Acknowledgments Acknowledgments
We would like to thank Bjoern Tackmann who provided an editorial and We would like to thank Bjoern Tackmann, who provided an editorial and
security review of this document. security review of this document.
Authors' Addresses Authors' Addresses
Frank Denis Frank Denis
Fastly Inc. Fastly Inc.
Email: fd@00f.net Email: fd@00f.net
Frederic Jacobs Frederic Jacobs
Apple Inc. Apple Inc.
 End of changes. 110 change blocks. 
378 lines changed or deleted 376 lines changed or added

This html diff was produced by rfcdiff 1.48.