RFC 9474 - RSA Blind Signatures 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc9474.html
タイトル : RFC 9474 - RSA Blind Signatures
翻訳編集 : 自動生成(GPT)

[要約] RFC 9474はRSAブラインド署名に関する技術仕様を定めた文書です。この技術は、送信者がメッセージの内容を知らずに署名を行うことを可能にし、プライバシー保護や匿名認証システムに利用されます。主に電子投票やデジタルキャッシュシステムなど、ユーザーの匿名性を保ちつつ認証を行いたい場面で活用されます。

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.

この文書は、RSAベースのブラインド署名プロトコルを指定しています。RSAブラインド署名は、Chaumによって最初に導入され、追跡不可能な支払いのために使用されました。このプロトコルから出力される署名は、RSA-PSS署名として検証することができます。

This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.

この文書は、IRTFのCrypto Forum Research Group（CFRG）の成果です。

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.

この文書はInternet Research Task Force (IRTF) の製品です。IRTF はインターネット関連の研究開発活動の結果を公表しています。これらの結果は展開に適していないかもしれません。この RFC は、Internet Research Task Force (IRTF) の Crypto Forum Research Group のコンセンサスを表しています。IRSG によって公表が承認された文書は、インターネット標準のいかなるレベルの候補にもなりません。RFC 7841 のセクション 2 を参照してください。

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.

このドキュメントの現在の状況、誤り訂正、フィードバックの方法についての情報は、https://www.rfc-editor.org/info/rfc9474 で入手できます。

Copyright Notice

著作権表示

著作権（c）2023 IETF Trustおよび文書の著者として特定された個人。全著作権所有。

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.

この文書は、この文書の公開日に有効なBCP 78およびIETF文書に関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。これらの文書を注意深く確認してください。この文書に関するあなたの権利と制限が記載されています。

   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

1. はじめに

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

Chaum氏による追跡不可能な支払いのためのデジタルキャッシュシステムの文脈で最初に導入されたRSAブラインド署名は、プライバシー保護デジタル支払いから認証メカニズムまで幅広い用途があることがわかりました。

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.

最近、盲署名に対する関心が高まっており、検証可能な忘却性擬似乱数関数（VOPRF）[VOPRF]を使用するアプリケーションの運用上の欠点に対処するために成長しています。具体的には、VOPRFは必ずしも公開検証可能ではなく、検証者がVOPRFの秘密鍵にアクセスする必要があるため、VOPRFプロトコルの出力が特定の入力に対して有効であることを検証することができます。この制限は、検証を行うエンティティに秘密鍵を配布したくない場合に、展開を複雑にします。さらに、秘密鍵をハードウェアセキュリティモジュールに保持している場合、鍵に対する操作の数が、検証に公開鍵のみが必要なスキームと比較して倍増します。

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.

逆に、デジタル署名は公開検証可能であり、検証には秘密鍵へのアクセスが必要ありません。さらに、[JKK14]は、メッセージと署名のペアをハッシュすることによってランダムオラクルモデルでVOPRFを実現できることを示しています。

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.

この文書は、(1) RSA-PSSエンコーディングを使用してRSAブラインド署名を計算するためのプロトコルと、(2) このプロトコルのためのバリアントファミリー（セクション5）であるRSABSSA（RSA Blind Signature with Appendix）を指定しています。展開を容易にするために、結果の（ブラインド解除された）署名が標準のRSA-PSSライブラリで検証できるように定義されています。

This document represents the consensus of the Crypto Forum Research Group (CFRG). It is not an IETF product and is not a standard.

この文書はCrypto Forum Research Group (CFRG) の合意を表しています。これはIETFの製品ではなく、標準でもありません。

2. Requirements Notation

2. 要件記法

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.

この文書におけるキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、全て大文字で表記されている場合に限り、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されるべきです。

3. Notation

The following terms, which describe different protocol operations, are used throughout this document:

この文書全体で使用されている、異なるプロトコル操作を説明する以下の用語：

bytes_to_int and int_to_bytes:

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

