diff options
Diffstat (limited to 'doc/rfc/rfc9474.txt')
| -rw-r--r-- | doc/rfc/rfc9474.txt | 1447 |
1 files changed, 1447 insertions, 0 deletions
diff --git a/doc/rfc/rfc9474.txt b/doc/rfc/rfc9474.txt new file mode 100644 index 0000000..03b62f3 --- /dev/null +++ b/doc/rfc/rfc9474.txt @@ -0,0 +1,1447 @@ + + + + +Internet Research Task Force (IRTF) F. Denis +Request for Comments: 9474 Fastly Inc. +Category: Informational F. Jacobs +ISSN: 2070-1721 Apple Inc. + C. A. Wood + Cloudflare + October 2023 + + + RSA Blind Signatures + +Abstract + + This document specifies an RSA-based blind signature protocol. RSA + blind signatures were first introduced by Chaum for untraceable + payments. A signature that is output from this protocol can be + verified as an RSA-PSS signature. + + This document is a product of the Crypto Forum Research Group (CFRG) + in the IRTF. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Research Task Force + (IRTF). The IRTF publishes the results of Internet-related research + and development activities. These results might not be suitable for + 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. + + 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 (c) 2023 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + +Table of Contents + + 1. Introduction + 2. Requirements Notation + 3. Notation + 4. Blind Signature Protocol + 4.1. Prepare + 4.2. Blind + 4.3. BlindSign + 4.4. Finalize + 4.5. Verification + 5. RSABSSA Variants + 6. Implementation and Usage Considerations + 6.1. Errors + 6.2. Signing Key Generation and Usage + 7. Security Considerations + 7.1. Timing Side Channels and Fault Attacks + 7.2. Message Robustness + 7.3. Message Entropy + 7.4. Randomness Generation + 7.5. Key Substitution Attacks + 7.6. Alternative RSA Encoding Functions + 7.7. Post-Quantum Readiness + 8. IANA Considerations + 9. References + 9.1. Normative References + 9.2. Informative References + Appendix A. Test Vectors + A.1. RSABSSA-SHA384-PSS-Randomized Test Vector + A.2. RSABSSA-SHA384-PSSZERO-Randomized Test Vector + A.3. RSABSSA-SHA384-PSS-Deterministic Test Vector + A.4. RSABSSA-SHA384-PSSZERO-Deterministic Test Vector + Acknowledgments + Authors' Addresses + +1. Introduction + + Originally introduced in the context of digital cash systems by Chaum + for untraceable payments [Chaum83], RSA blind signatures turned out + to have a wide range of applications ranging from privacy-preserving + digital payments to authentication mechanisms [GoogleVPN] + [ApplePrivateRelay] [PrettyGoodPhonePrivacy]. + + Recently, interest in blind signatures has grown to address + operational shortcomings from applications that use Verifiable + Oblivious Pseudorandom Functions (VOPRFs) [VOPRF], such as Privacy + Pass [PRIVACY-PASS]. Specifically, VOPRFs are not necessarily + publicly verifiable, meaning that a verifier needs access to the + VOPRF private key to verify that the output of a VOPRF protocol is + valid for a given input. This limitation complicates deployments + where it is not desirable to distribute private keys to entities + performing verification. Additionally, if the private key is kept in + a Hardware Security Module, the number of operations on the key is + doubled compared to a scheme where only the public key is required + for verification. + + In contrast, digital signatures provide a primitive that is publicly + verifiable and does not require access to the private key for + verification. Moreover, [JKK14] shows that one can realize a VOPRF + in the random oracle model by hashing a (message, signature) pair, + where the signature is computed using a deterministic blind signature + protocol. + + This document specifies (1) a protocol for computing RSA blind + signatures using RSA-PSS encoding and (2) a family of variants + (Section 5) for this protocol, denoted RSABSSA (RSA Blind Signature + with Appendix). In order to facilitate deployment, it is defined in + such a way that the resulting (unblinded) signature can be verified + with a standard RSA-PSS library. + + This document represents the consensus of the Crypto Forum Research + Group (CFRG). It is not an IETF product and is not a standard. + +2. Requirements Notation + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +3. Notation + + The following terms, which describe different protocol operations, + are used throughout this document: + + bytes_to_int and int_to_bytes: + Convert a byte string to and from a non-negative + integer. bytes_to_int and int_to_bytes are implemented as OS2IP + and I2OSP -- as described in [RFC8017] -- respectively. Note that + these functions operate on byte strings in big-endian byte order. + + 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. + +4. Blind Signature Protocol + + The RSA Blind Signature Protocol is a two-party protocol between a + client and server 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 private + 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 + 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. + + The protocol consists of four 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, and let + (sk, pk) be the server's private and public key pair. + + 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: + + blinded_msg, inv = Blind(pk, input_msg) + + The client then sends blinded_msg to the server, which then processes + the message by computing: + + blind_sig = BlindSign(sk, blinded_msg) + + The server then sends blind_sig to the client, which then finalizes + the protocol by computing: + + sig = Finalize(pk, input_msg, 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 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. + + Shown graphically, the protocol runs as follows: + + Client(pk, msg) Server(sk, pk) + ----------------------------------------------------- + input_msg = Prepare(msg) + blinded_msg, inv = Blind(pk, input_msg) + + blinded_msg + ----------> + + blind_sig = BlindSign(sk, blinded_msg) + + blind_sig + <---------- + + sig = Finalize(pk, input_msg, blind_sig, inv) + + In the remainder of this section, we specify the Prepare, Blind, + BlindSign, and Finalize functions that are used in this protocol. + +4.1. Prepare + + Message preparation, denoted by the Prepare function, is the process + by which the message to be signed and verified is prepared for input + to the blind signing protocol. There are two types of preparation + functions: an identity preparation function and a randomized + preparation function. The identity preparation function returns the + input message without transformation, i.e., msg = + PrepareIdentity(msg). + + The randomized preparation function augments the input message with + fresh randomness. We denote this process by the function + PrepareRandomize(msg), which takes as input a message msg and + produces a randomized message input_msg. Its implementation is shown + below. + + PrepareRandomize(msg) + + Inputs: + - msg, message to be signed, a byte string + + Outputs: + - input_msg, a byte string that is 32 bytes longer than msg + + Steps: + 1. msg_prefix = random(32) + 2. input_msg = concat(msg_prefix, msg) + 3. output input_msg + +4.2. Blind + + 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 + 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 try 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 6.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. + + Blind(pk, msg) + + 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 (denoted sLen + in RFC 8017) + + Inputs: + - pk, server public key (n, e) + - msg, message to be signed, a byte string + + Outputs: + - blinded_msg, a byte string of length modulus_len + - inv, an integer used to unblind the signature in Finalize + + 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. encoded_msg = EMSA-PSS-ENCODE(msg, bit_len(n)) + with Hash, MGF, and salt_len as defined in the parameters + 2. If EMSA-PSS-ENCODE raises an error, re-raise the error and stop + 3. m = bytes_to_int(encoded_msg) + 4. c = is_coprime(m, n) + 5. If c is false, raise an "invalid input" error and stop + 6. r = random_integer_uniform(1, n) + 7. inv = inverse_mod(r, n) + 8. If inverse_mod fails, raise a "blinding error" error and stop + 9. x = RSAVP1(pk, r) + 10. z = (m * x) mod n + 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 + distribution. This is typically done via rejection sampling. + +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, blinded_msg) + + Parameters: + - modulus_len, the length in bytes of the RSA modulus n + + Inputs: + - sk, server private key + - blinded_msg, encoded and blinded message to be signed, 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(blinded_msg) + 2. s = RSASP1(sk, m) + 3. m' = RSAVP1(pk, s) + 4. If m != m', raise a "signing failure" error and stop + 5. blind_sig = int_to_bytes(s, modulus_len) + 6. 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. + + Finalize(pk, msg, 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 (denoted sLen + in RFC 8017) + + Inputs: + - pk, server public key (n, e) + - msg, message to be signed, 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 an "unexpected input size" + error and stop + 2. z = bytes_to_int(blind_sig) + 3. s = (z * inv) mod n + 4. sig = int_to_bytes(s, modulus_len) + 5. result = RSASSA-PSS-VERIFY(pk, msg, sig) with + Hash, MGF, and salt_len as defined in the parameters + 6. If result = "valid signature", output sig, else + raise an "invalid signature" error and stop + +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. + 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 + [RFC8017] with (n, e) as pk, M as input_msg, and S as sig. + + Verification and the message that applications consume therefore + depend 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 message randomizer prefix + removed. + +5. RSABSSA Variants + + In this section, we define different named variants of RSABSSA. Each + variant specifies EMSA-PSS options Hash, MGF, and sLen as defined in + Section 9.1.1 of [RFC8017], as well as the type of message + preparation function applied (as described in Section 4.1). Each + variant uses the mask generation function 1 (MGF1) defined in + Appendix B.2.1. of [RFC8017]. Future specifications can introduce + other variants as desired. The named variants are as follows: + + RSABSSA-SHA384-PSS-Randomized: + This named variant uses SHA-384 as the EMSA-PSS Hash option, MGF1 + with SHA-384 as the EMSA-PSS MGF option, and 48 as the EMSA-PSS + sLen option (48-byte salt length); it also uses the randomized + preparation function (PrepareRandomize). + + RSABSSA-SHA384-PSSZERO-Randomized: + This named variant uses SHA-384 as the EMSA-PSS Hash option, MGF1 + with SHA-384 as the EMSA-PSS MGF option, and 0 as the EMSA-PSS + sLen option (0-byte salt length); it also uses the randomized + preparation function (PrepareRandomize). + + RSABSSA-SHA384-PSS-Deterministic: + This named variant uses SHA-384 as the EMSA-PSS Hash option, MGF1 + with SHA-384 as the EMSA-PSS MGF option, and 48 as the EMSA-PSS + sLen option (48-byte salt length); it also uses the identity + preparation function (PrepareIdentity). + + RSABSSA-SHA384-PSSZERO-Deterministic: + This named variant uses SHA-384 as the EMSA-PSS Hash option, MGF1 + with SHA-384 as the EMSA-PSS MGF option, and 0 as the EMSA-PSS + sLen option (0-byte salt length); it also 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 RSABSSA-SHA384-PSS-Randomized or + RSABSSA-SHA384-PSSZERO-Randomized. + + Not all named variants can be used interchangeably. In particular, + applications that provide high-entropy input messages can safely use + named variants without randomized message preparation, as the + additional message randomization does not offer security advantages. + See [Lys22] and Section 7.3 for more information. For all other + applications, the variants that use the randomized preparation + function protect clients from malicious signers. A verifier that + accepts randomized messages needs to remove the random component from + the signed part of messages before processing. + + Applications that require deterministic signatures can use the + RSABSSA-SHA384-PSSZERO-Deterministic variant, but only if their input + messages have high entropy. Applications that use RSABSSA-SHA384- + PSSZERO-Deterministic SHOULD carefully analyze the security + implications, taking into account the possibility of adversarially + generated signer keys as described in Section 7.3. When it is not + clear whether an application requires deterministic or randomized + signatures, applications SHOULD use one of the variants with + randomized message preparation. + +6. Implementation and Usage Considerations + + This section documents considerations for interfaces to + implementations of the protocol defined in this document. This + includes error handling and API considerations. + +6.1. Errors + + The high-level functions specified in Section 4 are all fallible. + The explicit errors generated throughout this specification, along + with the conditions that lead to each error, are listed in the + definitions for Blind, BlindSign, and Finalize. These errors are + meant as a guide for implementors. They are not an exhaustive list + of all the errors an implementation might emit. For example, + implementations might run out of memory. + + 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, a "blinding error" error is generated in Blind when the + client produces a prime factor of the server's public key. + Section 4.2 indicates that implementations SHOULD retry the Blind + function when this error occurs, but an implementation could also + handle this exceptional event differently, e.g., by informing the + server that the key has been factored. + +6.2. Signing Key Generation and Usage + + The RECOMMENDED method for generating the server signing key pair is + as specified in FIPS 186-5 [DSS]. + + A server signing key MUST NOT be reused for any other protocol beyond + RSABSSA. Moreover, a server signing key MUST NOT be reused for + different RSABSSA 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 id-RSASSA-PSS OID [RFC5756]. It MUST NOT use the + rsaEncryption OID [RFC5280]. + +7. Security Considerations + + Lysyanskaya proved one-more-forgery polynomial security of RSABSSA + variants in the random oracle model under the one-more-RSA + assumption; see [Lys22]. This means the adversary cannot output n+1 + valid message and signature tuples, where all messages are distinct, + after interacting with the server (signer) as a client only n times, + for some n that is polynomial in the protocol's security parameter. + Lysyanskaya also proved that the RSABSSA variants, which use the + PrepareRandomize function, achieve blindness (see version B of the + protocol and related proofs in [Lys22]). Blindness means that the + malicious signer learns nothing about the client input and output + after the protocol execution. However, additional assumptions on the + message inputs are required for blindness to hold for RSABSSA + variants that use the PrepareIdentity function; see Section 7.3 for + more discussion on those results. + +7.1. Timing Side Channels and Fault Attacks + + BlindSign is functionally a remote procedure call for applying the + RSA private key operation. As such, side-channel resistance is + paramount to protect the private key from exposure + [RemoteTimingAttacks]. Implementations SHOULD implement some form of + side-channel attack mitigation, such as RSA blinding as described in + Section 10 of [TimingAttacks]. Failure to apply such mitigations can + lead to side-channel attacks that leak the private signing key. + + Moreover, we assume that the server does not initiate the protocol + and therefore has no knowledge of when the Prepare and Blind + operations take place. If this were not the case, additional side- + channel mitigations might be required to prevent timing side channels + through Prepare and Blind. + + Beyond timing side channels, [FAULTS] describes the importance of + implementation safeguards that protect against fault attacks that can + also leak the private signing key. These safeguards require that + implementations check that the result of the private key operation + 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 an + equivalent) safeguard is necessary to mitigate fault attacks, even + for implementations that are not based on the Chinese remainder + theorem. + +7.2. Message Robustness + + An essential property of blind signature protocols is that the signer + learns nothing of the message being signed. In some circumstances, + this may raise concerns regarding arbitrary signing oracles. + Applications using blind signature protocols should take precautions + to ensure that such oracles do not cause cross-protocol attacks. + Ensuring that the signing key used for RSABSSA is distinct from other + protocols prevents such cross-protocol attacks. + + An alternative solution to this problem of message blindness is to + give signers proof that the message being signed is well structured. + Depending on the application, zero-knowledge proofs could be useful + for this purpose. Defining such proofs is out of scope for this + document. + + Verifiers should check that, in addition to signature validity, the + signed message is well structured for the relevant application. For + example, if an application of this protocol requires messages to be + structures of a particular form, then verifiers should check that + messages adhere to this form. + +7.3. Message Entropy + + As discussed in [Lys22], a malicious signer can construct an invalid + public key and use it to learn information about low-entropy input + messages. Note that some invalid public keys may not yield valid + signatures when run with the protocol, e.g., because the signature + fails to verify. However, if an attacker can coerce the client to + use these invalid public keys with low-entropy inputs, they can learn + information about the client inputs before the protocol completes. + + A client that uses this protocol might be vulnerable to attack from a + 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 + generated. [GRSB19] presents some (non-interactive) honest- + verifier zero-knowledge proofs of various statements about the + public key. + + (2) The input message has a value that the signer is unable to + guess. That is, the client has added a high-entropy component + that was not available to the signer prior to them choosing + their signing key. + + The named variants that use the PrepareRandomize function -- RSABSSA- + SHA384-PSS-Randomized and RSABSSA-SHA384-PSSZERO-Randomized -- + explicitly inject fresh entropy alongside each message to satisfy + condition (2). As such, these variants are safe for all application + 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 + signature is always randomized. As such, this interface is not + suitable for applications that require deterministic signatures. + +7.4. Randomness Generation + + All random values in the protocol, including the salt, message + randomizer prefix (msg_prefix; see Appendix A), and random blind + value in Blind, MUST be generated from a cryptographically secure + random number generator [RFC4086]. If these values are not generated + randomly or are otherwise constructed maliciously, it might be + possible for them to encode information that is not present in the + signed message. For example, the PSS salt might be maliciously + constructed to encode the local IP address of the client. As a + result, implementations SHOULD NOT allow clients to provide these + values directly. + + Note that malicious implementations could also encode client + information in the message being signed, but since clients can verify + the resulting message signature using the public key, this can be + detected. + +7.5. Key Substitution Attacks + + RSA is well known for permitting key substitution attacks, wherein an + attacker generates a key pair (skA, pkA) that verifies some known + (message, signature) pair produced under a different (sk, pk) key + pair [WM99]. This means it may be possible for an attacker to use a + (message, signature) pair from one context in another. Entities that + verify signatures must take care to ensure that a (message, + signature) pair verifies with a valid public key from the expected + issuer. + +7.6. Alternative RSA Encoding Functions + + This document uses PSS encoding as specified in [RFC8017] for a + number of reasons. First, it is recommended in recent standards, + including TLS 1.3 [RFC8446], X.509 [RFC4055], and even PKCS #1 + itself. According to [RFC8017], "Although no attacks are known + against RSASSA-PKCS1-v1_5, in the interest of increased robustness, + RSASSA-PSS is REQUIRED in new applications." While RSA-PSS is more + complex than RSASSA-PKCS1-v1_5 encoding, ubiquity of RSA-PSS support + influenced the design decision in this document, despite PKCS #1 v1.5 + having equivalent security properties for digital signatures [JKM18]. + + Full Domain Hash (FDH) encoding [RSA-FDH] is also possible. This + variant provides security equivalent to that of PSS [KK18]. However, + FDH is less standard and is not used widely in related technologies. + Moreover, FDH is deterministic, whereas PSS supports deterministic + and probabilistic encodings. + +7.7. Post-Quantum Readiness + + The blind signature protocol specified in this document is not post- + quantum ready, since it is based on RSA. Shor's polynomial-time + factorization algorithm readily applies. + +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/info/rfc2119>. + + [RFC5756] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, + "Updates for RSAES-OAEP and RSASSA-PSS Algorithm + Parameters", RFC 5756, DOI 10.17487/RFC5756, January 2010, + <https://www.rfc-editor.org/info/rfc5756>. + + [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, + "PKCS #1: RSA Cryptography Specifications Version 2.2", + RFC 8017, DOI 10.17487/RFC8017, November 2016, + <https://www.rfc-editor.org/info/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/info/rfc8174>. + +9.2. Informative References + + [ApplePrivateRelay] + "iCloud Private Relay Overview", December 2021, + <https://www.apple.com/icloud/docs/ + iCloud_Private_Relay_Overview_Dec2021.pdf>. + + [Chaum83] Chaum, D., "Blind Signatures for Untraceable Payments", + Springer-Verlag, 1998, + <https://sceweb.sce.uhcl.edu/yang/teaching/ + csci5234WebSecurityFall2011/Chaum-blind-signatures.PDF>. + + [DSS] "Digital Signature Standard (DSS)", National Institute of + Standards and Technology report, + DOI 10.6028/nist.fips.186-5, February 2023, + <https://doi.org/10.6028/NIST.FIPS.186-5>. + + [FAULTS] Boneh, D., DeMillo, R. A., and R. J. Lipton, "On the + Importance of Checking Cryptographic Protocols for + Faults", Advances in Cryptology - EUROCRYPT '97, pp. + 37-51, DOI 10.1007/3-540-69053-0_4, 1997, + <https://doi.org/10.1007/3-540-69053-0_4>. + + [GoogleVPN] + "VPN by Google One, explained", + <https://one.google.com/about/vpn/howitworks>. + + [GRSB19] Goldberg, S., Reyzin, L., Sagga, O., and F. Baldimtsi, + "Efficient Noninteractive Certification of RSA Moduli and + Beyond", October 2019, + <https://eprint.iacr.org/2018/057.pdf>. + + [JKK14] Jarecki, S., Kiayias, A., and H. Krawczyk, "Round-Optimal + Password-Protected Secret Sharing and T-PAKE in the + Password-Only Model", August 2014, + <https://eprint.iacr.org/2014/650>. + + [JKM18] Jager, T., Kakvi, S. A., and A. May, "On the Security of + the PKCS#1 v1.5 Signature Scheme", Proceedings of the 2018 + ACM SIGSAC Conference on Computer and Communications + Security, pp. 1195-1208, DOI 10.1145/3243734.3243798, + September 2018, <https://eprint.iacr.org/2018/855>. + + [KK18] Kakvi, S. A. 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>. + + [Lys22] Lysyanskaya, A., "Security Analysis of RSA-BSSA", March + 2023, <https://eprint.iacr.org/2022/895>. + + [PrettyGoodPhonePrivacy] + Schmitt, P. and B. Raghavan, "Pretty Good Phone Privacy", + Proceedings of the 30th USENIX Security Symposium, August + 2021, <https://www.usenix.org/conference/usenixsecurity21/ + presentation/schmitt>. + + [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>. + + [RemoteTimingAttacks] + Brumley, D. and D. Boneh, "Remote Timing Attacks are + Practical", Proceedings of the 12th USENIX Security + Symposium, August 2003, + <https://www.usenix.org/legacy/events/sec03/tech/brumley/ + brumley.pdf>. + + [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional + Algorithms and Identifiers for RSA Cryptography for use in + the Internet X.509 Public Key Infrastructure Certificate + and Certificate Revocation List (CRL) Profile", RFC 4055, + DOI 10.17487/RFC4055, June 2005, + <https://www.rfc-editor.org/info/rfc4055>. + + [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, RFC 4086, + DOI 10.17487/RFC4086, June 2005, + <https://www.rfc-editor.org/info/rfc4086>. + + [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/info/rfc5280>. + + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + <https://www.rfc-editor.org/info/rfc8446>. + + [RSA-FDH] Bellare, M. and P. Rogaway, "Random oracles are practical: + a paradigm for designing efficient protocols", CCS '93: + 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] + Kocher, P. C., "Timing Attacks on Implementations of + Diffie-Hellman, RSA, DSS, and Other Systems", Advances in + Cryptology - CRYPTO '96, pp. 104-113, + DOI 10.1007/3-540-68697-5_9, 1996, + <https://doi.org/10.1007/3-540-68697-5_9>. + + [VOPRF] Davidson, A., Faz-Hernandez, A., Sullivan, N., and C. A. + Wood, "Oblivious Pseudorandom Functions (OPRFs) using + Prime-Order Groups", Work in Progress, Internet-Draft, + draft-irtf-cfrg-voprf-21, 21 February 2023, + <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg- + voprf-21>. + + [WM99] Blake-Wilson, S. and A. Menezes, "Unknown Key-Share + Attacks on the Station-to-Station (STS) Protocol", + International Workshop on Public Key Cryptography, PKC + 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 + + This section includes test vectors for the blind signature protocol + defined in Section 4. The following parameters are specified for + each test vector: + + p, q, n, e, d: + RSA private and public key (sk and pk) parameters, each encoded as + a hexadecimal string. + + msg: + 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 string. This + is only present for variants that use the randomization + preparation function. + + prepared_msg: + The message actually signed. If the variant does not use the + randomization preparation function, this is equal to msg. + + salt: + 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 function is MGF1 + with SHA-384. + + inv: + The message blinding inverse, encoded as a hexadecimal string. + + blinded_msg, blind_sig: + The protocol values exchanged during the computation, encoded as + hexadecimal strings. + + sig: + The output message signature. + +A.1. RSABSSA-SHA384-PSS-Randomized Test Vector + + p = e1f4d7a34802e27c7392a3cea32a262a34dc3691bd87f3f310dc756734889305 + 59c120fd0410194fb8a0da55bd0b81227e843fdca6692ae80e5a5d414116d4803fca + 7d8c30eaaae57e44a1816ebb5c5b0606c536246c7f11985d731684150b63c9a3ad9e + 41b04c0b5b27cb188a692c84696b742a80d3cd00ab891f2457443dadfeba6d6daf10 + 8602be26d7071803c67105a5426838e6889d77e8474b29244cefaf418e381b312048 + b457d73419213063c60ee7b0d81820165864fef93523c9635c22210956e53a8d9632 + 2493ffc58d845368e2416e078e5bcb5d2fd68ae6acfa54f9627c42e84a9d3f277401 + 7e32ebca06308a12ecc290c7cd1156dcccfb2311 + q = c601a9caea66dc3835827b539db9df6f6f5ae77244692780cd334a006ab353c8 + 06426b60718c05245650821d39445d3ab591ed10a7339f15d83fe13f6a3dfb20b945 + 2c6a9b42eaa62a68c970df3cadb2139f804ad8223d56108dfde30ba7d367e9b0a7a8 + 0c4fdba2fd9dde6661fc73fc2947569d2029f2870fc02d8325acf28c9afa19ecf962 + daa7916e21afad09eb62fe9f1cf91b77dc879b7974b490d3ebd2e95426057f35d0a3 + c9f45f79ac727ab81a519a8b9285932d9b2e5ccd347e59f3f32ad9ca359115e7da00 + 8ab7406707bd0e8e185a5ed8758b5ba266e8828f8d863ae133846304a2936ad7bc7c + 9803879d2fc4a28e69291d73dbd799f8bc238385 + n = aec4d69addc70b990ea66a5e70603b6fee27aafebd08f2d94cbe1250c556e047 + a928d635c3f45ee9b66d1bc628a03bac9b7c3f416fe20dabea8f3d7b4bbf7f963be3 + 35d2328d67e6c13ee4a8f955e05a3283720d3e1f139c38e43e0338ad058a9495c533 + 77fc35be64d208f89b4aa721bf7f7d3fef837be2a80e0f8adf0bcd1eec5bb040443a + 2b2792fdca522a7472aed74f31a1ebe1eebc1f408660a0543dfe2a850f106a617ec6 + 685573702eaaa21a5640a5dcaf9b74e397fa3af18a2f1b7c03ba91a6336158de420d + 63188ee143866ee415735d155b7c2d854d795b7bc236cffd71542df34234221a0413 + e142d8c61355cc44d45bda94204974557ac2704cd8b593f035a5724b1adf442e78c5 + 42cd4414fce6f1298182fb6d8e53cef1adfd2e90e1e4deec52999bdc6c29144e8d52 + a125232c8c6d75c706ea3cc06841c7bda33568c63a6c03817f722b50fcf898237d78 + 8a4400869e44d90a3020923dc646388abcc914315215fcd1bae11b1c751fd52443aa + c8f601087d8d42737c18a3fa11ecd4131ecae017ae0a14acfc4ef85b83c19fed33cf + d1cd629da2c4c09e222b398e18d822f77bb378dea3cb360b605e5aa58b20edc29d00 + 0a66bd177c682a17e7eb12a63ef7c2e4183e0d898f3d6bf567ba8ae84f84f1d23bf8 + b8e261c3729e2fa6d07b832e07cddd1d14f55325c6f924267957121902dc19b3b329 + 48bdead5 + e = 010001 + d = 0d43242aefe1fb2c13fbc66e20b678c4336d20b1808c558b6e62ad16a2870771 + 80b177e1f01b12f9c6cd6c52630257ccef26a45135a990928773f3bd2fc01a313f1d + ac97a51cec71cb1fd7efc7adffdeb05f1fb04812c924ed7f4a8269925dad88bd7dcf + bc4ef01020ebfc60cb3e04c54f981fdbd273e69a8a58b8ceb7c2d83fbcbd6f784d05 + 2201b88a9848186f2a45c0d2826870733e6fd9aa46983e0a6e82e35ca20a439c5ee7 + b502a9062e1066493bdadf8b49eb30d9558ed85abc7afb29b3c9bc644199654a4676 + 681af4babcea4e6f71fe4565c9c1b85d9985b84ec1abf1a820a9bbebee0df1398aae + 2c85ab580a9f13e7743afd3108eb32100b870648fa6bc17e8abac4d3c99246b1f0ea + 9f7f93a5dd5458c56d9f3f81ff2216b3c3680a13591673c43194d8e6fc93fc1e37ce + 2986bd628ac48088bc723d8fbe293861ca7a9f4a73e9fa63b1b6d0074f5dea2a624c + 5249ff3ad811b6255b299d6bc5451ba7477f19c5a0db690c3e6476398b1483d10314 + afd38bbaf6e2fbdbcd62c3ca9797a420ca6034ec0a83360a3ee2adf4b9d4ba29731d + 131b099a38d6a23cc463db754603211260e99d19affc902c915d7854554aabf608e3 + ac52c19b8aa26ae042249b17b2d29669b5c859103ee53ef9bdc73ba3c6b537d5c34b + 6d8f034671d7f3a8a6966cc4543df223565343154140fd7391c7e7be03e241f4ecfe + b877a051 + msg = 8f3dc6fb8c4a02f4d6352edf0907822c1210a9b32f9bdda4c45a698c80023a + a6b59f8cfec5fdbb36331372ebefedae7d + msg_prefix = 8417e699b219d583fb6216ae0c53ca0e9723442d02f1d1a34295527 + e7d929e8b + prepared_msg = 8417e699b219d583fb6216ae0c53ca0e9723442d02f1d1a342955 + 27e7d929e8b8f3dc6fb8c4a02f4d6352edf0907822c1210a9b32f9bdda4c45a698c8 + 0023aa6b59f8cfec5fdbb36331372ebefedae7d + salt = 051722b35f458781397c3a671a7d3bd3096503940e4c4f1aaa269d60300ce + 449555cd7340100df9d46944c5356825abf + encoded_msg = 2be01c5669eb676cb3f0002eb636427d61568f3f0579da5b998279 + a7eb3ab784e5617319376d04809d83e72bef9f0738e7324af3fd1b4f0a35f4f58058 + ab329495406bdb5ff31a0274be2d137c735ab0d5a591b3129a6cc46fcecc4b41dbc6 + 84c965cb30e3eb4864ef18cc8d95b4d6a2002607c821d4d8a7e026ae7bb1f6b4c7c9 + 3d1b58e9cd87864d6094b0d8f7e2b5f966473703634fb58c774dd4a24376e0eb262a + 24b58e3a0b4da4f36ef75651627561ff2ecee9dcbfe1d728cc31a7b46030f7a2815a + e9edf9a2a5c0c6d8dbab1b33b9c3bbda5c083670a3550f7d74c4263aad09f8ed1d43 + 5fc6295ca4d51fc02c7de9ae28ffd53372c3fa864521b27560daa11ab9daad8d0d74 + 7661718d2f79c59d0661b09c74863fa32bdcb1c408d3bd24569c57aecae6e06c0c9d + eb7303c5b7b1240960fd2413d61b2e3829af8c09874fdba0fe84ca6aa7e7d533f9b0 + ddfe508f562b132ca2d325f1e73f91a8a6b831a2fd9bc0bd5bfa5ea3a1dee16bd9b2 + 64174b9553a4c0c0d62373353355c05b35824e4bae702f49e5a6bf83eaff65af4990 + 45bcef1470a0e58ddb21856034af0db96f8636d4a6f1591f34c7224e0c0293e3d3be + 2139f2797c5ed8b65473ac2f83c52b87f8cf8754ac2f55f5e41e105df1d079a647fb + 1aa591526295667f37db1129752d024eb03bfe506a43665072118423351ef9b86633 + 76f9fc073141e1e7bc + inv = 80682c48982407b489d53d1261b19ec8627d02b8cda5336750b8cee332ae26 + 0de57b02d72609c1e0e9f28e2040fc65b6f02d56dbd6aa9af8fde656f70495dfb723 + ba01173d4707a12fddac628ca29f3e32340bd8f7ddb557cf819f6b01e445ad96f874 + ba235584ee71f6581f62d4f43bf03f910f6510deb85e8ef06c7f09d9794a008be7ff + 2529f0ebb69decef646387dc767b74939265fec0223aa6d84d2a8a1cc912d5ca25b4 + e144ab8f6ba054b54910176d5737a2cff011da431bd5f2a0d2d66b9e70b39f4b050e + 45c0d9c16f02deda9ddf2d00f3e4b01037d7029cd49c2d46a8e1fc2c0c17520af1f4 + b5e25ba396afc4cd60c494a4c426448b35b49635b337cfb08e7c22a39b256dd032c0 + 0adddafb51a627f99a0e1704170ac1f1912e49d9db10ec04c19c58f420212973e0cb + 329524223a6aa56c7937c5dffdb5d966b6cd4cbc26f3201dd25c80960a1a111b3294 + 7bb78973d269fac7f5186530930ed19f68507540eed9e1bab8b00f00d8ca09b3f099 + aae46180e04e3584bd7ca054df18a1504b89d1d1675d0966c4ae1407be325cdf623c + f13ff13e4a28b594d59e3eadbadf6136eee7a59d6a444c9eb4e2198e8a974f27a39e + b63af2c9af3870488b8adaad444674f512133ad80b9220e09158521614f1faadfe85 + 05ef57b7df6813048603f0dd04f4280177a11380fbfc861dbcbd7418d62155248dad + 5fdec0991f + blinded_msg = aa3ee045138d874669685ffaef962c7694a9450aa9b4fd6465db9b + 3b75a522bb921c4c0fdcdfae9667593255099cff51f5d3fd65e8ffb9d3b3036252a6 + b51b6edfb3f40382b2bbf34c0055e4cbcc422850e586d84f190cd449af11dc65545f + 5fe26fd89796eb87da4bda0c545f397cddfeeb56f06e28135ec74fd477949e7677f6 + f36cfae8fd5c1c5898b03b9c244cf6d1a4fb7ad1cb43aff5e80cb462fac541e72f67 + f0a50f1843d1759edfaae92d1a916d3f0efaf4d650db416c3bf8abdb5414a78cebc9 + 7de676723cb119e77aea489f2bbf530c440ebc5a75dccd3ebf5a412a5f346badd61b + ee588e5917bdcce9dc33c882e39826951b0b8276c6203971947072b726e935816056 + ff5cb11a71ca2946478584126bb877acdf87255f26e6cca4e0878801307485d3b7bb + 89b289551a8b65a7a6b93db010423d1406e149c87731910306e5e410b41d4da32346 + 24e74f92845183e323cf7eb244f212a695f8856c675fbc3a021ce649e22c6f0d053a + 9d238841cf3afdc2739f99672a419ae13c17f1f8a3bc302ec2e7b98e8c353898b715 + 0ad8877ec841ea6e4b288064c254fefd0d049c3ad196bf7ffa535e74585d0120ce72 + 8036ed500942fbd5e6332c298f1ffebe9ff60c1e117b274cf0cb9d70c36ee4891528 + 996ec1ed0b178e9f3c0c0e6120885f39e8ccaadbb20f3196378c07b1ff22d10049d3 + 039a7a92fe7efdd95d + blind_sig = 3f4a79eacd4445fca628a310d41e12fcd813c4d43aa4ef2b81226953 + 248d6d00adfee6b79cb88bfa1f99270369fd063c023e5ed546719b0b2d143dd1bca4 + 6b0e0e615fe5c63d95c5a6b873b8b50bc52487354e69c3dfbf416e7aca18d5842c89 + b676efdd38087008fa5a810161fcdec26f20ccf2f1e6ab0f9d2bb93e051cb9e86a9b + 28c5bb62fd5f5391379f887c0f706a08bcc3b9e7506aaf02485d688198f5e22eefdf + 837b2dd919320b17482c5cc54271b4ccb41d267629b3f844fd63750b01f5276c79e3 + 3718bb561a152acb2eb36d8be75bce05c9d1b94eb609106f38226fb2e0f5cd5c5c39 + c59dda166862de498b8d92f6bcb41af433d65a2ac23da87f39764cb64e79e74a8f4c + e4dd567480d967cefac46b6e9c06434c3715635834357edd2ce6f105eea854ac126c + cfa3de2aac5607565a4e5efaac5eed491c335f6fc97e6eb7e9cea3e12de38dfb3152 + 20c0a3f84536abb2fdd722813e083feda010391ac3d8fd1cd9212b5d94e634e69ebc + c800c4d5c4c1091c64afc37acf563c7fc0a6e4c082bc55544f50a7971f3fb97d5853 + d72c3af34ffd5ce123998be5360d1059820c66a81e1ee6d9c1803b5b62af6bc87752 + 6df255b6d1d835d8c840bebbcd6cc0ee910f17da37caf8488afbc08397a1941fcc79 + e76a5888a95b3d5405e13f737bea5c78d716a48eb9dc0aec8de39c4b45c6914ad4a8 + 185969f70b1adf46 + sig = 191e941c57510e22d29afad257de5ca436d2316221fe870c7cb75205a6c071 + c2735aed0bc24c37f3d5bd960ab97a829a508f966bbaed7a82645e65eadaf24ab5e6 + d9421392c5b15b7f9b640d34fec512846a3100b80f75ef51064602118c1a77d28d93 + 8f6efc22041d60159a518d3de7c4d840c9c68109672d743d299d8d2577ef60c19ab4 + 63c716b3fa75fa56f5735349d414a44df12bf0dd44aa3e10822a651ed4cb0eb6f47c + 9bd0ef14a034a7ac2451e30434d513eb22e68b7587a8de9b4e63a059d05c8b22c7c5 + 1e2cfee2d8bef511412e93c859a13726d87c57d1bc4c2e68ab121562f839c3a3d233 + e87ed63c69b7e57525367753fbebcc2a9805a2802659f5888b2c69115bf865559f10 + d906c09d048a0d71bfee4b33857393ec2b69e451433496d02c9a7910abb954317720 + bbde9e69108eafc3e90bad3d5ca4066d7b1e49013fa04e948104a1dd82b12509ecb1 + 46e948c54bd8bfb5e6d18127cd1f7a93c3cf9f2d869d5a78878c03fe808a0d799e91 + 0be6f26d18db61c485b303631d3568368fc41986d08a95ea6ac0592240c19d7b2241 + 6b9c82ae6241e211dd5610d0baaa9823158f9c32b66318f5529491b7eeadcaa71898 + a63bac9d95f4aa548d5e97568d744fc429104e32edd9c87519892a198a30d333d427 + 739ffb9607b092e910ae37771abf2adb9f63bc058bf58062ad456cb934679795bbdf + cdfad5e0f2 + +A.2. RSABSSA-SHA384-PSSZERO-Randomized Test Vector + + p = e1f4d7a34802e27c7392a3cea32a262a34dc3691bd87f3f310dc756734889305 + 59c120fd0410194fb8a0da55bd0b81227e843fdca6692ae80e5a5d414116d4803fca + 7d8c30eaaae57e44a1816ebb5c5b0606c536246c7f11985d731684150b63c9a3ad9e + 41b04c0b5b27cb188a692c84696b742a80d3cd00ab891f2457443dadfeba6d6daf10 + 8602be26d7071803c67105a5426838e6889d77e8474b29244cefaf418e381b312048 + b457d73419213063c60ee7b0d81820165864fef93523c9635c22210956e53a8d9632 + 2493ffc58d845368e2416e078e5bcb5d2fd68ae6acfa54f9627c42e84a9d3f277401 + 7e32ebca06308a12ecc290c7cd1156dcccfb2311 + q = c601a9caea66dc3835827b539db9df6f6f5ae77244692780cd334a006ab353c8 + 06426b60718c05245650821d39445d3ab591ed10a7339f15d83fe13f6a3dfb20b945 + 2c6a9b42eaa62a68c970df3cadb2139f804ad8223d56108dfde30ba7d367e9b0a7a8 + 0c4fdba2fd9dde6661fc73fc2947569d2029f2870fc02d8325acf28c9afa19ecf962 + daa7916e21afad09eb62fe9f1cf91b77dc879b7974b490d3ebd2e95426057f35d0a3 + c9f45f79ac727ab81a519a8b9285932d9b2e5ccd347e59f3f32ad9ca359115e7da00 + 8ab7406707bd0e8e185a5ed8758b5ba266e8828f8d863ae133846304a2936ad7bc7c + 9803879d2fc4a28e69291d73dbd799f8bc238385 + n = aec4d69addc70b990ea66a5e70603b6fee27aafebd08f2d94cbe1250c556e047 + a928d635c3f45ee9b66d1bc628a03bac9b7c3f416fe20dabea8f3d7b4bbf7f963be3 + 35d2328d67e6c13ee4a8f955e05a3283720d3e1f139c38e43e0338ad058a9495c533 + 77fc35be64d208f89b4aa721bf7f7d3fef837be2a80e0f8adf0bcd1eec5bb040443a + 2b2792fdca522a7472aed74f31a1ebe1eebc1f408660a0543dfe2a850f106a617ec6 + 685573702eaaa21a5640a5dcaf9b74e397fa3af18a2f1b7c03ba91a6336158de420d + 63188ee143866ee415735d155b7c2d854d795b7bc236cffd71542df34234221a0413 + e142d8c61355cc44d45bda94204974557ac2704cd8b593f035a5724b1adf442e78c5 + 42cd4414fce6f1298182fb6d8e53cef1adfd2e90e1e4deec52999bdc6c29144e8d52 + a125232c8c6d75c706ea3cc06841c7bda33568c63a6c03817f722b50fcf898237d78 + 8a4400869e44d90a3020923dc646388abcc914315215fcd1bae11b1c751fd52443aa + c8f601087d8d42737c18a3fa11ecd4131ecae017ae0a14acfc4ef85b83c19fed33cf + d1cd629da2c4c09e222b398e18d822f77bb378dea3cb360b605e5aa58b20edc29d00 + 0a66bd177c682a17e7eb12a63ef7c2e4183e0d898f3d6bf567ba8ae84f84f1d23bf8 + b8e261c3729e2fa6d07b832e07cddd1d14f55325c6f924267957121902dc19b3b329 + 48bdead5 + e = 010001 + d = 0d43242aefe1fb2c13fbc66e20b678c4336d20b1808c558b6e62ad16a2870771 + 80b177e1f01b12f9c6cd6c52630257ccef26a45135a990928773f3bd2fc01a313f1d + ac97a51cec71cb1fd7efc7adffdeb05f1fb04812c924ed7f4a8269925dad88bd7dcf + bc4ef01020ebfc60cb3e04c54f981fdbd273e69a8a58b8ceb7c2d83fbcbd6f784d05 + 2201b88a9848186f2a45c0d2826870733e6fd9aa46983e0a6e82e35ca20a439c5ee7 + b502a9062e1066493bdadf8b49eb30d9558ed85abc7afb29b3c9bc644199654a4676 + 681af4babcea4e6f71fe4565c9c1b85d9985b84ec1abf1a820a9bbebee0df1398aae + 2c85ab580a9f13e7743afd3108eb32100b870648fa6bc17e8abac4d3c99246b1f0ea + 9f7f93a5dd5458c56d9f3f81ff2216b3c3680a13591673c43194d8e6fc93fc1e37ce + 2986bd628ac48088bc723d8fbe293861ca7a9f4a73e9fa63b1b6d0074f5dea2a624c + 5249ff3ad811b6255b299d6bc5451ba7477f19c5a0db690c3e6476398b1483d10314 + afd38bbaf6e2fbdbcd62c3ca9797a420ca6034ec0a83360a3ee2adf4b9d4ba29731d + 131b099a38d6a23cc463db754603211260e99d19affc902c915d7854554aabf608e3 + ac52c19b8aa26ae042249b17b2d29669b5c859103ee53ef9bdc73ba3c6b537d5c34b + 6d8f034671d7f3a8a6966cc4543df223565343154140fd7391c7e7be03e241f4ecfe + b877a051 + msg = 8f3dc6fb8c4a02f4d6352edf0907822c1210a9b32f9bdda4c45a698c80023a + a6b59f8cfec5fdbb36331372ebefedae7d + msg_prefix = 84ea86c8cf3beedfed73beceabd792027c609d1100bf041fdd60d82 + 6a718130d + prepared_msg = 84ea86c8cf3beedfed73beceabd792027c609d1100bf041fdd60d + 826a718130d8f3dc6fb8c4a02f4d6352edf0907822c1210a9b32f9bdda4c45a698c8 + 0023aa6b59f8cfec5fdbb36331372ebefedae7d + salt = + encoded_msg = 37f4ea66054b3570f2c46f43125a8df8d751a81db1003edcc70e98 + 88cb3d0fa71bb7634437a779c1bf9e84e88b3479894490ee41cd69fc8e911478326f + e8460d1699f96abedde22ba0ba25a02f78bae77eb039decd41e6cd40fecc28f301c9 + 4d5644eb3e55b316569e2bec3ccf8e33b06eb6defca5fe672613d33ea60f84daa560 + ded4c1c5e65613fb19e090d0fc96a1394e29dfad6a7644362bf30bdc90c7ca0a0651 + 90f5a099b5c33ae787b872518a724d9aa139229656eb21053bbe86c38f6d03b4c6fa + 37a900935d9b8d19e0c394be4af6af028680996e3fd533b6698ce9e2ed6a9f96d4d3 + a682027ae5240040e55d75017dc303b7142c1f7e17b79778a94431398d21dc0cc7ae + 454cc0d6cf4db4d588d3fd15fd7f71576052fd2a52d688f99790dfb13808ecb24b6b + 9e9a43a8c0105670ec3ad8d6318a9c6a9cef9eb99b36d74b8e83dbacf6e8100e135b + 609850b34a4b01091b263678d7cd9905af2ffda801a2888d863a25211903b43cb5e5 + 9f5dba6bc18713ce4f028f1774c593664912f1d181d4544a13a1da354332d8595f59 + cf5af260a8aaf21a6bc948b5d5d4a520c1f72c216259dc12a33c2a3bd4d32ff2bf3d + e2ffe76e51f8af030b40fadc5899e740da20be1dd5a50f701292ceaee51fa35d9a04 + 7f3efc6543dc583fb3f23abeade39c2a5b5b352de26d7a11267435be7bffa8f2292e + 139fad923dbaf863bc + inv = 80682c48982407b489d53d1261b19ec8627d02b8cda5336750b8cee332ae26 + 0de57b02d72609c1e0e9f28e2040fc65b6f02d56dbd6aa9af8fde656f70495dfb723 + ba01173d4707a12fddac628ca29f3e32340bd8f7ddb557cf819f6b01e445ad96f874 + ba235584ee71f6581f62d4f43bf03f910f6510deb85e8ef06c7f09d9794a008be7ff + 2529f0ebb69decef646387dc767b74939265fec0223aa6d84d2a8a1cc912d5ca25b4 + e144ab8f6ba054b54910176d5737a2cff011da431bd5f2a0d2d66b9e70b39f4b050e + 45c0d9c16f02deda9ddf2d00f3e4b01037d7029cd49c2d46a8e1fc2c0c17520af1f4 + b5e25ba396afc4cd60c494a4c426448b35b49635b337cfb08e7c22a39b256dd032c0 + 0adddafb51a627f99a0e1704170ac1f1912e49d9db10ec04c19c58f420212973e0cb + 329524223a6aa56c7937c5dffdb5d966b6cd4cbc26f3201dd25c80960a1a111b3294 + 7bb78973d269fac7f5186530930ed19f68507540eed9e1bab8b00f00d8ca09b3f099 + aae46180e04e3584bd7ca054df18a1504b89d1d1675d0966c4ae1407be325cdf623c + f13ff13e4a28b594d59e3eadbadf6136eee7a59d6a444c9eb4e2198e8a974f27a39e + b63af2c9af3870488b8adaad444674f512133ad80b9220e09158521614f1faadfe85 + 05ef57b7df6813048603f0dd04f4280177a11380fbfc861dbcbd7418d62155248dad + 5fdec0991f + blinded_msg = 4c1b82d9b97b968b2ce0754e326abd49e3d723ed937d84bead34b6 + a834483b43d510bf62ca47683ed366d94d3d357b270a85cf2cc2ddd171141b45d754 + 9d5373cf67d14f6f462c14ebded906793144faba37f129c0f3172854ec0f854e5555 + 52eec5a30c87788f1039814594f04348709e26a883be82affff207b1886b75c037f4 + 3f847f45d89bcbf210c22ffcdf8118ce8a526b3723e6209c26319f8f5d2adcf0b637 + 031c9fdf53470a915c587e30287ba88ed4f1cd5e93cf3d4990acf31fffdbfddec80a + e0b728d5b4c612a396fd81acaa65566a4dc1c24624f44fd10cdba05f3d0bed2e69bb + 0d13d41a9f1b4e67aa566520778733ced5e6260f4d1982f63bb835442acffe3cb87f + 5f8ec6bb84226e0eab787159d08e57604b13557ceea97f2c4ad0631accf898f302df + 86f0b64354ec0b3bdf1b4e2a4deb4d38f655ea8d80de4cc19aa06ffcd56e348faf89 + 4c8774c53235ddcc152d80cf66b417eee4d182781bab8c979937a3c7502d8f39c57c + 4f09884de5a7247f2539910a96e4b15f9a3df88edc21a13030af357467a99dca50db + a4afe4a6185a240ac8f1d8aab2e83443025f94e1af930f56f78661369cc6790701f3 + 1b83aec40f96a72c7f7ba13b4ebdd8e24e7351f4ffba0a7c072cb28f13aff06cd023 + 68491044fcc536213b2e3b1cf6ca81cf2097b7b19d2b36bd246f390f53768f1c2e56 + 113ea91b33c7cfa647 + blind_sig = 4894f64d7214c216282d9842cbf7e7cccd9c0dcb1f4294a6bdeccd4c + 4c2446160d7cac7892f01b70dfa69f533891d2fbb447f7cf7541d1b504a2d46fc1bb + 6de26b345972aada8ebce280b906f3a10a13208f77ef896fbe6bc4504327fd4c5c8f + 03211d45ae9672e9f4be0f4900762ba2a7177a58b90d6dd1263faf2b7a5f15d50a7b + 00e733742c1b6a1ea4eb5fbfb407abf14496ab26b50cf1a5a56dea616b7a6a559577 + 7400571a751c682b9fdd6badb3f72292f314f4ba2ba0f394f91676a4bb12e60ea08c + 977f7082be6357c1ca82fe3301fe5fb4128609bee2410db0481aea3a5737fb0bce93 + 81272c2202644f662e99f64bf1190d66e230cc0371ec33fe32fe725dfd872041914d + 39462a909414a780c9aab394af443199eba56c83986d22d57d4421b41ff8e5bec537 + d271223adb34d26c64989048a88d8f352a06a7cc153e216a6bed9548bb38d2a1600b + 2f3403289df6df74aec525ef9e413b7140a7c1a914dedd74a336f1beed39a8e5e2ce + f76cac094df0dbb3fa55d4b7ee781c74bed3bd8bc7aa6ef3f1dbfa4674945720ec93 + dafa6d0650229ab75e3fae687327fac081cf4bb376e02a2b73314c54c12f88572c28 + 980f13aba5731bc5a3a60575ea116c8ea2fe5009168deb1255026c9310783ff7f644 + 255d3e1691e194db1babd7780b9a5dc0cb3de2b700d12f49cbe4db51ca2f3c8a58b0 + 9e854cc71e8070ab + sig = 195363ba25e4bf763f6538c86865785f93f4ea6092da3ad200d41b99eb0eb0 + 869fa792df619fd8fa5923d5d03d5882faae6d25054118deef5e4a6a252dd5afb0da + c262b74c391090b1575fbafd959d26bc294f47fb45a2c1c209932c4f94b24394eded + 91fbdd015e1a85dde63c9e77a0283f812cad1192d86432c51331e46fd4f3771bbafb + 929f847a19cb05e5f79b6b519d67e8f005951e53656be97cb612d2f506618b366403 + b34648451d6fbc7318c2f3f583cc6fa17bf2108398f9284e0602187904406a9322f1 + e7b8016ca9ad11b835756df862c465c420535e25faa48bf341f7ee8192be47fa8757 + 91f32f56d5e631d237060688f052426dee5b0b2b74ca5f830e82a453379eedb541fa + 4fcdaa19dae6509401e3cdd4c40f5c9243db3f6d7115c4e8cd6db8290723ab01d9d0 + d7e355a97a01547800e43f11736668c3f8908848d759c33a67a2f506abc3f6871cbe + 625b1bc71eb06d785a59501396712c581a60d6ccc450d2f4eb4cf08ae0dbfa45c286 + 0425be90cc4cd4c989495bbd2963e19c59ae5d90d1ca884e80d654b5f2cd6a80c358 + 8b514ee91c802736f594c340397b316a97e9c70b0609955b6c3ee06f4760d9377f07 + 97a0411a244db395bb8b711ef79fbcb5589226174029be79a72dcd6f4ca566b7b1b9 + a27e43b5c02a9a579d60bdda183398d66d76e0e8eceb1af2f27633589d043bcdc041 + 683b31f7f1 + +A.3. RSABSSA-SHA384-PSS-Deterministic Test Vector + + p = e1f4d7a34802e27c7392a3cea32a262a34dc3691bd87f3f310dc756734889305 + 59c120fd0410194fb8a0da55bd0b81227e843fdca6692ae80e5a5d414116d4803fca + 7d8c30eaaae57e44a1816ebb5c5b0606c536246c7f11985d731684150b63c9a3ad9e + 41b04c0b5b27cb188a692c84696b742a80d3cd00ab891f2457443dadfeba6d6daf10 + 8602be26d7071803c67105a5426838e6889d77e8474b29244cefaf418e381b312048 + b457d73419213063c60ee7b0d81820165864fef93523c9635c22210956e53a8d9632 + 2493ffc58d845368e2416e078e5bcb5d2fd68ae6acfa54f9627c42e84a9d3f277401 + 7e32ebca06308a12ecc290c7cd1156dcccfb2311 + q = c601a9caea66dc3835827b539db9df6f6f5ae77244692780cd334a006ab353c8 + 06426b60718c05245650821d39445d3ab591ed10a7339f15d83fe13f6a3dfb20b945 + 2c6a9b42eaa62a68c970df3cadb2139f804ad8223d56108dfde30ba7d367e9b0a7a8 + 0c4fdba2fd9dde6661fc73fc2947569d2029f2870fc02d8325acf28c9afa19ecf962 + daa7916e21afad09eb62fe9f1cf91b77dc879b7974b490d3ebd2e95426057f35d0a3 + c9f45f79ac727ab81a519a8b9285932d9b2e5ccd347e59f3f32ad9ca359115e7da00 + 8ab7406707bd0e8e185a5ed8758b5ba266e8828f8d863ae133846304a2936ad7bc7c + 9803879d2fc4a28e69291d73dbd799f8bc238385 + n = aec4d69addc70b990ea66a5e70603b6fee27aafebd08f2d94cbe1250c556e047 + a928d635c3f45ee9b66d1bc628a03bac9b7c3f416fe20dabea8f3d7b4bbf7f963be3 + 35d2328d67e6c13ee4a8f955e05a3283720d3e1f139c38e43e0338ad058a9495c533 + 77fc35be64d208f89b4aa721bf7f7d3fef837be2a80e0f8adf0bcd1eec5bb040443a + 2b2792fdca522a7472aed74f31a1ebe1eebc1f408660a0543dfe2a850f106a617ec6 + 685573702eaaa21a5640a5dcaf9b74e397fa3af18a2f1b7c03ba91a6336158de420d + 63188ee143866ee415735d155b7c2d854d795b7bc236cffd71542df34234221a0413 + e142d8c61355cc44d45bda94204974557ac2704cd8b593f035a5724b1adf442e78c5 + 42cd4414fce6f1298182fb6d8e53cef1adfd2e90e1e4deec52999bdc6c29144e8d52 + a125232c8c6d75c706ea3cc06841c7bda33568c63a6c03817f722b50fcf898237d78 + 8a4400869e44d90a3020923dc646388abcc914315215fcd1bae11b1c751fd52443aa + c8f601087d8d42737c18a3fa11ecd4131ecae017ae0a14acfc4ef85b83c19fed33cf + d1cd629da2c4c09e222b398e18d822f77bb378dea3cb360b605e5aa58b20edc29d00 + 0a66bd177c682a17e7eb12a63ef7c2e4183e0d898f3d6bf567ba8ae84f84f1d23bf8 + b8e261c3729e2fa6d07b832e07cddd1d14f55325c6f924267957121902dc19b3b329 + 48bdead5 + e = 010001 + d = 0d43242aefe1fb2c13fbc66e20b678c4336d20b1808c558b6e62ad16a2870771 + 80b177e1f01b12f9c6cd6c52630257ccef26a45135a990928773f3bd2fc01a313f1d + ac97a51cec71cb1fd7efc7adffdeb05f1fb04812c924ed7f4a8269925dad88bd7dcf + bc4ef01020ebfc60cb3e04c54f981fdbd273e69a8a58b8ceb7c2d83fbcbd6f784d05 + 2201b88a9848186f2a45c0d2826870733e6fd9aa46983e0a6e82e35ca20a439c5ee7 + b502a9062e1066493bdadf8b49eb30d9558ed85abc7afb29b3c9bc644199654a4676 + 681af4babcea4e6f71fe4565c9c1b85d9985b84ec1abf1a820a9bbebee0df1398aae + 2c85ab580a9f13e7743afd3108eb32100b870648fa6bc17e8abac4d3c99246b1f0ea + 9f7f93a5dd5458c56d9f3f81ff2216b3c3680a13591673c43194d8e6fc93fc1e37ce + 2986bd628ac48088bc723d8fbe293861ca7a9f4a73e9fa63b1b6d0074f5dea2a624c + 5249ff3ad811b6255b299d6bc5451ba7477f19c5a0db690c3e6476398b1483d10314 + afd38bbaf6e2fbdbcd62c3ca9797a420ca6034ec0a83360a3ee2adf4b9d4ba29731d + 131b099a38d6a23cc463db754603211260e99d19affc902c915d7854554aabf608e3 + ac52c19b8aa26ae042249b17b2d29669b5c859103ee53ef9bdc73ba3c6b537d5c34b + 6d8f034671d7f3a8a6966cc4543df223565343154140fd7391c7e7be03e241f4ecfe + b877a051 + msg = 8f3dc6fb8c4a02f4d6352edf0907822c1210a9b32f9bdda4c45a698c80023a + a6b59f8cfec5fdbb36331372ebefedae7d + msg_prefix = + prepared_msg = 8f3dc6fb8c4a02f4d6352edf0907822c1210a9b32f9bdda4c45a6 + 98c80023aa6b59f8cfec5fdbb36331372ebefedae7d + salt = 051722b35f458781397c3a671a7d3bd3096503940e4c4f1aaa269d60300ce + 449555cd7340100df9d46944c5356825abf + encoded_msg = 6e0c464d9c2f9fbc147b43570fc4f238e0d0b38870b3addcf7a421 + 7df912ccef17a7f629aa850f63a063925f312d61d6437be954b45025e8282f9c0b11 + 31bc8ff19a8a928d859b37113db1064f92a27f64761c181c1e1f9b251ae5a2f8a404 + 7573b67a270584e089beadcb13e7c82337797119712e9b849ff56e04385d144d3ca9 + d8d92bf78adb20b5bbeb3685f17038ec6afade3ef354429c51c687b45a7018ee3a69 + 66b3af15c9ba8f40e6461ba0a17ef5a799672ad882bab02b518f9da7c1a962945c2e + 9b0f02f29b31b9cdf3e633f9d9d2a22e96e1de28e25241ca7dd04147112f57897340 + 3e0f4fd80865965475d22294f065e17a1c4a201de93bd14223e6b1b999fd548f2f75 + 9f52db71964528b6f15b9c2d7811f2a0a35d534b8216301c47f4f04f412cae142b48 + c4cdff78bc54df690fd43142d750c671dd8e2e938e6a440b2f825b6dbb3e19f1d7a3 + c0150428a47948037c322365b7fe6fe57ac88d8f80889e9ff38177bad8c8d8d98db4 + 2908b389cb59692a58ce275aa15acb032ca951b3e0a3404b7f33f655b7c7d83a2f8d + 1b6bbff49d5fcedf2e030e80881aa436db27a5c0dea13f32e7d460dbf01240c2320c + 2bb5b3225b17145c72d61d47c8f84d1e19417ebd8ce3638a82d395cc6f7050b6209d + 9283dc7b93fecc04f3f9e7f566829ac41568ef799480c733c09759aa9734e2013d76 + 40dc6151018ea902bc + inv = 80682c48982407b489d53d1261b19ec8627d02b8cda5336750b8cee332ae26 + 0de57b02d72609c1e0e9f28e2040fc65b6f02d56dbd6aa9af8fde656f70495dfb723 + ba01173d4707a12fddac628ca29f3e32340bd8f7ddb557cf819f6b01e445ad96f874 + ba235584ee71f6581f62d4f43bf03f910f6510deb85e8ef06c7f09d9794a008be7ff + 2529f0ebb69decef646387dc767b74939265fec0223aa6d84d2a8a1cc912d5ca25b4 + e144ab8f6ba054b54910176d5737a2cff011da431bd5f2a0d2d66b9e70b39f4b050e + 45c0d9c16f02deda9ddf2d00f3e4b01037d7029cd49c2d46a8e1fc2c0c17520af1f4 + b5e25ba396afc4cd60c494a4c426448b35b49635b337cfb08e7c22a39b256dd032c0 + 0adddafb51a627f99a0e1704170ac1f1912e49d9db10ec04c19c58f420212973e0cb + 329524223a6aa56c7937c5dffdb5d966b6cd4cbc26f3201dd25c80960a1a111b3294 + 7bb78973d269fac7f5186530930ed19f68507540eed9e1bab8b00f00d8ca09b3f099 + aae46180e04e3584bd7ca054df18a1504b89d1d1675d0966c4ae1407be325cdf623c + f13ff13e4a28b594d59e3eadbadf6136eee7a59d6a444c9eb4e2198e8a974f27a39e + b63af2c9af3870488b8adaad444674f512133ad80b9220e09158521614f1faadfe85 + 05ef57b7df6813048603f0dd04f4280177a11380fbfc861dbcbd7418d62155248dad + 5fdec0991f + blinded_msg = 10c166c6a711e81c46f45b18e5873cc4f494f003180dd7f115585d + 871a28930259654fe28a54dab319cc5011204c8373b50a57b0fdc7a678bd74c52325 + 9dfe4fd5ea9f52f170e19dfa332930ad1609fc8a00902d725cfe50685c95e5b2968c + 9a2828a21207fcf393d15f849769e2af34ac4259d91dfd98c3a707c509e1af55647e + faa31290ddf48e0133b798562af5eabd327270ac2fb6c594734ce339a14ea4fe1b9a + 2f81c0bc230ca523bda17ff42a377266bc2778a274c0ae5ec5a8cbbe364fcf0d2403 + f7ee178d77ff28b67a20c7ceec009182dbcaa9bc99b51ebbf13b7d542be337172c64 + 74f2cd3561219fe0dfa3fb207cff89632091ab841cf38d8aa88af6891539f263adb8 + eac6402c41b6ebd72984e43666e537f5f5fe27b2b5aa114957e9a580730308a5f5a9 + c63a1eb599f093ab401d0c6003a451931b6d124180305705845060ebba6b0036154f + cef3e5e9f9e4b87e8f084542fd1dd67e7782a5585150181c01eb6d90cb9588383738 + 4a5b91dbb606f266059ecc51b5acbaa280e45cfd2eec8cc1cdb1b7211c8e14805ba6 + 83f9b78824b2eb005bc8a7d7179a36c152cb87c8219e5569bba911bb32a1b923ca83 + de0e03fb10fba75d85c55907dda5a2606bf918b056c3808ba496a4d95532212040a5 + f44f37e1097f26dc27b98a51837daa78f23e532156296b64352669c94a8a855acf30 + 533d8e0594ace7c442 + blind_sig = 364f6a40dbfbc3bbb257943337eeff791a0f290898a6791283bba581 + d9eac90a6376a837241f5f73a78a5c6746e1306ba3adab6067c32ff69115734ce014 + d354e2f259d4cbfb890244fd451a497fe6ecf9aa90d19a2d441162f7eaa7ce3fc4e8 + 9fd4e76b7ae585be2a2c0fd6fb246b8ac8d58bcb585634e30c9168a434786fe5e0b7 + 4bfe8187b47ac091aa571ffea0a864cb906d0e28c77a00e8cd8f6aba4317a8cc7bf3 + 2ce566bd1ef80c64de041728abe087bee6cadd0b7062bde5ceef308a23bd1ccc154f + d0c3a26110df6193464fc0d24ee189aea8979d722170ba945fdcce9b1b4b63349980 + f3a92dc2e5418c54d38a862916926b3f9ca270a8cf40dfb9772bfbdd9a3e0e089236 + 9c18249211ba857f35963d0e05d8da98f1aa0c6bba58f47487b8f663e395091275f8 + 2941830b050b260e4767ce2fa903e75ff8970c98bfb3a08d6db91ab1746c86420ee2 + e909bf681cac173697135983c3594b2def673736220452fde4ddec867d40ff42dd3d + a36c84e3e52508b891a00f50b4f62d112edb3b6b6cc3dbd546ba10f36b03f06c0d82 + aeec3b25e127af545fac28e1613a0517a6095ad18a98ab79f68801e05c175e15bae2 + 1f821e80c80ab4fdec6fb34ca315e194502b8f3dcf7892b511aee45060e3994cd15e + 003861bc7220a2babd7b40eda03382548a34a7110f9b1779bf3ef6011361611e6bc5 + c0dc851e1509de1a + sig = 6fef8bf9bc182cd8cf7ce45c7dcf0e6f3e518ae48f06f3c670c649ac737a8b + 8119a34d51641785be151a697ed7825fdfece82865123445eab03eb4bb91cecf4d69 + 51738495f8481151b62de869658573df4e50a95c17c31b52e154ae26a04067d5ecdc + 1592c287550bb982a5bb9c30fd53a768cee6baabb3d483e9f1e2da954c7f4cf492fe + 3944d2fe456c1ecaf0840369e33fb4010e6b44bb1d721840513524d8e9a3519f40d1 + b81ae34fb7a31ee6b7ed641cb16c2ac999004c2191de0201457523f5a4700dd64926 + 7d9286f5c1d193f1454c9f868a57816bf5ff76c838a2eeb616a3fc9976f65d4371de + ecfbab29362caebdff69c635fe5a2113da4d4d8c24f0b16a0584fa05e80e607c5d9a + 2f765f1f069f8d4da21f27c2a3b5c984b4ab24899bef46c6d9323df4862fe51ce300 + fca40fb539c3bb7fe2dcc9409e425f2d3b95e70e9c49c5feb6ecc9d43442c33d5000 + 3ee936845892fb8be475647da9a080f5bc7f8a716590b3745c2209fe05b17992830c + e15f32c7b22cde755c8a2fe50bd814a0434130b807dc1b7218d4e85342d70695a5d7 + f29306f25623ad1e8aa08ef71b54b8ee447b5f64e73d09bdd6c3b7ca224058d7c67c + c7551e9241688ada12d859cb7646fbd3ed8b34312f3b49d69802f0eaa11bc4211c2f + 7a29cd5c01ed01a39001c5856fab36228f5ee2f2e1110811872fe7c865c42ed59029 + c706195d52 + +A.4. RSABSSA-SHA384-PSSZERO-Deterministic Test Vector + + p = e1f4d7a34802e27c7392a3cea32a262a34dc3691bd87f3f310dc756734889305 + 59c120fd0410194fb8a0da55bd0b81227e843fdca6692ae80e5a5d414116d4803fca + 7d8c30eaaae57e44a1816ebb5c5b0606c536246c7f11985d731684150b63c9a3ad9e + 41b04c0b5b27cb188a692c84696b742a80d3cd00ab891f2457443dadfeba6d6daf10 + 8602be26d7071803c67105a5426838e6889d77e8474b29244cefaf418e381b312048 + b457d73419213063c60ee7b0d81820165864fef93523c9635c22210956e53a8d9632 + 2493ffc58d845368e2416e078e5bcb5d2fd68ae6acfa54f9627c42e84a9d3f277401 + 7e32ebca06308a12ecc290c7cd1156dcccfb2311 + q = c601a9caea66dc3835827b539db9df6f6f5ae77244692780cd334a006ab353c8 + 06426b60718c05245650821d39445d3ab591ed10a7339f15d83fe13f6a3dfb20b945 + 2c6a9b42eaa62a68c970df3cadb2139f804ad8223d56108dfde30ba7d367e9b0a7a8 + 0c4fdba2fd9dde6661fc73fc2947569d2029f2870fc02d8325acf28c9afa19ecf962 + daa7916e21afad09eb62fe9f1cf91b77dc879b7974b490d3ebd2e95426057f35d0a3 + c9f45f79ac727ab81a519a8b9285932d9b2e5ccd347e59f3f32ad9ca359115e7da00 + 8ab7406707bd0e8e185a5ed8758b5ba266e8828f8d863ae133846304a2936ad7bc7c + 9803879d2fc4a28e69291d73dbd799f8bc238385 + n = aec4d69addc70b990ea66a5e70603b6fee27aafebd08f2d94cbe1250c556e047 + a928d635c3f45ee9b66d1bc628a03bac9b7c3f416fe20dabea8f3d7b4bbf7f963be3 + 35d2328d67e6c13ee4a8f955e05a3283720d3e1f139c38e43e0338ad058a9495c533 + 77fc35be64d208f89b4aa721bf7f7d3fef837be2a80e0f8adf0bcd1eec5bb040443a + 2b2792fdca522a7472aed74f31a1ebe1eebc1f408660a0543dfe2a850f106a617ec6 + 685573702eaaa21a5640a5dcaf9b74e397fa3af18a2f1b7c03ba91a6336158de420d + 63188ee143866ee415735d155b7c2d854d795b7bc236cffd71542df34234221a0413 + e142d8c61355cc44d45bda94204974557ac2704cd8b593f035a5724b1adf442e78c5 + 42cd4414fce6f1298182fb6d8e53cef1adfd2e90e1e4deec52999bdc6c29144e8d52 + a125232c8c6d75c706ea3cc06841c7bda33568c63a6c03817f722b50fcf898237d78 + 8a4400869e44d90a3020923dc646388abcc914315215fcd1bae11b1c751fd52443aa + c8f601087d8d42737c18a3fa11ecd4131ecae017ae0a14acfc4ef85b83c19fed33cf + d1cd629da2c4c09e222b398e18d822f77bb378dea3cb360b605e5aa58b20edc29d00 + 0a66bd177c682a17e7eb12a63ef7c2e4183e0d898f3d6bf567ba8ae84f84f1d23bf8 + b8e261c3729e2fa6d07b832e07cddd1d14f55325c6f924267957121902dc19b3b329 + 48bdead5 + e = 010001 + d = 0d43242aefe1fb2c13fbc66e20b678c4336d20b1808c558b6e62ad16a2870771 + 80b177e1f01b12f9c6cd6c52630257ccef26a45135a990928773f3bd2fc01a313f1d + ac97a51cec71cb1fd7efc7adffdeb05f1fb04812c924ed7f4a8269925dad88bd7dcf + bc4ef01020ebfc60cb3e04c54f981fdbd273e69a8a58b8ceb7c2d83fbcbd6f784d05 + 2201b88a9848186f2a45c0d2826870733e6fd9aa46983e0a6e82e35ca20a439c5ee7 + b502a9062e1066493bdadf8b49eb30d9558ed85abc7afb29b3c9bc644199654a4676 + 681af4babcea4e6f71fe4565c9c1b85d9985b84ec1abf1a820a9bbebee0df1398aae + 2c85ab580a9f13e7743afd3108eb32100b870648fa6bc17e8abac4d3c99246b1f0ea + 9f7f93a5dd5458c56d9f3f81ff2216b3c3680a13591673c43194d8e6fc93fc1e37ce + 2986bd628ac48088bc723d8fbe293861ca7a9f4a73e9fa63b1b6d0074f5dea2a624c + 5249ff3ad811b6255b299d6bc5451ba7477f19c5a0db690c3e6476398b1483d10314 + afd38bbaf6e2fbdbcd62c3ca9797a420ca6034ec0a83360a3ee2adf4b9d4ba29731d + 131b099a38d6a23cc463db754603211260e99d19affc902c915d7854554aabf608e3 + ac52c19b8aa26ae042249b17b2d29669b5c859103ee53ef9bdc73ba3c6b537d5c34b + 6d8f034671d7f3a8a6966cc4543df223565343154140fd7391c7e7be03e241f4ecfe + b877a051 + msg = 8f3dc6fb8c4a02f4d6352edf0907822c1210a9b32f9bdda4c45a698c80023a + a6b59f8cfec5fdbb36331372ebefedae7d + msg_prefix = + prepared_msg = 8f3dc6fb8c4a02f4d6352edf0907822c1210a9b32f9bdda4c45a6 + 98c80023aa6b59f8cfec5fdbb36331372ebefedae7d + salt = + encoded_msg = 159499b90471b496c2639ec482e99feaba525c0420c565d17dc60c + 1bb1f47703f04436cceaa8f69811e1bf8546fa971226c9e71421b32b571ed5ea0e03 + 2269d4219b4404316eb17a58f277634aeed394b7f3888153b5bb163e40807e605daf + dd1789dd473b0846bdcb6524417bc3a35366fab4261708c0e4b4beba07a1a64bbccb + 4b1ac215d1350a50a501e8e96612028b535ad731abf1f117ee07d07a4de9cef3d70f + 5845ba84c29d5d92c6e66a1f9489a5f527b846825360fd6e90f40ed041c682e489f3 + acde984a3ea580181418c1d15017af2657bc4b70485cdc0f1ebc3693e0d70a5d01f3 + 7ff640993fa071274fb9ee44e0c24dcb58ffa21a9a6540d87f24379beaafcc3b4bd4 + 2c45ec6820e03738ce98bea11c71685f31db63429fab8658bdb816f1ecccb1888f24 + 02de0bd2f0f9646decdcad4c11b41428eec1ed25f2a86d43bb04f95726bfbd98ea34 + ca091b7adbabd0e28f17fa0345b89542d23c3530554987508a23641bd4f9e52962b0 + bee3ac9ffe005322d26a39941c5847774300411c69635f96903e8d593530908bd92a + 4fa6a2d52f88073a647a4b3894b7e4ebb80699e60227397bfa93f41b1c97e107b632 + f68e70409372ead2f072c11cf99be4486fcbf763dde28ee156db26cd358a69fcb796 + 44f1f2fcc166f41a4c80f5851ee08be051f14b601418d6e56e61733b9b210c6bef17 + edac121a754d19b9bc + inv = 80682c48982407b489d53d1261b19ec8627d02b8cda5336750b8cee332ae26 + 0de57b02d72609c1e0e9f28e2040fc65b6f02d56dbd6aa9af8fde656f70495dfb723 + ba01173d4707a12fddac628ca29f3e32340bd8f7ddb557cf819f6b01e445ad96f874 + ba235584ee71f6581f62d4f43bf03f910f6510deb85e8ef06c7f09d9794a008be7ff + 2529f0ebb69decef646387dc767b74939265fec0223aa6d84d2a8a1cc912d5ca25b4 + e144ab8f6ba054b54910176d5737a2cff011da431bd5f2a0d2d66b9e70b39f4b050e + 45c0d9c16f02deda9ddf2d00f3e4b01037d7029cd49c2d46a8e1fc2c0c17520af1f4 + b5e25ba396afc4cd60c494a4c426448b35b49635b337cfb08e7c22a39b256dd032c0 + 0adddafb51a627f99a0e1704170ac1f1912e49d9db10ec04c19c58f420212973e0cb + 329524223a6aa56c7937c5dffdb5d966b6cd4cbc26f3201dd25c80960a1a111b3294 + 7bb78973d269fac7f5186530930ed19f68507540eed9e1bab8b00f00d8ca09b3f099 + aae46180e04e3584bd7ca054df18a1504b89d1d1675d0966c4ae1407be325cdf623c + f13ff13e4a28b594d59e3eadbadf6136eee7a59d6a444c9eb4e2198e8a974f27a39e + b63af2c9af3870488b8adaad444674f512133ad80b9220e09158521614f1faadfe85 + 05ef57b7df6813048603f0dd04f4280177a11380fbfc861dbcbd7418d62155248dad + 5fdec0991f + blinded_msg = 982790826556aabe6004467671a864397eea3b95740e9a11c8b80b + 99ee0cf4dbc50af860bda81b601a2eceaa6943ef104f13325ad0be2e37f42030b312 + 0e87cfee8cfe59cde1acfb25485a43275ebe777292e2518181ae531e596f988ff16f + 458daa5a42408939cbe60e7271391a21657276427d195bee6a20054101d4ceb892ec + dea402ea1a866acf0e451a3336f07e7589330d96c3883fd5bc1a829a715b618b74a8 + 6b2a898764246ad081d4c9f1edb8ab5077e315fde2417ec2dd33cad93e120340b49b + e89c18a63e62c6bb289037283d3bf18608be11ee4c823c710b0c6b89235fed3f03a7 + b96ddd25a8f54f20dac37ce8905093ad8e066810f354fb1773236e3d3788ba755de2 + c9bce8d340078bb1831ddc7314a5018673427ced65cb356281aae08b5e6636f3eb24 + 17e09d6ae476a9abcc410bc8c90813d0740e39ae75efae4c02eed49dbb7aa51258bb + 71197445d17a6029bf566ba6b36282173af2c42e9b9631366f22eb6a19ef1d92bd3c + e0631d3a7fb3288195b0ba380a3828d5411cefd5eba83e52198c001ac9946a333a33 + d89d4d235fc833239d59837f04eaf065e9563659b00c7624a6263b727d8f2c07959b + a2bb592e7ff251b8f09c85995fd2e4474e743586576b518230986b6076b762ae7708 + 8a37e4bffd2ef41ae68d6d4e79205290b4f76c42ef039638c41cdc6fe8af9b429c0d + ee45b2942e3861da2a + blind_sig = 362ef369f9b8c1487e285514702a7cd6fe03e4a2fb854881f3d3f986 + b7742a0c9bfab6562a6cd5ed71c574af67d7e77e71b33420c08ebb0ff37886b85829 + 7f9562fc366066c6d8e77bad1918b04756ba03f5c385d44f06759daf1b7a38b2a642 + 48dee95d0e3886c8afa1f74afd8ac3c56520d0f3fd206df8e0d257312756803b09a7 + 9d0cc38112592c3aec32de5a9bc3284c5a0a2d0808b102deafa5cc60f04e3d71c028 + 4cba04f17f88aa8e07d5544fe0265807d515877f79d30ed26d522b9d9c56597647b0 + dbca5a69d6418f8d1b51481723f272c2a3d48f6f4fd6beeac3576c3edb00e8779964 + 548aeab8e004c7c4f8ef9cb6e680e2d2d49792004bb3e6974fa48f241a361ca449c0 + 2bd4c0ad4e66252c55e656f16049908efe59acbafa1171895dfac64d909808e54204 + 69d622c7253ec1de7522b41634d383bf8786bf881cbf1561627f1e62b2d93300ec30 + ec0f5f0ab32036fce068bc76b0b0c6452079537f8d7f8dcee4b42bbf2d9ad7499d38 + 35cd93cfc7e8ebea3554ab5241e181e5d73241b7bebf0a281b63594a35f4993e2b41 + 6d60db966b58b648cfcba2c4bee4c2830aae4a70ff55012480298f549c13b1b26842 + 77bca12f592471b8a99285174f1c0ebb38fc80e74a10b3f02ec3e6682ba873f7ff0e + 1e79718b470927c74ed754d4f7c3d9a55e22246e829cdb5a1c6fb2a0a6c896df3030 + 63c918bcf5eb0017 + sig = 4454b6983ff01cb28545329f394936efa42ed231e15efbc025fdaca00277ac + f0c8e00e3d8b0ecebd35b057b8ebfc14e1a7097368a4abd20b555894ccef3d1b9528 + c6bcbda6b95376bef230d0f1feff0c1064c62c60a7ae7431d1fdfa43a81eed9235e3 + 63e1ffa0b2797aba6aad6082fcd285e14fc8b71de6b9c87cb4059c7dc1e96ae1e637 + 95a1e9af86b9073d1d848aef3eca8a03421bcd116572456b53bcfd4dabb0a9691f1f + abda3ed0ce357aee2cfee5b1a0eb226f69716d4e011d96eede5e38a9acb531a64336 + a0d5b0bae3ab085b658692579a376740ff6ce69e89b06f360520b864e33d82d029c8 + 08248a19e18e31f0ecd16fac5cd4870f8d3ebc1c32c718124152dc905672ab0b7af4 + 8bf7d1ac1ff7b9c742549c91275ab105458ae37621757add83482bbcf779e777bbd6 + 1126e93686635d4766aedf5103cf7978f3856ccac9e28d21a850dbb03c811128616d + 315d717be1c2b6254f8509acae862042c034530329ce15ca2e2f6b1f5fd59272746e + 3918c748c0eb810bf76884fa10fcf749326bbfaa5ba285a0186a22e4f628dbf178d3 + bb5dc7e165ca73f6a55ecc14c4f5a26c4693ce5da032264cbec319b12ddb9787d0ef + a4fcf1e5ccee35ad85ecd453182df9ed735893f830b570faae8be0f6fe2e571a4e0d + 927cba4debd368d3b4fca33ec6251897a137cf75474a32ac8256df5e5ffa518b88b4 + 3fb6f63a24 + +Acknowledgments + + We would like to thank Bjoern Tackmann, who provided an editorial and + security review of this document. + +Authors' Addresses + + Frank Denis + Fastly Inc. + Email: fd@00f.net + + + Frederic Jacobs + Apple Inc. + Email: frederic.jacobs@apple.com + + + Christopher A. Wood + Cloudflare + Email: caw@heapingbits.net |