バイト文字列を非負の整数に変換およびその逆を行います。bytes_to_intおよびint_to_bytesは、それぞれOS2IPおよびI2OSPとして実装されています。これらの関数はビッグエンディアンバイト順でバイト文字列上で動作することに注意してください。

random_integer_uniform(M, N):

Generate a random, uniformly distributed integer R between M inclusive and N exclusive, i.e., M <= R < N.

M以上N未満の範囲で一様分布の整数Rを生成してください。

bit_len(n):

この文は特定の意味を持たないため、そのまま出力します。

Compute the minimum number of bits needed to represent the positive integer n.

正の整数nを表すのに必要な最小ビット数を計算してください。

inverse_mod(x, n):

逆モジュラ逆(x, n):

Compute the multiplicative inverse of x mod n or fail if x and n are not co-prime.

xとnが互いに素でない場合は、x mod nの乗法逆数を計算するか、失敗します。

is_coprime(x, n):

Return true if x and n are co-prime, and false otherwise.

xとnが互いに素であればtrueを返し、そうでなければfalseを返します。

len(s):

The length of a byte string, in bytes.

バイト文字列の長さ（バイト単位）。

random(n):

ランダム(n):

Generate n random bytes using a cryptographically secure random number generator.

暗号学的に安全な乱数生成器を使用して、n個のランダムなバイトを生成してください。

concat(x0, ..., xN):

Concatenation of byte strings. For example, concat(0x01, 0x0203, 0x040506) = 0x010203040506.

バイト文字列の連結。例えば、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.

バイト文字列 x のオフセット i から j までのバイトを返します。例えば、slice(0x010203040506, 1, 5) = 0x0203040506。

4. Blind Signature Protocol

4. 盲署名プロトコル

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.

RSA Blind Signature Protocolは、クライアントとサーバーの間で行われる2者間のプロトコルで、彼らはsig = Sign(sk, input_msg)を計算するためにやり取りします。ここで、input_msg = Prepare(msg)は、クライアントが提供するプライベートメッセージmsgの準備されたバージョンであり、skはサーバーが提供するプライベート署名キーです。このプロトコルでskが生成され、どのように使用されるかの詳細については、セクション6.2を参照してください。このプロトコルの完了時、サーバーは何も学習しませんが、クライアントはsigを学習します。特に、これはサーバーがmsgやinput_msgについて何も学習せず、クライアントが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.

プロトコルは、Prepare、Blind、BlindSign、Finalizeの4つの機能で構成され、クライアントとサーバーの間で1ラウンドのやり取りが必要です。msgをクライアントのプライベート入力メッセージとし、(sk、pk)をサーバーの秘密鍵と公開鍵のペアとします。

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:

クライアントはその後、blinded_msgをサーバーに送信し、サーバーはそのメッセージを処理するために計算します。

   blind_sig = BlindSign(sk, blinded_msg)

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

サーバーはその後、blind_sigをクライアントに送信し、クライアントは次の手順を実行してプロトコルを完了します。

   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.

プロトコルの出力はinput_msgとsigです。完了時、正確性を確保するために、クライアントは[RFC8017]のセクション8.1.2で定義されたRSASSA-PSS-VERIFYルーチンを呼び出して、サーバーの公開鍵pkを使用して準備されたメッセージinput_msg上の署名sigを検証できる必要があります。Finalize関数は、このチェックを行い、署名を返す前に行います。このプロトコルを通じて生成された署名を検証する詳細については、セクション4.5を参照してください。

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.

このセクションの残りでは、このプロトコルで使用されるPrepare、Blind、BlindSign、およびFinalize関数を指定します。

4.1. Prepare

4.1. 準備

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

メッセージの準備は、署名および検証されるメッセージがブラインド署名プロトコルに入力されるためのプロセスを示すPrepare関数によって示されます。準備関数には2つのタイプがあります：アイデンティティ準備関数とランダム化された準備関数。アイデンティティ準備関数は、変換せずに入力メッセージを返します、つまり、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)で示し、メッセージmsgを入力として受け取り、ランダム化されたメッセージinput_msgを生成します。その実装は以下に示されています。

   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

4.2. 盲目

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.

Blind 関数は入力メッセージをエンコードし、サーバーの公開鍵でブラインドします。サーバーに送信するためのブラインドされたメッセージをバイト文字列として出力し、対応する逆数（整数）も出力します。RSAVP1 および EMSA-PSS-ENCODE はそれぞれ[RFC8017]のセクション5.2.2および9.1.1で定義されています。

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.

もしこの関数が「blinding error」エラーで失敗した場合、実装は関数をもう一度試すべきです。連続して1つ以上のこのようなエラーが発生する確率は無視できるほど小さいです。この関数はまた「invalid input」エラーで失敗する可能性があり、これは入力の1つ（おそらく公開鍵）が無効であることを示します。実装はこの関数を再度呼び出す前に公開鍵を更新すべきです。このようなエラーの取り扱いについての詳細はセクション6.1を参照してください。

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.

この関数はRSAVP1を呼び出しますが、RSAVP1は無効な入力に対してオプションのエラーをスローするように定義されています。ただし、RSAVP1の呼び出し方に基づいてこのエラーは発生しないため、このエラーは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.

盲目化因子 r は一様分布からランダムに選択する必要があります。通常、これは拒否サンプリングを使用して行われます。

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は、クライアントのブラインドされたメッセージ入力に対してRSAの秘密鍵操作を実行し、出力をバイト文字列としてエンコードして返します。RSASP1は[RFC8017]のセクション5.2.1で定義されています。

   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

4.4. 最終決定

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はサーバーの応答を検証し、メッセージをアンブラインドして署名を生成し、正しさを検証し、成功した場合に署名を出力します。この関数は、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

4.5. 検証

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.

セクション4に記載されているように、プロトコルの出力は準備されたメッセージinput_msgと署名sigです。アプリケーションが利用するメッセージはmsgであり、input_msgはこれから派生します。クライアントは、サーバーの公開鍵pkを用いてmsgの署名を検証し、[RFC8017]のセクション8.1.2で定義されたRSASSA-PSS-VERIFYルーチンを(n, e)をpk、Mをinput_msg、Sを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.

検証とアプリケーションが消費するメッセージは、使用される準備関数に依存します。特に、PrepareIdentity関数が使用される場合、アプリケーションメッセージはinput_msgです。一方、PrepareRandomize関数が使用される場合、アプリケーションメッセージはslice(input_msg, 32, len(input_msg))であり、つまり、メッセージランダマイザー接頭辞が削除された準備されたメッセージです。

5. RSABSSA Variants

5. RSABSSAバリアント

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の異なる名前付きバリアントを定義します。各バリアントは、[RFC8017]のセクション9.1.1で定義されているEMSA-PSSオプションのHash、MGF、sLen、および適用されるメッセージ準備関数のタイプ（セクション4.1で説明されている）を指定します。各バリアントは、[RFC8017]の付録B.2.1で定義されているマスク生成関数1（MGF1）を使用します。将来の仕様では、必要に応じて他のバリアントを導入できます。名前付きバリアントは以下の通りです：

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

この名前付きの変種は、EMSA-PSSハッシュオプションとしてSHA-384を使用し、EMSA-PSS MGFオプションとしてMGF1 with SHA-384を使用し、EMSA-PSS sLenオプションとして48を使用します（48バイトのソルト長）；また、ランダム化準備関数（PrepareRandomize）も使用します。

RSABSSA-SHA384-PSSZERO-Randomized:

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

この名前付きの変種は、EMSA-PSSハッシュオプションとしてSHA-384を使用し、EMSA-PSS MGFオプションとしてSHA-384を使用し、EMSA-PSS sLenオプションとして0を使用します（0バイトのソルト長）；また、ランダム化準備関数（PrepareRandomize）も使用します。

RSABSSA-SHA384-PSS-Deterministic:

この名前付きの変種は、EMSA-PSSハッシュオプションとしてSHA-384を使用し、EMSA-PSS MGFオプションとしてSHA-384を使用し、EMSA-PSS sLenオプションとして48を使用します（48バイトのソルト長）；また、識別準備関数（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.

この名前付きのバリアントは、EMSA-PSSハッシュオプションとしてSHA-384を使用し、EMSA-PSS MGFオプションとしてSHA-384を使用し、EMSA-PSS sLenオプションとして0（0バイトのソルト長）を使用します。また、アイデンティティ準備関数（PrepareIdentity）も使用します。これは、クライアントの入力メッセージmsgに対して決定論的な署名を生成する唯一のバリアントです。

The RECOMMENDED variants are RSABSSA-SHA384-PSS-Randomized or RSABSSA-SHA384-PSSZERO-Randomized.

推奨されるバリアントはRSABSSA-SHA384-PSS-Randomizedまたは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.

名前付きの変種をすべて互換性を持って使用することはできません。特に、高エントロピーの入力メッセージを提供するアプリケーションは、追加のメッセージランダム化がセキュリティ上の利点を提供しないため、ランダム化されたメッセージの準備を行わずに名前付きの変種を安全に使用できます。詳細については、[Lys22]とセクション7.3を参照してください。その他のすべてのアプリケーションにおいて、ランダム化された準備関数を使用する変種は、悪意のある署名者からクライアントを保護します。ランダム化されたメッセージを受け入れる検証者は、処理の前にメッセージの署名部分からランダムな要素を削除する必要があります。

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.

決定論的署名を必要とするアプリケーションは、RSABSSA-SHA384-PSSZERO-Deterministicバリアントを使用できますが、入力メッセージが高いエントロピーを持っている場合に限ります。RSABSSA-SHA384-PSSZERO-Deterministicを使用するアプリケーションは、セキュリティの影響を慎重に分析するべきであり、第7.3節で説明されているように、敵対的に生成された署名者キーの可能性を考慮すべきです。アプリケーションが決定論的署名またはランダム化された署名が必要かどうかが明確でない場合、アプリケーションはランダム化されたメッセージ準備を行うバリアントのいずれかを使用するべきです。

6. Implementation and Usage Considerations

6. 実装と使用に関する考慮事項

This section documents considerations for interfaces to implementations of the protocol defined in this document. This includes error handling and API considerations.

このセクションは、この文書で定義されたプロトコルの実装へのインターフェースに関する考慮事項を文書化しています。これにはエラー処理やAPIに関する考慮事項が含まれます。

6.1. Errors

6.1. エラー

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.

セクション4で指定された高レベルの関数はすべて失敗する可能性があります。この仕様全体で生成される明示的なエラーと、それぞれのエラーにつながる条件は、Blind、BlindSign、およびFinalizeの定義にリストされています。これらのエラーは、実装者のためのガイドとして意図されています。実装がメモリ不足になるなど、実装が発生させる可能性のあるすべてのエラーの網羅的なリストではありません。

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.

さらに、実装は必要に応じてエラーを処理できます。該当する場合、この文書はプロトコルで生成される明示的なエラーの処理方法についてのガイダンスを提供します。たとえば、クライアントがサーバーの公開鍵の素因数を生成した場合には、「ブラインドエラー」がBlindで生成されます。セクション4.2では、このエラーが発生した場合には、実装はBlind関数を再試行するべきであると示されていますが、実装はこの例外的なイベントを異なる方法で処理することもできます。例えば、サーバーに鍵が因数分解されたことを通知するなどです。

6.2. Signing Key Generation and Usage

6.2. 署名キーの生成と使用

The RECOMMENDED method for generating the server signing key pair is as specified in FIPS 186-5 [DSS].

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.

サーバー署名キーは、RSABSSA以外のプロトコルで再利用してはいけません。さらに、サーバー署名キーは、異なるRSABSSAエンコーディングオプションで再利用してはいけません。つまり、サーバーが2つの異なるエンコーディングオプションをサポートしている場合、それぞれのオプションに対して異なるキーペアを持っている必要があります。

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

サーバーの公開鍵がX.509証明書に含まれている場合、id-RSASSA-PSS OID [RFC5756] を使用する必要があります。rsaEncryption OID [RFC5280] を使用してはいけません。

7. Security Considerations

7. セキュリティに関する考慮事項

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.

Lysyanskayaは、ランダムオラクルモデルにおいて、one-more-RSA仮定の下でRSABSSAの変種の一つの偽造多項式セキュリティを証明しました。これは、敵対者がサーバー（署名者）としてクライアントとしてn回だけやり取りした後に、異なるすべてのメッセージを持つn+1個の有効なメッセージと署名のタプルを出力することができないことを意味します。このnは、プロトコルのセキュリティパラメータに対して多項式である必要があります。Lysyanskayaはまた、PrepareRandomize関数を使用するRSABSSAの変種が盲目性を達成することを証明しました。盲目性とは、悪意のある署名者がプロトコルの実行後にクライアントの入力と出力について何も学習しないことを意味します。ただし、PrepareIdentity関数を使用するRSABSSAの変種に対して盲目性が保持されるためには、メッセージ入力に関する追加の仮定が必要です。これについては、その結果に関する詳細な議論については、セクション7.3を参照してください。

7.1. Timing Side Channels and Fault Attacks

7.1. タイミング側面チャネルとフォルト攻撃

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.

BlindSignは、RSAの秘密鍵操作を適用するためのリモート手続き呼び出しです。そのため、サイドチャネルへの耐性は、秘密鍵の露出から保護するために極めて重要です[RemoteTimingAttacks]。実装は、[TimingAttacks]のセクション10で説明されているように、RSAブラインディングなどのサイドチャネル攻撃緩和の形式を実装するべきです。このような緩和策を適用しないと、秘密署名鍵が漏洩するサイドチャネル攻撃が発生する可能性があります。

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.

さらに、サーバーがプロトコルを開始しないと仮定しているため、PrepareおよびBlind操作が行われるタイミングを知らないと仮定しています。もし違う場合、Prepareおよび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.

[FAULTS]は、タイミング側面のチャネルを超えて、秘密の署名鍵を漏洩させる可能性のあるフォルト攻撃に対する保護策の重要性を説明しています。これらの保護策には、実装が署名時の秘密鍵操作の結果が正しいことを確認する必要があります。つまり、s = RSASP1(sk, m) として与えられた場合、m = RSAVP1(pk, s) を検証する必要があります。これは BlindSign によって必要とされています。この（または同等の）保護策を適用することは、中国剰余定理に基づいていない実装にとっても、フォルト攻撃を緩和するために必要です。

7.2. Message Robustness

7.2. メッセージの信頼性

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.

盲目署名プロトコルの重要な特性の1つは、署名者が署名されるメッセージについて何も知らないことです。いくつかの状況では、これが任意の署名オラクルに関する懸念を引き起こす可能性があります。盲目署名プロトコルを使用するアプリケーションは、そのようなオラクルがクロスプロトコル攻撃を引き起こさないように注意を払う必要があります。RSABSSAに使用される署名キーが他のプロトコルとは異なることを確認することで、そのようなクロスプロトコル攻撃を防ぐことができます。

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

7.3. メッセージエントロピー

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.

[Lys22]で議論されているように、悪意のある署名者は無効な公開鍵を構築し、それを使用して低エントロピーの入力メッセージに関する情報を取得することができます。一部の無効な公開鍵は、プロトコルを実行する際に有効な署名を生成しない場合があります（たとえば、署名が検証に失敗するため）。ただし、攻撃者がクライアントを強制してこれらの無効な公開鍵を低エントロピーの入力と共に使用させることができれば、プロトコルが完了する前にクライアントの入力に関する情報を取得することができます。

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.

(1) クライアントは、署名者の公開鍵が正直に生成されたことを証明しています。[GRSB19]は、公開鍵に関するさまざまな文についての（非対話的な）正直な検証者ゼロ知識証明を示しています。

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

(2) 入力メッセージには、署名者が推測できない値が含まれています。つまり、クライアントは、署名者が署名キーを選択する前に利用できなかった高エントロピーのコンポーネントを追加しました。

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.

PrepareRandomize関数を使用する名前付きの変種--RSABSSA-SHA384-PSS-RandomizedおよびRSABSSA-SHA384-PSSZERO-Randomized--は、条件（2）を満たすために各メッセージに新鮮なエントロピーを明示的に注入します。したがって、これらの変種はすべてのアプリケーションユースケースに安全です。一方、PrepareIdentity関数を使用する名前付きの変種は新鮮なエントロピーを注入せず、したがって低エントロピーの入力で問題が発生する可能性があります。

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

7.4. ランダム性の生成

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.

プロトコル内のすべてのランダム値、ソルト、メッセージランダマイザープレフィックス（msg_prefix; 付録Aを参照）、およびBlind内のランダムブラインド値は、暗号的に安全な乱数生成器[RFC4086]から生成する必要があります。これらの値がランダムに生成されていないか、または悪意を持って構築されている場合、署名されたメッセージに存在しない情報をエンコードする可能性があります。たとえば、PSSソルトは、クライアントのローカルIPアドレスをエンコードするように悪意を持って構築されているかもしれません。その結果、実装ではクライアントにこれらの値を直接提供することを許可すべきではありません。

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

7.5. キー置換攻撃

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.

RSAは、鍵の置換攻撃を許容することでよく知られており、攻撃者が異なる鍵のペア（sk、pk）で生成されたある（メッセージ、署名）ペアを検証する（skA、pkA）鍵ペアを生成することができます。これは、攻撃者があるコンテキストでの（メッセージ、署名）ペアを別のコンテキストで使用する可能性があることを意味します。署名を検証するエンティティは、（メッセージ、署名）ペアが期待される発行者の有効な公開鍵で検証されることを確認するために注意を払う必要があります。

7.6. Alternative RSA Encoding Functions

7.6. 代替RSAエンコーディング関数

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

この文書では、いくつかの理由から[RFC8017]で指定されたPSSエンコーディングが使用されています。まず、最近の標準仕様、TLS 1.3 [RFC8446]、X.509 [RFC4055]、そしてPKCS＃1自体でも推奨されています。[RFC8017]によると、「RSASSA-PKCS1-v1_5に対する攻撃は知られていませんが、信頼性を高めるために、新しいアプリケーションではRSASSA-PSSが必要です。」RSA-PSSはRSASSA-PKCS1-v1_5エンコーディングよりも複雑ですが、RSA-PSSサポートの普及がこの文書の設計上の決定に影響を与えました。PKCS＃1 v1.5はデジタル署名に対する同等のセキュリティ特性を持っているにもかかわらず、[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.

Full Domain Hash（FDH）エンコーディング[RSA-FDH]も可能です。このバリアントは、PSS[KK18]と同等のセキュリティを提供します。ただし、FDHは標準化されておらず、関連技術で広く使用されていません。さらに、FDHは決定論的であり、一方、PSSは決定論的および確率的なエンコーディングをサポートしています。

7.7. Post-Quantum Readiness

7.7. ポスト量子準備

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.

この文書で指定されているブラインド署名プロトコルは、RSAに基づいているため、ポスト量子準備ができていません。Shorの多項式時間の因数分解アルゴリズムが容易に適用されます。

8. IANA Considerations

8. IANAの考慮事項

This document has no IANA actions.

この文書にはIANAのアクションはありません。

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

   [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

9.2. 参考引用

   [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

付録A. テストベクトル

This section includes test vectors for the blind signature protocol defined in Section 4. The following parameters are specified for each test vector:

このセクションには、セクション4で定義されたブラインド署名プロトコルのテストベクトルが含まれています。各テストベクトルには、以下のパラメータが指定されています。

p, q, n, e, d:

RSA private and public key (sk and pk) parameters, each encoded as a hexadecimal string.

RSAの秘密鍵と公開鍵（skとpk）のパラメーターは、それぞれ16進数の文字列としてエンコードされています。

msg:

Input message being signed, encoded as a hexadecimal string. The hash is computed using SHA-384.

署名される入力メッセージは、16進数文字列としてエンコードされます。ハッシュはSHA-384を使用して計算されます。

msg_prefix:

Message randomizer prefix, encoded as a hexadecimal string. This is only present for variants that use the randomization preparation function.

ランダム化準備関数を使用するバリアントにのみ存在する、16進数文字列としてエンコードされたメッセージランダマイザーのプレフィックスです。

prepared_msg:

The message actually signed. If the variant does not use the randomization preparation function, this is equal to msg.

実際に署名されたメッセージです。変種がランダム化準備機能を使用していない場合、これはmsgと同じです。

salt:

ソルト:

Randomly generated salt used when computing the signature. The length is either 48 or 0 bytes.

署名を計算する際に使用されるランダムに生成されたソルト。長さは48バイトまたは0バイトのいずれかです。

encoded_msg:

EMSA-PSS encoded message. The mask generation function is MGF1 with SHA-384.

EMSA-PSSエンコードされたメッセージ。マスク生成関数はSHA-384を用いたMGF1です。

inv:

The message blinding inverse, encoded as a hexadecimal string.

メッセージは逆に暗号化され、16進数の文字列としてエンコードされています。

blinded_msg, blind_sig:

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

計算中に交換されるプロトコル値は、16進数文字列としてエンコードされます。

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

A.2. RSABSSA-SHA384-PSSZERO-ランダム化されたテストベクトル

   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.

この文書の編集とセキュリティレビューを提供してくれたBjoern Tackmannに感謝したいと思います。

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

RFC 9474 - RSA Blind Signatures 日本語訳

RSA Blind Signatures

RSA Blind Signatures

Abstract

概要

Status of This Memo

本文書の位置付け

Copyright Notice

著作権表示

Table of Contents

目次

1. Introduction

1. はじめに

2. Requirements Notation

2. 要件記法

3. Notation

3. Notation

4. Blind Signature Protocol

4. 盲署名プロトコル

4.1. Prepare

4.1. 準備

4.2. Blind

4.2. 盲目

4.3. BlindSign

4.3. BlindSign

4.4. Finalize

4.4. 最終決定

4.5. Verification

4.5. 検証

5. RSABSSA Variants

5. RSABSSAバリアント

6. Implementation and Usage Considerations

6. 実装と使用に関する考慮事項

6.1. Errors

6.1. エラー

6.2. Signing Key Generation and Usage

6.2. 署名キーの生成と使用

7. Security Considerations

7. セキュリティに関する考慮事項

7.1. Timing Side Channels and Fault Attacks

7.1. タイミング側面チャネルとフォルト攻撃

7.2. Message Robustness

7.2. メッセージの信頼性

7.3. Message Entropy

7.3. メッセージエントロピー

7.4. Randomness Generation

7.4. ランダム性の生成

7.5. Key Substitution Attacks

7.5. キー置換攻撃

7.6. Alternative RSA Encoding Functions

7.6. 代替RSAエンコーディング関数

7.7. Post-Quantum Readiness

7.7. ポスト量子準備

8. IANA Considerations

8. IANAの考慮事項

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

9.2. Informative References

9.2. 参考引用

Appendix A. Test Vectors

付録A. テストベクトル

A.1. RSABSSA-SHA384-PSS-Randomized Test Vector

A.1. RSABSSA-SHA384-PSS-Randomized Test Vector

A.2. RSABSSA-SHA384-PSSZERO-Randomized Test Vector

A.2. RSABSSA-SHA384-PSSZERO-ランダム化されたテストベクトル

A.3. RSABSSA-SHA384-PSS-Deterministic Test Vector

A.3. RSABSSA-SHA384-PSS-Deterministic Test Vector

A.4. RSABSSA-SHA384-PSSZERO-Deterministic Test Vector

A.4. RSABSSA-SHA384-PSSZERO-Deterministic Test Vector

Acknowledgments

謝辞

Authors' Addresses

著者の住所