diff --git a/wolfSSL/src-ja/appendix04.md b/wolfSSL/src-ja/appendix04.md index 4c6a7a6c..41e88905 100644 --- a/wolfSSL/src-ja/appendix04.md +++ b/wolfSSL/src-ja/appendix04.md @@ -9,13 +9,13 @@ -wolfSSL(以前のCyassl)が埋め込まれたSSLライブラリは、SSL 3.0、TLS 1.0、TLS 1.1、TLS 1.2、およびTLS 1.3プロトコルを実装しています。TLS 1.3は現在、標準の最も安全で最新のバージョンです。wolfSSLは、数年間不安定であるという事実により、SSL 2.0をサポートしていません。 +組み込み向けSSL/TLSライブラリであるwolfSSL(旧称：Cyassl)は、SSL 3.0、TLS 1.0、TLS 1.1、TLS 1.2、およびTLS 1.3プロトコルを実装しています。TLS 1.3は現在、標準化されている最も安全な最新バージョンです。wolfSSLは、数年間不安定であるという事実により、SSL 2.0をサポートしていません。 -WOLFSSLのTLSプロトコルは、[RFC 5246 (https://tools.ietf.org/html/rfc5246).](https://tools.ietf.org/html/rfc5246)で定義されているとおりに実装されています.SSL には、メッセージ層とハンドシェーク層の 2 つのレコード層プロトコルが存在します。ハンドシェイク メッセージは、共通の暗号スイートのネゴシエーション、シークレットの作成、および安全な接続の有効化に使用されます。メッセージ レイヤーはハンドシェイク レイヤーをカプセル化すると同時に、アラート処理とアプリケーション データ転送もサポートします。 +wolfSSLのTLSプロトコルは、[RFC 5246 (https://tools.ietf.org/html/rfc5246).](https://tools.ietf.org/html/rfc5246) で定義されているとおりに実装しています.TLSには、メッセージ層とハンドシェーク層の2つのレコード層プロトコルが存在します。ハンドシェイクメッセージは、共通の暗号スイートのネゴシエーション、シークレットの作成、および安全な接続の有効化に使用されます。メッセージレイヤーはハンドシェイクレイヤーをカプセル化すると同時に、アラート処理とアプリケーションデータ転送もサポートします。 -SSLプロトコルが既存のプロトコルにどのように適合するかについての一般的な図は、**図1**に表示されます。SSL は、OSI モデルのトランスポート層とアプリケーション層の間に位置し、任意の数のプロトコル (TCP/IP、Bluetooth などを含む) がトランスポート メディアとして機能します。アプリケーション プロトコルは、SSL (HTTP、FTP、SMTP など) の上に階層化されています。 +SSLプロトコルが既存のプロトコルにどのように適合するかを、**図1**に示します。SSLは、OSIモデルのトランスポート層とアプリケーション層の間に位置し、多くのプロトコル (TCP/IP、Bluetooth などを含む) がトランスポートメディアとして機能します。アプリケーションプロトコルは、SSL (HTTP、FTP、SMTP など) の上に階層化されています。 ![SSL Protocol Diagram](sslprotocol.png "SSL Protocol Diagram") @@ -25,8 +25,8 @@ SSLプロトコルが既存のプロトコルにどのように適合するか ## SSLハンドシェイク - -SSLハンドシェイクには、SSLクライアントとサーバーが構成されているオプションに応じて、いくつかのステップが必須ではありません。以下、**図2**では、SSLハンドシェイクプロセスの簡略図があります。 +SSLハンドシェイクプロセスの簡略を以下の**図2**に示します。 +なお、SSLクライアントとサーバーの構成オプションによってはいくつかのステップは実行されません。 ![SSL Handshake Diagram](sslhandshake.png "SSL Handshake Diagram") @@ -37,10 +37,10 @@ SSLハンドシェイクには、SSLクライアントとサーバーが構成 -SSL (Secure Sockets Layer) と TLS (Transport Security Layer) はどちらも、ネットワーク上で安全な通信を提供する暗号化プロトコルです。 これら 2 つのプロトコル (およびそれぞれのいくつかのバージョン) は、今日、Web ブラウジングから電子メール、インスタント メッセージング、VoIP に至るまで、さまざまなアプリケーションで広く使用されています。各プロトコル、およびそれぞれの基礎となるバージョンは、他とはわずかに異なります。 +SSL (Secure Sockets Layer) と TLS (Transport Security Layer) はどちらも、ネットワーク上で安全な通信を提供する暗号化プロトコルです。 これら2つのプロトコル (および、それぞれのいくつかのバージョン) は、今日、Webブラウジングから電子メール、インスタントメッセージング、VoIP に至るまで、さまざまなアプリケーションで広く使用されています。SSLとTLS、そしてそれぞれに含まれる各バージョン間にはいくつかの違いがあります。 -以下に、異なる SSL および TLS プロトコル バージョンの説明と主な相違点を示します。 各プロトコルの具体的な詳細については、記載されている RFC 仕様を参照してください。 +以下に、SSL および TLS プロトコルの各バージョンについての解説と主な相違点を示します。 各プロトコルの具体的な詳細については、記載されている RFC 仕様を参照してください。 @@ -49,26 +49,26 @@ SSL (Secure Sockets Layer) と TLS (Transport Security Layer) はどちらも、 -このプロトコルは1996年にリリースされましたが、Netscapeによって開発されたSSL 1.0の作成から始まりました。バージョン1.0はリリースされておらず、バージョン2.0には多くのセキュリティ上の欠陥があり、SSL 3.0のリリースにつながりました。SSL 2.0 に対する SSL 3.0 のいくつかの主要な改善点は次のとおりです。 +このプロトコルはNetscapeによって開発されたSSL 1.0から始まり、1996年にリリースされました。バージョン1.0はリリースされておらず、バージョン2.0には多くのセキュリティ上の欠陥があり、SSL 3.0のリリースにつながりました。SSL 2.0 に対する SSL 3.0 のいくつかの主要な改善点は次のとおりです。 * メッセージ層からのデータ転送の分離 -* Export Cipherを使用している場合でも、128ビットのキーイングマテリアルを使用する +* Export Cipherを使用している場合でも、128ビットのキーイングマテリアルを使用 -* クライアントとサーバーが証明書のチェーンを送信する能力により、組織は2つ以上の証明書の証明書階層を使用できるようにします。 +* クライアントとサーバーが証明書のチェーンを送信し、組織は2つ以上の証明書の証明書階層を使用可能に -* 一般化された鍵交換プロトコルを実装し、Diffie-HellmanとFortezzaの鍵交換と非RSA証明書を許可しています。 +* 一般化された鍵交換プロトコルを実装し、Diffie-HellmanとFortezzaの鍵交換と非RSA証明書を許可 -* レコードの圧縮と解凍を可能にする +* レコードの圧縮と解凍を可能に -* 2.0 クライアントが検出されたときに SSL 2.0 にフォールバックする機能 +* 2.0 クライアントが検出されたときに SSL 2.0 にフォールバック @@ -78,23 +78,23 @@ SSL (Secure Sockets Layer) と TLS (Transport Security Layer) はどちらも、 -このプロトコルは1999年1月にRFC 2246で最初に定義されています。このプロトコルは、1999 年 1 月に RFC 2246 で最初に定義されました。これは SSL 3.0 からのアップグレードであり、違いは劇的ではありませんでしたが、SSL 3.0 と TLS 1.0 が相互運用できない程度の変更を含んでいます。SSL 3.0とTLS 1.0の間の大きな違いの一部は次のとおりです。 +このプロトコルは1999年1月にRFC 2246で最初に定義されました。これは SSL 3.0 からのアップグレードであり劇的な違いはありませんが、SSL 3.0 と TLS 1.0 は相互運用できない程度の変更を含んでいます。SSL 3.0とTLS 1.0の間の大きな違いとして、以下が挙げられます。 -* キー導出関数は異なります +* 鍵導出関数の変更 -* Macは異なります-SSL 3.0は初期HMACの変更を使用し、TLS 1.0はHMACを使用します。 +* MACの変更 - SSL 3.0は初期HMACの変更を使用し、TLS 1.0はHMACを使用します。 -* 完了（Finished)メッセージが異なります +* 完了(Finished)メッセージの変更 -* TLSにはより警告があります +* アラートの増加 -* TLSにはDSS/DHサポートが必要です +* DSS/DHサポートの要求 @@ -104,17 +104,17 @@ SSL (Secure Sockets Layer) と TLS (Transport Security Layer) はどちらも、 -このプロトコルは、2006年4月にRFC 4346で定義され、TLS 1.0の更新です。主な変更は次のとおりです。 +このプロトコルは、2006年4月にTLS 1.0の後継としてRFC 4346で定義されました。主な変更点は次のとおりです。 -* 暗黙の初期化ベクトル(IV)は、暗号ブロック連鎖(CBC)攻撃から保護するために明示的なIVに置き換えられます。 +* 暗黙の初期化ベクトル(IV)は、暗号ブロック連鎖(CBC)攻撃から保護するために明示的なIVに置き換えられました。 * パディングエラーの取り扱いは、CBC攻撃から保護するためにdecryption_failedアラートではなくbad_record_macアラートを使用するよう変更されました。 -* IANAレジストリは、プロトコルパラメーター用に定義されています +* IANAレジストリは、プロトコルパラメーター用に定義されました。 * 早期終了によってセッションが再開できなくなることがなくなりました。 @@ -127,7 +127,7 @@ SSL (Secure Sockets Layer) と TLS (Transport Security Layer) はどちらも、 -このプロトコルは、2008 年 8 月に RFC 5246 で定義されました。TLS 1.1 に基づいて、TLS 1.2 には改善された柔軟性が含まれています。主な違いは次のとおりです。 +このプロトコルは、2008 年 8 月に RFC 5246 で定義されました。TLS 1.1 をベースとして、いくつかの改善が行われました。主な相違点は次のとおりです。 @@ -137,25 +137,25 @@ SSL (Secure Sockets Layer) と TLS (Transport Security Layer) はどちらも、 * デジタル署名要素のMD5/SHA-1の組み合わせは、単一のハッシュに置き換えられました。署名された要素には、使用されるハッシュアルゴリズムを明示的に指定するフィールドが含まれます。 -* クライアントとサーバーが受け入れるハッシュおよび署名アルゴリズムを指定する能力にかなりのクリーンアップがありました。 +* クライアントとサーバーが受け入れるハッシュおよび署名アルゴリズムの組み合わせが整理されました。 -* 追加のデータモードを使用した認証された暗号化のためのサポートの追加。 +* 追加のデータモードを使用した、認証された暗号化のためのサポートが追加されました。 * TLS拡張機能の定義とAES暗号スイートがマージされました。 -* EncryptedPremasterSecretバージョン番号の厳しいチェック。 +* EncryptedPremasterSecretバージョン番号が厳しくチェックされるようになりました。 -* 多くの要件が厳しくなりました +* 多くの要件が厳しくなりました。 -* `Verify_data`長さは暗号スイートに依存します +* `Verify_data`の長さは暗号スイートに依存します -* Bleichenbacher/Dlima 攻撃防御の説明がクリーンアップされました。 +* Bleichenbacher/Dlima 攻撃防御の説明が簡潔になりました。 @@ -165,32 +165,32 @@ SSL (Secure Sockets Layer) と TLS (Transport Security Layer) はどちらも、 -このプロトコルは、2018年8月にRFC 8446で定義されています.TLS 1.3には、セキュリティとスピードが向上しました。主な違いは次のとおりです。 +このプロトコルは、2018年8月にRFC 8446で定義されました。主に、セキュリティ性能とスピードが向上しています。主な違いは次のとおりです。 * サポートされている対称アルゴリズムのリストは、すべての従来のアルゴリズムから整理されました。残りのアルゴリズムはすべて、認証タグ付き暗号(AEAD) アルゴリズムを使用します。 -* ゼロ RTT (0-RTT) モードが追加され、一部のセキュリティ 属性を犠牲にすることで、一部のアプリケーション データのための接続時のラウンドトリップが削減されました。 +* ゼロ RTT (0-RTT) モードが追加され、一部のセキュリティ属性を犠牲にすることで、一部のアプリケーションデータのための接続時のラウンドトリップが削減されました。 -* ServerHello の後のすべてのハンドシェイク メッセージが暗号化されるようになりました。 +* ServerHello の後のすべてのハンドシェイクメッセージが暗号化されるようになりました。 * HMACベースの抽出および拡張鍵導出機能(HKDF)がプリミティブとして使用されているため、鍵導出機能が再設計されました。 -* ハンドシェイク ステート マシンが再構築され、一貫性が向上し、余分なメッセージが削除されました。 +* ハンドシェイクステートマシンが再構築され、一貫性が向上し、余分なメッセージが削除されました。 -* ECC は基本仕様になり、新しい署名アルゴリズムが含まれています。各曲線の単一のポイント形式を支持して、ポイント形式のネゴシエーションを削除しました。 +* ECC は基本仕様になり、新しい署名アルゴリズムが含まれるようになりました。各曲線の単一のポイント形式を支持して、ポイント形式のネゴシエーションを削除しました。 -* 圧縮、カスタムDHEグループ、およびDSAが削除されました、RSAパディングは現在PSSを使用します。 +* 圧縮、カスタムDHEグループ、およびDSAが削除されました、RSAパディングはPSSを使用するようになりました。 -* TLS 1.2バージョンネゴシエーション検証メカニズムは、拡張子のバージョンリストを支持して非推奨を受けました。 +* TLS 1.2 バージョンネゴシエーション検証メカニズムは廃止され、拡張機能のバージョンリストが採用されました。 * サーバー側の状態の有無にかかわらず、セッションの再開と、TLS の以前のバージョンの PSK ベースの暗号スイートは、単一の新しい PSK 交換に置き換えられました。 diff --git a/wolfSSL/src-ja/appendix06.md b/wolfSSL/src-ja/appendix06.md index f9cf051c..e9e6ba9d 100644 --- a/wolfSSL/src-ja/appendix06.md +++ b/wolfSSL/src-ja/appendix06.md @@ -168,11 +168,11 @@ wolfSSL(以前のCyassl)エラーコードは`wolfssl/ssl.h`にあります。 -## wolfcryptエラーコード +## wolfCryptエラーコード -WolfCryptエラーコードは`wolfssl/wolfcrypt/error.h`にあります。 +wolfCryptエラーコードは`wolfssl/wolfcrypt/error.h`にあります。 |エラーコード列挙|エラーコード|エラー説明| | --------------- | ---------- | ----------------- | @@ -280,8 +280,8 @@ WolfCryptエラーコードは`wolfssl/wolfcrypt/error.h`にあります。 |`AKID_E` |-225 |権限キー識別子エラー| |`KEYUSAGE_E` |-226 |悪いキー使用率値| |`CERTPOLICIES_E` |-227 |証明書ポリシーの設定エラー| -|`WC_INIT_E` |-228 |wolfcryptは初期化に失敗しました| -|`SIG_VERIFY_E` |-229 |wolfcryptシグネチャーの検証エラー| +|`WC_INIT_E` |-228 |wolfCryptは初期化に失敗しました| +|`SIG_VERIFY_E` |-229 |wolfCryptシグネチャーの検証エラー| |`BAD_PKCS7_SIGNEEDS_CHECKCOND_E` |-230 |悪条件変数演算| |`SIG_TYPE_E` |-231 |署名タイプが有効/利用可能な| |`HASH_TYPE_E` |-232 |ハッシュタイプは有効/利用可能ではありません| @@ -292,7 +292,7 @@ WolfCryptエラーコードは`wolfssl/wolfcrypt/error.h`にあります。 |`ASN_PATHLEN_INV_E` |-238 |ASN CAパスの長さ反転誤差| |`BAD_KEYWRAP_ALG_E` |-239 |KeyWrapのアルゴリズムエラー| |`BAD_KEYWRAP_IV_E` |-240 |復号化されたAESキーラップIV不正| -|`WC_CLEANUP_E` |-241 |wolfcryptのクリーンアップに失敗しました| +|`WC_CLEANUP_E` |-241 |wolfCryptのクリーンアップに失敗しました| |`ECC_CDH_KAT_FIPS_E` |-242 |ECC CDH既知の回答テスト失敗| |`DH_CHECK_PUB_E` |-243 |DH公開キーエラーを確認します| |`BAD_PATH_ERROR` |-244 |Opendirの悪い道| @@ -334,7 +334,7 @@ WolfCryptエラーコードは`wolfssl/wolfcrypt/error.h`にあります。 -アプリケーションをwolfsslで起動して実行するときに一般的に起こるエラーコードがいくつかあります。 +アプリケーションをwolfSSLで起動して実行するときに一般的に起こるエラーコードがいくつかあります。 diff --git a/wolfSSL/src-ja/appendix07.md b/wolfSSL/src-ja/appendix07.md index adf91fcb..364b942a 100644 --- a/wolfSSL/src-ja/appendix07.md +++ b/wolfSSL/src-ja/appendix07.md @@ -26,10 +26,10 @@ wolfSSLチームは、実験的なポスト量子暗号アルゴリズムをwolf -最近、量子コンピューターの開発にはますます多くのリソースが専念しています。そのため、クラウド量子コンピューティングリソースの商業化がすでに始まっています。現在の最新の状態は暗号化に関連する領域にまだありませんが、「まずデータを収集、蓄積し、後に時間をかけて解読を進めていく」などの一部の脅威モデルは、暗号化に関連する量子コンピューターの出現よりも早く準備が必要であることを意味します。 +今日では、量子コンピューターの開発にますます多くのリソースが割かれるようになりました。そのため、クラウド量子コンピューティングリソースの商業化がすでに始まっています。現時点では未だ実用レベルの暗号が解かれた報告はありません。しかし、「あらかじめデータを収集、蓄積し、後に時間をかけて解読を進めていく」といった脅威モデルが存在します。すなわち、暗号の復号に特化した量子コンピューターが出現するよりも早いうちに準備が必要です。 -NISTが、量子コンピューターに対して脆弱になる公開キー暗号アルゴリズムを置き換えるように設計された新しいクラスのアルゴリズムの標準化の道をリードしていることが広く認められています。このパッセージの執筆時点で、NISTはPQC標準化プロセスでの第3ラウンドの完了に近づいており、2022年初頭に標準化されるアルゴリズムを発表します。その後、プロセスにはもう1年かかると予測されています。プロトコルとデータ形式を説明する標準ドキュメントを作成します。その後、FIPSのような規制が開発を開始する可能性があります。 +NISTが、量子コンピューターに対して脆弱になる公開鍵暗号アルゴリズムを置き換えるように設計された新しいクラスのアルゴリズムの標準化を進めています。この章の執筆時点で、NISTはPQC標準化プロセスの第3ラウンドをほぼ完了させており、2022年初頭に標準化されるアルゴリズムを発表する予定です。その後、プロトコルとデータ形式を記述した標準文書を作成するプロセスにはさらに1年かかると予測されています。さらにその後には、FIPSのような規制の策定が開始される可能性があります。 @@ -37,24 +37,24 @@ NISTが、量子コンピューターに対して脆弱になる公開キー暗 -高レベルの観点からは、TLS 1.3接続ごとに、認証と機密性は各接続を保護する2つの主な目標です。認証はECDSAなどのシグネチャスキームを介して維持されます。機密性は、ECDHEなどの重要な確立アルゴリズムによって維持され、その後、対称暗号化アルゴリズムで確立されたキーを使用して通信ストリームを暗号化する。したがって、TLS 1.3プロトコルのセキュリティを3種類の暗号化アルゴリズムに分解することができます。 +大まかに言えば、すべての TLS 1.3 接続において、認証と機密性は各接続を保護する重要な目標です。認証は、ECDSAなどの署名スキームによって維持されます。機密性は、ECDHEなどのキー確立アルゴリズムによって維持され、確立されたキーとAESなどの対称暗号化アルゴリズムを使用して通信ストリームを暗号化します。したがって、TLS 1.3 プロトコルのセキュリティは、次の3種類の暗号化アルゴリズムに分解できます。 * 認証アルゴリズム -* 重要な確立アルゴリズム +* キー確立アルゴリズム * 対称暗号アルゴリズム -従来の暗号に対する量子コンピューターの脅威には、2 つの形態があります。Grover のアルゴリズムは最新の対称暗号アルゴリズムのセキュリティを半分に減らしますが、Shor のアルゴリズムは最新の認証および鍵確立アルゴリズムのセキュリティを完全に破ります。その結果、対称的な暗号アルゴリズムの強度を2倍にし、従来の認証と主要な確立アルゴリズムをポスト量子暗号アルゴリズムに置き換えることにより、通信を保護し続けることができます。TLS 1.3のハンドシェーク中に、Ciphersuiteは、接続期間中に使用される対称暗号を指定することに注意してください。AES-128は一般に十分であると認められているため、AES_256_GCM_SHA384 Ciphersuiteを使用して強度を2倍にすることができます。鍵の確立と認証には、ポスト量子 KEM (Key Encapsulation Mechanisms) と署名スキームがあります。 +量子コンピュータが従来の暗号に及ぼす脅威には2つの形態があります。グローバーのアルゴリズムは、最新の対称暗号アルゴリズムのセキュリティを半分に低下させ、ショアのアルゴリズムは、最新の認証および鍵確立アルゴリズムのセキュリティを完全に破壊します。その結果、対称暗号アルゴリズムの強度を2倍にし、従来の認証および鍵確立アルゴリズムをポスト量子アルゴリズムに置き換えることで、通信を保護し続けることができます。TLS 1.3 ハンドシェイク中、暗号スイートは接続中に使用される対称暗号を指定します。AES-128は一般的に十分であると認められているため、AES_256_GCM_SHA384暗号スイートを使用することで強度を2倍にすることができます。鍵確立と認証には、ポスト量子KEM (Key Encapsulation Mechanisms) と署名スキームがあります。 -これらは、従来のアルゴリズムとは異なる種類の数学を使用します。それらは、量子コンピューターへの耐性のために特別に設計されています。統合することを選択した認証アルゴリズムとKEMはすべて格子ベースのアルゴリズムです。 +これらは量子コンピュータへの耐性のため、従来のアルゴリズムとは異なる種類の数学を使用して特別に設計されます。私たちが統合することを選択した認証アルゴリズムとKEMはすべて格子ベースのアルゴリズムです。 * ダイリチウム署名スキーム @@ -76,13 +76,13 @@ NISTが、量子コンピューターに対して脆弱になる公開キー暗 -格子ベースの暗号化の説明はこの文書の範囲外になりますが、これらのアルゴリズムに関する情報は。 +格子ベースの暗号化の説明はこのドキュメントの範囲外のため、これらのアルゴリズムに関する詳細は、NIST の公開文書 をご確認ください。 -残念ながら、ショックを受けるかもしれませんが、これらのアルゴリズムが量子コンピューターからの攻撃に抵抗できるかどうかは実際にはわかっていません。実際、これらのアルゴリズムが従来のコンピューターに対して安全であることさえわかっていません。その可能性はますます低くなりますが、誰かが格子ベースの暗号を破る可能性があります。しかし、セキュリティの専門家があなたに言うように、これは暗号化が常にどのように機能してきた形です。アルゴリズムは、使い始めは良いものですが、弱点や脆弱性が発見され、技術が向上します。ポスト量子アルゴリズムは、比較的新しく、コミュニティからもう少し注意を払う必要があるという点で、やや問題があります。 +残念ながら、この章を記している時点においてこれらのアルゴリズムが量子コンピューターからの攻撃に耐えられるかどうかは、まだ分かっていません。従来型コンピューターにおける攻撃耐性も同様です。可能性はますます低くなっていますが、誰かが格子ベースの暗号化を破る可能性があります。ただし、暗号化は常にこのような経緯で機能してきた歴史があります。アルゴリズムは使い始めたときは優れていますが、弱点や脆弱性が発見され、テクノロジーは順次改善されます。ポスト量子アルゴリズムは比較的新しいため、コミュニティからもう少し注目する必要があるかもしれません。 -解決策の 1 つは、これらの新しいアルゴリズムを完全に信用しないことです。とりあえず、私たちは実際に信頼する従来のアルゴリズムで、質量のKEMをハイブリダイズすることで賭けをヘッジできます。NIST標準化された曲線を備えたECCは、FIPSコンプライアンスが優先事項であるため、それらを使用し続ける必要があるため、優れた候補のように見えます。このため、ポストカントゥムケムを統合しただけでなく、NIST承認の曲線を介してECDSAでハイブリダイズしました。以下のハイブリッドグループのリストをご覧ください。 +解決策の1つは、これらの新しいアルゴリズムを完全には信頼しないことです。今のところ、ポスト量子KEMを、信頼している従来のアルゴリズムとハイブリッド化することで、このリスクを回避することができます。FIPS準拠を第一に考えると、NIST標準曲線を使用したECCは良い選択肢になります。このため、ポスト量子KEMを統合するだけでなく、NISTが承認した曲線上のECDSAとハイブリッド化しました。詳しくは以下のハイブリッドグループのリストを参照してください。 @@ -90,11 +90,11 @@ NISTが、量子コンピューターに対して脆弱になる公開キー暗 -次の手順では、クリーンな Linux 開発環境から開始し、段階的に安全な TLS 1.3 接続を実行できるようにします。 +ここでは、まっさらなLinux環境から安全なTLS 1.3接続を実行できるようにするまでの手順を示します。 ### ビルド手順 -wolfSSL リポジトリの INSTALL ファイル (https://github.com/wolfSSL/wolfssl/blob/master/INSTALL) を参照してください。 +wolfSSLリポジトリのINSTALLファイル (https://github.com/wolfSSL/wolfssl/blob/master/INSTALL) を参照してください。 項目 15 (TLS 1.3 用の liboq を使用したビルド [実験的]) には、構成とビルドの方法に関する説明があります。 @@ -112,7 +112,7 @@ wolfSSL リポジトリの INSTALL ファイル (https://github.com/wolfSSL/wolf ### 量子安全な TLS 接続を確立する -次のようにサーバーとクライアントを別々のターミナルで実行できます。 +次のようにして、サーバーとクライアントを別々のターミナルで実行します。 ```sh examples/server/server -v 4 -l TLS_AES_256_GCM_SHA384 \ @@ -133,19 +133,20 @@ examples/client/client -v 4 -l TLS_AES_256_GCM_SHA384 \ 対称暗号化に AES-256、認証に FALCON 署名方式、キー確立に KYBER KEM とハイブリッド化された ECDHE を使用して、完全に量子安全な TLS 1.3 接続を実現しました。他のポスト量子の例についての詳細は、https://github.com/wolfSSL/wolfssl-examples/blob/master/pq/README.md で見つけることができます。 -## WolfsSLとOQSのフォークのOpenSSLの間の命名規則マッピング +## wolfSSLとOQSのフォークのOpenSSLの間の命名規則マッピング -NIST PQCコンペティションに提出したすべてのチームは、ここでNISTで定義されているように、複数のレベルのセキュリティをサポートしました： +NIST PQCコンテストに応募したすべてのチームは、NISTが定義する複数のセキュリティレベルをサポートしていました。 + -そのように、彼らは彼らの亜種を識別する方法を思いつく必要があり、各チームは彼ら自身のバリアント命名スキームを思いつく必要がありました。次の表を見ることができるように、これを行う方法についてのチーム間に調整はありませんでした。wolfSSLライブラリは、バリアントのNISTレベルベースの命名規則を使用しています。OQSチームは、各提出書の命名規則に従うことを選択しました。次の表を参照してください。 +そのため、各チームはバリアントを識別する方法を考え出す必要があり、各チームが独自のバリアント命名スキームを考え出しました。次の表からわかるように、この方法についてチーム間で調整はありませんでした。wolfSSL ライブラリは、バリアントのNISTレベルベースの命名規則を使用します。OQSチームは、各応募論文の命名規則に従うことを選択しました。次の表で、当社の命名規則と応募論文の命名規則をマッピングしています。 ポスト量子署名方式の命名規則:： -wolfsslバリアント名|PQC提出バリアント名 +wolfSSLバリアント名|PQC提出バリアント名 -------------------- | --------------------------- FALCON_LEVEL1 | FALCON512 FALCON_LEVEL5 | FALCON1024 @@ -161,9 +162,9 @@ SPHINCS_SMALL_LEVEL5 | SPHINCS+-SHAKE256-256s-simple -ポスト量子 KEM 命名規則： +ポスト量子KEM命名規則： -wolfsslバリアント名|PQC提出バリアント名 +wolfSSLバリアント名|PQC提出バリアント名 -------------------- | --------------------------- KYBER_LEVEL1 | KYBER512 KYBER_LEVEL3 | KYBER768 @@ -172,7 +173,7 @@ KYBER_LEVEL5 | KYBER1024 ポスト量子ハイブリッド KEM 命名規則： -wolfsslバリアント名|NIST ECC曲線とPQC提出バリアント名 +wolfSSLバリアント名|NIST ECC曲線とPQC提出バリアント名 -------------------- | ---------------------------------------------- P256_KYBER_LEVEL1 | ECDSA P-256 and KYBER512 P384_KYBER_LEVEL3 | ECDSA P-384 and KYBER768 @@ -185,12 +186,12 @@ P521_KYBER_LEVEL5 | ECDSA P-521 and KYBER1024 -私たちがサポートするポストカントゥム署名アルゴリズムとKEMは、OQSプロジェクトのOpenSSLフォークによってもサポートされています。彼らの命名規則は私たちのものとは異なりますが、同じ数値OIDとコードポイントを使用し、暗号化アーティファクトが同じライブラリによって生成および処理されるという点で完全な相互運用性があります。すなわち、liboqs。コードポイントは、TLS 1.3のシガルグおよびサポートされているグループ拡張機能で使用されます。OIDは、公開キー、プライベートキー、署名の識別子として証明書およびプライベートキーで使用されます。 +当社がサポートする耐量子署名アルゴリズムとKEMは、OQSプロジェクトのOpenSSLフォークでもサポートされています。命名規則は当社のものとは異なりますが、同じ数値OIDとコードポイントを使用し、暗号化アーティファクトが同じライブラリ (liboqs) によって生成および処理されるという点で、完全な相互運用性があります。コードポイントは、TLS 1.3のsigalgsおよびサポートされるグループ拡張で使用されます。OIDは、公開鍵、秘密鍵、署名の識別子として証明書と秘密鍵で使用されます。 TLS 1.3のための量子コードポイント -wolfsslバリアント名|コードポイント +wolfSSLバリアント名|コードポイント -------------------- | ---------- FALCON_LEVEL1 | 65035 FALCON_LEVEL5 | 65038 @@ -207,7 +208,7 @@ P521_KYBER_LEVEL5 | 12093 証明書の Post-Quantum OID： -wolfsslバリアント名|oid +wolfSSLバリアント名|oid -------------------- | --- FALCON_LEVEL1 | 1.3.9999.3.1 FALCON_LEVEL5 | 1.3.9999.3.4 @@ -226,12 +227,12 @@ SPHINCS_SMALL_LEVEL5 | 1.3.9999.6.9.7 -すべてのサイズはバイトです。 +以下に示すサイズの単位はバイトです。 量子署名方式のアーティファクトサイズ： -wolfsslバリアント名|公開キーのサイズ|秘密キーサイズ|最大署名サイズ +wolfSSLバリアント名|公開鍵サイズ|秘密鍵サイズ|最大署名サイズ -------------------- | --------------- | ---------------- | ---------------------- FALCON_LEVEL1 | 897 | 1281 | 690 FALCON_LEVEL5 | 1793 | 2305 | 1330 @@ -248,12 +249,12 @@ SPHINCS_SMALL_LEVEL5 | 64 | 128 | 29792 -**注**：Falconには、さまざまな署名サイズがあります。 +**注**：Falconには、いくつかの署名サイズがあります。 -ポスト量子 KEM アーティファクトのサイズ： +耐量子 KEM アーティファクトのサイズ： -wolfsslバリアント名|公開キーのサイズ|秘密キーサイズ|暗号文サイズ|共有秘密のサイズ +wolfSSLバリアント名|公開鍵サイズ|秘密鍵サイズ|暗号文サイズ|共有秘密のサイズ -------------------- | --------------- | ---------------- | --------------- | ------------------ KYBER_LEVEL1 | 800 | 1632 | 768 | 32 KYBER_LEVEL3 | 1184 | 2400 | 1088 | 32 @@ -268,8 +269,7 @@ KYBER_90S_LEVEL5 | 1568 | 3168 | 1568 | 32 ## 統計的データ - -次の統計データとベンチマークは、Ubuntu 21.10 を実行する 8 コアの第 11 世代 Intel Core i7-1165G7@3-GHz で取得されました。Liboqsは、`0.7.0`の古いコードとのコンパイラの非互換性により、メインブランチの`ba5b61a779a0db364f0e691a0a0bc8ac42e73f1b`にアップグレードされました。次の構成が使用されました(特に明記しない限り)。 +以下の統計とベンチマークは、Ubuntu 21.10を実行している第11世代 Intel Core i7-1165G7@3-GHz(8コア) で取得しました。liboqs は、`0.7.0` の古いコードとのコンパイラの非互換性のため、メインブランチで `ba5b61a779a0db364f0e691a0a0bc8ac42e73f1b` を使用しています。特記のない限り、構成オプションは以下のとおりです。 liboqs： @@ -277,7 +277,7 @@ liboqs： ```text -CFLAGS="-Os" cmake -DOQS_USE_OPENSSL=0 -DOQS_MINIMAL_BUILD="OQS_ENABLE_KEM_saber_saber;OQS_ENABLE_KEM_saber_lightsaber;OQS_ENABLE_KEM_saber_firesaber;OQS_ENABLE_KEM_kyber_1024;OQS_ENABLE_KEM_kyber_1024_90s;OQS_ENABLE_KEM_kyber_768;OQS_ENABLE_KEM_kyber_768_90s;OQS_ENABLE_KEM_kyber_512;OQS_ENABLE_KEM_kyber_512_90s;OQS_ENABLE_KEM_ntru_hps2048509;OQS_ENABLE_KEM_ntru_hps2048677;OQS_ENABLE_KEM_ntru_hps4096821;OQS_ENABLE_KEM_ntru_hrss701;OQS_ENABLE_SIG_falcon_1024;OQS_ENABLE_SIG_falcon_512" .. +CFLAGS="-Os" cmake -DOQS_USE_OPENSSL=0 -DOQS_MINIMAL_BUILD="OQS_ENABLE_KEM_saber_saber;OQS_ENABLE_KEM_saber_lightsaber;OQS_ENABLE_KEM_saber_firesaber;OQS_ENABLE_KEM_kyber_1024;OQS_ENABLE_KEM_kyber_1024_90s;OQS_ENABLE_KEM_kyber_768;OQS_ENABLE_KEM_kyber_768_90s;OQS_ENABLE_KEM_kyber_512;OQS_ENABLE_KEM_kyber_512_90s;OQS_ENABLE_KEM_ntru_hps2048509;OQS_ENABLE_KEM_ntru_hps2048677;OQS_ENABLE_KEM_ntru_hps4096821;OQS_ENABLE_KEM_ntru_hrss701;OQS_ENABLE_SIG_falcon_1024;OQS_ENABLE_SIG_falcon_512;OQS_ENABLE_SIG_dilithium_2;OQS_ENABLE_SIG_dilithium_3;OQS_ENABLE_SIG_dilithium_5;OQS_ENABLE_SIG_dilithium_2_aes;OQS_ENABLE_SIG_dilithium_3_aes;OQS_ENABLE_SIG_dilithium_5_aes" .. ``` @@ -299,7 +299,7 @@ wolfssl： -**注**：主にポストカントゥムアルゴリズムをベンチマークしていますが、比較目的のために従来のアルゴリズムを残しています。 +**注**：主に耐量子アルゴリズムをベンチマークしていますが、比較目的のために従来のアルゴリズムを残しています。 @@ -307,7 +307,7 @@ wolfssl： -`tls_bench`のアプリケーションバイナリファイルの例は、ビルドされてから削除された後(約2.4m)2479992バイトです。`--with-liboqs`がなければ、ビルドされてから571832バイト(約559k)があります。これは、1908160バイト(約1.9MB)の違いです。 +`tls_bench` サンプルプログラムのバイナリファイルは約2.4MB、`--with-liboqs` を使用しない場合には559kBです。約1.9MBの違いがあります。 @@ -315,7 +315,7 @@ wolfssl： -次の結果は、サンプルサーバーとクライアントを実行し、Wiresharkを介して送信されているすべての情報を記録することによって行われました。これには、相互認証、「こんにちはwolfSSL！」とTLS 1.3ハンドシェイクが含まれます。そして、「私はあなたのFa Shizzle」を聞きます！メッセージすべてのパケットの`tcp.len`を合計しました。 +サンプルサーバーとクライアントを実行し、送信されるすべての情報をWiresharkで記録することによって取得した値を以下に示します。これには、相互認証による TLS 1.3 ハンドシェイク、"hello wolfssl!"、"I hear you fa shizzle!" メッセージが含まれます。すべてのパケットの `tcp.len` を合計しました。 ciphersuite |認証|キー施設|合計バイト ---------------------- | -------------- | --------------------- | ----------- @@ -348,10 +348,10 @@ TLS_AES_256_GCM_SHA384 | DILITHIUM_LEVEL5 | ECC SECP256R1 | 13477 -これらの統計は、次の構成フラグを追加することで取得されました：`--enable-trackmemory --enable-stacksize`。 - +これらの統計は、次の構成フラグを追加して取得しました。 +`--enable-trackmemory --enable-stacksize` -サーバーサインとクライアントのメモリの使用クライアントのサーバー認証なしで、TLS13-AES256-GCM-SHA384 CipherSuiteおよびECC SECP256R1のキー交換のためのECC SECP256R1。 +クライアントのサーバー認証なしのサーバー署名とクライアント検証、鍵交換用の TLS13-AES256-GCM-SHA384 暗号スイートおよび ECC SECP256R1 におけるメモリ使用量を以下に示します。 @@ -451,6 +451,10 @@ heap peak = 41760 KEMグループのメモリ使用。サーバーのクライアント認証には TLS13-AES256-GCM-SHA384 暗号スイートおよび RSA-2048 を使用し、クライアントのサーバー認証は使用しません。 +KEM グループのメモリ使用量を示します。サーバーのクライアント認証には TLS13-AES256-GCM-SHA384とRSA-2048を使用し、クライアントのサーバー認証は行いません。 + + + ```text Server KYBER_LEVEL1 @@ -676,7 +680,7 @@ decaps | 299571 | 3.000 | 10.014 | 5.489 | -次のベンチマークは、次の設定フラグを使用して得られました。 +次のベンチマークは、次の設定フラグを使用して取得しました。 @@ -688,7 +692,6 @@ decaps | 299571 | 3.000 | 10.014 | 5.489 | --enable-aesni \ --enable-sp \ --enable-sp-math \ - --enable-sp-math-all \ --enable-sp-asm \ CFLAGS="-Os -DECC_USER_CURVES -DHAVE_ECC256 -DHAVE_ECC384" ``` @@ -696,11 +699,11 @@ decaps | 299571 | 3.000 | 10.014 | 5.489 | -#### WolfCryptのベンチマーク +#### wolfCryptのベンチマーク -**注**：1つのコアのみが使用されます。 +**注**：シングルコアで測定したものです。 @@ -736,11 +739,11 @@ kyber90s_level5-ed 39300 ops took 1.000 sec, avg 0.025 ms, 39283.188 ops -#### Wolfsslのベンチマーク +#### wolfSSLのベンチマーク -**注**：これらのベンチマークに使用されているコアのみが2つだけです。 +**注**：2コアで測定したものです。 @@ -996,7 +999,7 @@ wolfSSL Client Benchmark on TLS13-AES256-GCM-SHA384 with group P384_KYBER_90S_LE -次のベンチマークは、次の設定フラグを使用して得られました。 +次のベンチマークは、次の設定フラグを使用して取得しました。 @@ -1013,7 +1016,7 @@ wolfSSL Client Benchmark on TLS13-AES256-GCM-SHA384 with group P384_KYBER_90S_LE -**注**：これらのベンチマークに使用されているコアのみが2つだけです。 +**注**：2コアで測定したものです。 ```text @@ -1084,38 +1087,39 @@ wolfSSL Client Benchmark on TLS13-AES256-GCM-SHA384 with group P521_KYBER_90S_LE 技術文書や既知の回答テストなどのその他のリソースは、NIST PQC Webサイトにあります。 -。 + -アルゴリズム固有のベンチマーク情報については、OQS プロジェクトの Web サイトにベンチマーク情報があります。 +アルゴリズム固有のベンチマーク情報については、OQSプロジェクトのWebサイトに掲載されています。 ## ポスト量子ステートフルハッシュベース署名 -このセクションでは最近wolfSSLがサポートを開始したLMS/HSSなどのポスト量子ステートフルハッシュベース署名（HBS)スキームをカバーしています。 +このセクションでは、最近wolfSSLがサポートを開始したLMS/HSSなどのポスト量子ステートフルハッシュベース署名(HBS)スキームについて記します。 ### 動機づけ -ステートフルHBSスキームには、さまざまな理由から関心が高まっています。ステートフルHBSスキームの主な動機はポスト量子セキュリティです。この付録で以前に説明したように、Shorのアルゴリズムを使用すると、量子コンピュータが大きな整数を効率的に因数分解し、離散対数を計算できるため、RSAやECCなどの公開鍵暗号化スキームを完全に突破できます。 +ステートフルHBSスキームは、さまざまな理由から関心が高まっています。 +ステートフルHBSスキームの主な目的は、量子セキュリティの強化です。前述したように、ショアのアルゴリズムにより、量子コンピューターは大きな整数を効率的に因数分解し、離散対数を計算することができます。これによって、RSAやECCなどの公開鍵暗号スキームを完全に破ることができます。 -対照的に、ステートフルHBSスキームは、その基礎となるハッシュ関数とマークルツリー(通常はSHA256で実装される) のセキュリティに基づいており、暗号に関連する量子コンピューターの出現によって破られるとは予想されていません。これらの理由により、これらはNIST SP 800-208およびNSAのCNSA 2.0スイートによって推奨されています。詳細については、次の2つのリンクを参照してください： +対照的に、ステートフルHBSスキームは、その基礎となるハッシュ関数とマークルツリー(通常SHA256で実装)のセキュリティに基づいており、暗号に関連する量子コンピューターの登場によって破られることは予想されていません。これらの理由から、ステートフルHBSスキームは NIST SP 800-208 および NSA の CNSA 2.0 スイートで推奨されています。詳細については、次の2つのリンクをご参照ください。 - - -さらに、CNSA 2.0タイムラインでは、ポスト量子ステートフルHBSスキームを2030年までに独占的に使用し、採用を「直ちに」開始する必要があると指定しています。実際LMSの導入は、CNSA 2.0スイートのスケジュールにおける最も早い要件です。 +さらにCNSA 2.0のタイムラインでは、2030年までにポスト量子ステートフルHBSスキームのみを使用する必要があり、採用は 「直ちに」 開始する必要があると規定されています。LMS の採用は、CNSA 2.0スイートのタイムラインで最も早い要件です。 -ただし、ステートフルHBSスキームの性質上、その使用と状態の追跡には十分な注意が必要です。ステートフルHBSシステムでは、秘密鍵は実際にはワンタイム署名 (OTS)鍵の有限セットであり、再利用することはできません。同じOTS鍵を使用して2つの異なるメッセージに署名すると、攻撃者が署名を偽造することが可能になり、スキーム全体のセキュリティが崩れてしまいます。したがって、ステートフルHBSスキームは、公共のインターネットなどの一般的な用途には適していません。 +ただし、ステートフルHBSスキームの性質上、その使用と状態の追跡には細心の注意を払う必要があります。ステートフルHBSシステムでは、秘密鍵は実際にはワンタイム署名(OTS)キーの有限セットであり、再利用されることはありません。同じOTSキーを使用して2つの異なるメッセージを署名すると、攻撃者が署名を偽造できる可能性があり、スキーム全体のセキュリティが崩壊します。したがって、ステートフルHBSスキームは、パブリックインターネットなどの一般的な使用には適していません。 -代わりに、これらの独自の強みと特性、およびNISTおよびNSAの支援により、LMS/HSSなどのステートフルHBSスキームは、オフラインファームウェア認証と署名検証、特に長期間の運用が予想される組み込みシステムまたは制約付きシステムで特に重要です。 したがって、暗号化に関連する量子コンピューターに対する耐性が必要です。 +LMS/HSSなどのステートフルHBSスキームは、特に長い運用寿命が期待され、暗号に関連する量子コンピューターに対して耐性が求められる組み込みシステムや制約付きシステムでのオフラインファームウェア認証と署名検証に特に役立ちます。 ### LMS/HSS署名 wolfSSLは、wolfCrypt組み込み暗号エンジンにLMS/HSSハッシュベースの署名スキームのサポートを追加しています。これは、以前のlibOQS統合と同様に、hash-sigsLMS/HSSライブラリ()との実験的な統合によって実現されます。 -Leighton-Micali Signatures(LMS)とそのマルチツリーのバリアントであるHierarchical Signature System(HSS)は、ポスト量子、ステートフルハッシュベース署名スキームです。公開鍵と秘密鍵が小さく、署名と検証が速いことで知られています。シグネチャのサイズは大きくなりますが、Winternitzパラメーターを介して調整できます。詳細については、RFC8554の次の2つのリンクを参照してください： +Leighton-Micali Signatures(LMS)とそのマルチツリーのバリアントであるHierarchical Signature System(HSS)は、ポスト量子、ステートフルハッシュベース署名スキームです。公開鍵と秘密鍵が小さく、署名と検証が速いことで知られています。署名のサイズは大きくなりますが、Winternitzパラメーターを介して調整できます。詳細については、RFC8554の次の2つのリンクを参照してください： - LMS: - HSS: @@ -1170,27 +1174,28 @@ WC_LMS_PARM_L3_H5_W8 | 3992 | 32768 WC_LMS_PARM_L3_H10_W4 | 7640 | 1073741824 WC_LMS_PARM_L4_H5_W8 | 5340 | 1048576 -表からわかるように、署名のサイズは主にレベルとウィンターニッツパラメーター、および程度は低いですが高さによって決まります。 -- レベル値を大きくすると、シグネチャサイズが大幅に増加します。 -- 高さの値を大きくすると、署名のサイズが適度に増加します。 -- Winternitz 値を大きくすると、署名のサイズが小さくなりますが、鍵の生成と署名/検証にかかる時間が長くなります。 +表からわかるように、署名のサイズは主にレベルとWinternitz値、および比較的影響は小さいですが高さによって決まります。 -鍵の生成時間は、第1レベルのツリーの高さによって大きく決まります。使用可能な署名の数が同じであっても、レベル３、高さ5 のツリーは、初期鍵生成時にレベル１、高さ15 のツリーよりもはるかに高速です +- レベル値を大きくすると、署名サイズは大幅に増加します。 +- 高さの値を大きくすると、署名のサイズは増加します。 +- Winternitz値を大きくすると、署名のサイズは小さくなりますが、鍵の生成と署名/検証にかかる時間が長くなります。 + +鍵の生成時間は、第1レベルのツリーの高さによって大きく決まります。使用可能な署名の数が同じであっても、レベル3、高さ5のツリーは、初期鍵生成時にレベル1、高さ15のツリーよりもはるかに高速です #### LMS/HSSビルド方法 -wolfSSLリポジトリのINSTALLファイル(https://github.com/wolfSSL/wolfssl/blob/master/INSTALL)を参照してください。 項目17(LMS/HSSサポートのためのhash-sigsライブラリを使用した構築 [実験]) には、wolfSSLとhash-sigs LMS/HSSライブラリを設定および構築する方法についての手順が記載されています。 +wolfSSLリポジトリのINSTALLファイル (https://github.com/wolfSSL/wolfssl/blob/master/INSTALL) を参照してください。 項目17(LMS/HSSサポートのためのhash-sigsライブラリを使用した構築 [実験]) には、wolfSSLとhash-sigs LMS/HSSライブラリを設定および構築する方法についての手順が記載されています。 #### ベンチマークデータ 次のベンチマークデータは、Fedora 38(`6.2.9-300.fc38.x86_64`)上の8コアIntel i7-8700 CPU@3.20GHzで取得されました。マルチスレッドの例では4スレッドと4コアが使用されましたが、シングルスレッドの例では1コアのみが使用されました。 INSTALLファイルの項目17で説明したように、hash-sigsライブラリは2つの静的ライブラリを提供します。 -- `hss_lib.a`: シングルスレッドバージョン。 -- `hss_lib_thread.a`: マルチスレッドバージョン。 +- `hss_lib.a`: シングルスレッド +- `hss_lib_thread.a`: マルチスレッド -マルチスレッドバージョンではワーカースレッドが生成され、鍵生成などのCPUを集中的に使用するタスクが高速化されます。これにより、主にすべてのパラメータ値に対する鍵の生成と署名が高速化され、程度は低いですが、より大きなレベル値の検証が高速化されます。 +マルチスレッドバージョンではワーカースレッドが生成され、鍵生成などのCPUを集中的に使用するタスクが高速化されます。これにより、主にすべてのパラメータ値に対する鍵の生成と署名が高速化され、より大きなレベル値の検証も多少高速化されます。 -参考までに、wolfSSLは両方のベンチマークを取得するために次のようにして構築されました。 +なお、以下のベンチマークは次の構成オプションを有効化して取得しました。 ```text @@ -1255,3 +1260,168 @@ LMS/HSS L4_H5_W8 5340 sign 100 ops took 1.066 sec, avg 10.665 ms, 93. LMS/HSS L4_H5_W8 5340 verify 200 ops took 1.478 sec, avg 7.388 ms, 135.358 ops/sec Benchmark complete ``` + + +### XMSS/XMSS^MT 署名 + +wolfSSLは、XMSS/XMSS^MTステートフルハッシュベース署名のサポートを追加しています。LMSと同様に、これはRFC 8391 (https://www.rfc-editor.org/rfc/rfc8391.html) のxmss-reference リポジトリ (https://github.com/XMSS/xmss-reference.git) との実験的な統合によって実現されています。 + +xmss-referenceは、`xmss_core_fast` および `xmss_core` 実装をサポートしています。`xmss_core_fast` 実装は、トレードオフとしてより大きな秘密鍵サイズでパフォーマンスを優先するように設計されています。 + +当社の統合では `xmss_core_fast` を使用していますが、パッチが適用されているため、代わりに wolfCrypt SHA256実装を使用できます。 + +パッチは、wolfssl-examplesリポジトリの +```pq/stateful_hash_sig/0001-Patch-to-support-wolfSSL-xmss-reference-integration.patch``` +で公開しています。https://github.com/wolfSSL/wolfssl-examples + +全体的に、XMSS/XMSS^MTはLMS/HSSに似ています。より詳細な比較については、「LMS vs XMSS: 2 つのハッシュベース署名標準の比較」(https://eprint.iacr.org/2017/349.pdf) を参照してください。 + +XMSS^MTはXMSSのマルチツリー一般化であり、HSS with LMSに似ていますが、XMSS/XMSS^MTではWinternitz値が `w=16` に固定されている点が異なります。公開鍵はXMSS/XMSS^MTでは若干大きくなり(XMSS/XMSS^MTでは68 バイト、LMS/HSSでは60バイト)、署名は若干小さくなります。 + +#### サポートしているパラメータ + +wolfSSLは、NIST SP 800-208 (https://csrc.nist.gov/pubs/sp/800/208/final) の表10および11のSHA256 XMSS/XMSS^MTパラメータセットをサポートしています。 + +parameter set name | Oid | n | w | h | d | h/d | Sig len +----------------------- | ----------- | --- | --- | --- | --- | --- | -- +XMSS | | | | | | | +"XMSS-SHA2_10_256" | 0x00000001 | 32 | 16 | 10 | 1 | 10 | 2500 +"XMSS-SHA2_16_256" | 0x00000002 | 32 | 16 | 16 | 1 | 16 | 2692 +"XMSS-SHA2_20_256" | 0x00000003 | 32 | 16 | 20 | 1 | 20 | 2820 +XMSS^MT | | | | | | | +"XMSSMT-SHA2_20/2_256" | 0x00000001 | 32 | 16 | 20 | 2 | 10 | 4963 +"XMSSMT-SHA2_20/4_256" | 0x00000002 | 32 | 16 | 20 | 4 | 5 | 9251 +"XMSSMT-SHA2_40/2_256" | 0x00000003 | 32 | 16 | 40 | 2 | 20 | 5605 +"XMSSMT-SHA2_40/4_256" | 0x00000004 | 32 | 16 | 40 | 4 | 10 | 9893 +"XMSSMT-SHA2_40/8_256" | 0x00000005 | 32 | 16 | 40 | 8 | 5 | 18469 +"XMSSMT-SHA2_60/3_256" | 0x00000006 | 32 | 16 | 60 | 3 | 20 | 8392 +"XMSSMT-SHA2_60/6_256" | 0x00000007 | 32 | 16 | 60 | 6 | 10 | 14824 +"XMSSMT-SHA2_60/12_256" | 0x00000008 | 32 | 16 | 60 | 12 | 5 | 27688 + +上記の表で、`n` は HASH 関数のバイト数、`w` はWinternitz値、`h` はツリーシステムの合計高さ、`d` はツリーのレベルを示します。 + +鍵生成時間は第1レベルのツリーの高さ(または`h/d`) によって大きく左右されますが、署名の長さは主に`d` (ハイパーツリーレベルの数)とともに増加します。 + +LMS/HSSと同様に、使用可能な署名の数は `2**h` に比例して増加します。ここで `h` はツリー システムの合計高さです。 + +#### ベンチマークデータ + +以下では、Intel x86_64およびaarch64のいくつかのXMSS/XMSS^MTパラメータセットのベンチマーク データを示します。これらのシステムでのSHA256パフォーマンスも参考として記載されています。必要なハッシュチェーンの数が多いため、XMSS/XMSS^MTのCPU 作業の大部分が計算されるためです。さらに、xmss-referenceへのパッチはwolfCryptのSHA256実装を置き換えるため、同じASMの高速化のメリットが得られます。 + +前述のように、XMSS統合ではxmss-referenceの`xmss_core_fast`実装を使用しています。この実装は、秘密鍵のサイズが大きいというトレードオフで、より高速なパフォーマンスを実現します。 + +**x86_64** + +以下のx86_64ベンチマークデータは、Fedora 38 (`6.2.9-300.fc38.x86_64`) が動作するIntel i7-8700 CPU @ 3.20GHz(8コア)で取得しました。このCPUには`avx avx2`フラグがあり、`--enable-intelasm` を有効化することでハッシュ操作を高速化できます。 + +`--enable-intelasm` を使用する場合 + +```text +$./wolfcrypt/benchmark/benchmark -xmss_xmssmt -sha256 +------------------------------------------------------------------------------ + wolfSSL version 5.6.3 +------------------------------------------------------------------------------ +Math: Multi-Precision: Wolf(SP) word-size=64 bits=4096 sp_int.c +wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each) +SHA-256 500 MiB took 1.009 seconds, 495.569 MiB/s Cycles per byte = 6.14 +XMSS-SHA2_10_256 2500 sign 200 ops took 1.010 sec, avg 5.052 ms, 197.925 ops/sec +XMSS-SHA2_10_256 2500 verify 1600 ops took 1.011 sec, avg 0.632 ms, 1582.844 ops/sec +XMSSMT-SHA2_20/2_256 4963 sign 200 ops took 1.286 sec, avg 6.431 ms, 155.504 ops/sec +XMSSMT-SHA2_20/2_256 4963 verify 700 ops took 1.009 sec, avg 1.441 ms, 693.905 ops/sec +XMSSMT-SHA2_20/4_256 9251 sign 300 ops took 1.223 sec, avg 4.076 ms, 245.335 ops/sec +XMSSMT-SHA2_20/4_256 9251 verify 400 ops took 1.027 sec, avg 2.569 ms, 389.329 ops/sec +XMSSMT-SHA2_40/4_256 9893 sign 200 ops took 1.466 sec, avg 7.332 ms, 136.394 ops/sec +XMSSMT-SHA2_40/4_256 9893 verify 400 ops took 1.024 sec, avg 2.560 ms, 390.627 ops/sec +XMSSMT-SHA2_40/8_256 18469 sign 300 ops took 1.202 sec, avg 4.006 ms, 249.637 ops/sec +XMSSMT-SHA2_40/8_256 18469 verify 200 ops took 1.089 sec, avg 5.446 ms, 183.635 ops/sec +XMSSMT-SHA2_60/6_256 14824 sign 200 ops took 1.724 sec, avg 8.618 ms, 116.033 ops/sec +XMSSMT-SHA2_60/6_256 14824 verify 300 ops took 1.136 sec, avg 3.788 ms, 263.995 ops/sec +XMSSMT-SHA2_60/12_256 27688 sign 300 ops took 1.210 sec, avg 4.034 ms, 247.889 ops/sec +XMSSMT-SHA2_60/12_256 27688 verify 200 ops took 1.575 sec, avg 7.877 ms, 126.946 ops/sec +Benchmark complete +``` + +`--enable-intelasm` を使用しない場合 + +```text +$./wolfcrypt/benchmark/benchmark -xmss_xmssmt -sha256 +------------------------------------------------------------------------------ + wolfSSL version 5.6.3 +------------------------------------------------------------------------------ +Math: Multi-Precision: Wolf(SP) word-size=64 bits=4096 sp_int.c +wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each) +SHA-256 275 MiB took 1.005 seconds, 273.549 MiB/s Cycles per byte = 11.13 +XMSS-SHA2_10_256 2500 sign 200 ops took 1.356 sec, avg 6.781 ms, 147.480 ops/sec +XMSS-SHA2_10_256 2500 verify 1200 ops took 1.025 sec, avg 0.854 ms, 1170.547 ops/sec +XMSSMT-SHA2_20/2_256 4963 sign 200 ops took 1.687 sec, avg 8.436 ms, 118.546 ops/sec +XMSSMT-SHA2_20/2_256 4963 verify 600 ops took 1.187 sec, avg 1.978 ms, 505.663 ops/sec +XMSSMT-SHA2_20/4_256 9251 sign 200 ops took 1.119 sec, avg 5.593 ms, 178.785 ops/sec +XMSSMT-SHA2_20/4_256 9251 verify 300 ops took 1.086 sec, avg 3.622 ms, 276.122 ops/sec +XMSSMT-SHA2_40/4_256 9893 sign 200 ops took 1.991 sec, avg 9.954 ms, 100.460 ops/sec +XMSSMT-SHA2_40/4_256 9893 verify 300 ops took 1.043 sec, avg 3.478 ms, 287.545 ops/sec +XMSSMT-SHA2_40/8_256 18469 sign 200 ops took 1.114 sec, avg 5.572 ms, 179.454 ops/sec +XMSSMT-SHA2_40/8_256 18469 verify 200 ops took 1.495 sec, avg 7.476 ms, 133.770 ops/sec +XMSSMT-SHA2_60/6_256 14824 sign 100 ops took 1.111 sec, avg 11.114 ms, 89.975 ops/sec +XMSSMT-SHA2_60/6_256 14824 verify 200 ops took 1.070 sec, avg 5.349 ms, 186.963 ops/sec +XMSSMT-SHA2_60/12_256 27688 sign 200 ops took 1.148 sec, avg 5.739 ms, 174.247 ops/sec +XMSSMT-SHA2_60/12_256 27688 verify 100 ops took 1.080 sec, avg 10.797 ms, 92.618 ops/sec +Benchmark complete +``` + +**aarch64** + +以下のaarch64データは、CPUフラグ`sha1 sha2 sha3 sha512`を使用してApple M1上で実行されているUbuntu(`5.15.0-71-generic`) で取得されました。`--enable-armasm` を使用してビルドすると、特に SHA ハッシュ操作が大幅に高速化されます。 + +`--enable-armasm`を使用する場合 + +```text +$ ./wolfcrypt/benchmark/benchmark -xmss_xmssmt -sha256 +------------------------------------------------------------------------------ + wolfSSL version 5.6.3 +------------------------------------------------------------------------------ +Math: Multi-Precision: Wolf(SP) word-size=64 bits=4096 sp_int.c +wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each) +SHA-256 2305 MiB took 1.001 seconds, 2303.346 MiB/s +XMSS-SHA2_10_256 2500 sign 800 ops took 1.079 sec, avg 1.349 ms, 741.447 ops/sec +XMSS-SHA2_10_256 2500 verify 6500 ops took 1.007 sec, avg 0.155 ms, 6455.445 ops/sec +XMSSMT-SHA2_20/2_256 4963 sign 700 ops took 1.155 sec, avg 1.650 ms, 606.154 ops/sec +XMSSMT-SHA2_20/2_256 4963 verify 3100 ops took 1.021 sec, avg 0.329 ms, 3037.051 ops/sec +XMSSMT-SHA2_20/4_256 9251 sign 1100 ops took 1.006 sec, avg 0.915 ms, 1093.191 ops/sec +XMSSMT-SHA2_20/4_256 9251 verify 1700 ops took 1.013 sec, avg 0.596 ms, 1677.399 ops/sec +XMSSMT-SHA2_40/4_256 9893 sign 600 ops took 1.096 sec, avg 1.827 ms, 547.226 ops/sec +XMSSMT-SHA2_40/4_256 9893 verify 1600 ops took 1.062 sec, avg 0.664 ms, 1506.946 ops/sec +XMSSMT-SHA2_40/8_256 18469 sign 1100 ops took 1.007 sec, avg 0.916 ms, 1092.214 ops/sec +XMSSMT-SHA2_40/8_256 18469 verify 900 ops took 1.088 sec, avg 1.209 ms, 827.090 ops/sec +XMSSMT-SHA2_60/6_256 14824 sign 600 ops took 1.179 sec, avg 1.966 ms, 508.728 ops/sec +XMSSMT-SHA2_60/6_256 14824 verify 1100 ops took 1.038 sec, avg 0.944 ms, 1059.590 ops/sec +XMSSMT-SHA2_60/12_256 27688 sign 1100 ops took 1.015 sec, avg 0.923 ms, 1083.767 ops/sec +XMSSMT-SHA2_60/12_256 27688 verify 600 ops took 1.149 sec, avg 1.914 ms, 522.367 ops/sec +Benchmark complete +``` + +`--enable-armasm`を使用しない場合 + +```text +$ ./wolfcrypt/benchmark/benchmark -xmss_xmssmt -sha256 +------------------------------------------------------------------------------ + wolfSSL version 5.6.3 +------------------------------------------------------------------------------ +Math: Multi-Precision: Wolf(SP) word-size=64 bits=4096 sp_int.c +wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each) +SHA-256 190 MiB took 1.020 seconds, 186.277 MiB/s +XMSS-SHA2_10_256 2500 sign 200 ops took 1.908 sec, avg 9.538 ms, 104.845 ops/sec +XMSS-SHA2_10_256 2500 verify 800 ops took 1.002 sec, avg 1.253 ms, 798.338 ops/sec +XMSSMT-SHA2_20/2_256 4963 sign 100 ops took 1.084 sec, avg 10.843 ms, 92.222 ops/sec +XMSSMT-SHA2_20/2_256 4963 verify 500 ops took 1.240 sec, avg 2.479 ms, 403.334 ops/sec +XMSSMT-SHA2_20/4_256 9251 sign 200 ops took 1.615 sec, avg 8.074 ms, 123.855 ops/sec +XMSSMT-SHA2_20/4_256 9251 verify 200 ops took 1.071 sec, avg 5.355 ms, 186.726 ops/sec +XMSSMT-SHA2_40/4_256 9893 sign 100 ops took 1.354 sec, avg 13.543 ms, 73.840 ops/sec +XMSSMT-SHA2_40/4_256 9893 verify 300 ops took 1.483 sec, avg 4.945 ms, 202.237 ops/sec +XMSSMT-SHA2_40/8_256 18469 sign 200 ops took 1.588 sec, avg 7.941 ms, 125.922 ops/sec +XMSSMT-SHA2_40/8_256 18469 verify 100 ops took 1.042 sec, avg 10.415 ms, 96.014 ops/sec +XMSSMT-SHA2_60/6_256 14824 sign 100 ops took 1.571 sec, avg 15.710 ms, 63.654 ops/sec +XMSSMT-SHA2_60/6_256 14824 verify 200 ops took 1.526 sec, avg 7.632 ms, 131.033 ops/sec +XMSSMT-SHA2_60/12_256 27688 sign 200 ops took 1.607 sec, avg 8.036 ms, 124.434 ops/sec +XMSSMT-SHA2_60/12_256 27688 verify 100 ops took 1.501 sec, avg 15.011 ms, 66.616 ops/sec +Benchmark complete +``` diff --git a/wolfSSL/src-ja/appendix08.md b/wolfSSL/src-ja/appendix08.md index 1ea48424..4f1761ff 100644 --- a/wolfSSL/src-ja/appendix08.md +++ b/wolfSSL/src-ja/appendix08.md @@ -2,26 +2,27 @@ ## 目的 -このガイドは、wolfSSL 軽量 SSL/TLS ライブラリを新しい組み込みプラットフォーム、オペレーティング システム、またはトランスポート メディア (TCP/IP、Bluetooth など) に移植する開発者およびエンジニア向けのリファレンスを提供します。 これは、wolfSSL を移植する際に通常変更が必要な wolfSSL コードベースの領域を呼び出します。 これは「ガイド」であり、更新・修正されより良いものになります。 不足しているものがある場合はお知らせください。ドキュメントに指示や説明を追加させていただきます。 +このガイドは、軽量 SSL/TLS ライブラリwolfSSLを新しい組み込みプラットフォーム、オペレーティングシステム、トランスポートメディア(TCP/IP、Bluetoothなど)に移植するエンジニア向けのリファレンスを提供します。wolfSSLを移植する際に通常変更が必要となるwolfSSLコードベースの領域を説明しています。本稿はあくまで「ガイド」で、技術の進化に伴い変更が必要になることもあります。不足していると感じる箇所があれば、気兼ねなくお知らせください。 + ## 対象読者 -このガイドは、デフォルトでサポートされていない新しいプラットフォームまたは環境に wolfSSL および wolfCrypt を移植する開発者またはエンジニアを対象としています。 +このガイドは、wolfSSLおよびwolfCryptを、現在サポートされていない新しいプラットフォームまたは環境に移植するエンジニアを対象としています。 ## 序章 -組み込みプラットフォームで wolfSSL を実行するには、いくつかの手順を繰り返す必要があります。 これらの手順の一部は、[セクション 2.4](chapter02.md#非標準環境での構築) で概説されています。 +組み込みプラットフォームでwolfSSLを実行するには、いくつかの手順を繰り返す必要があります。これらの手順の一部は、[2.4章](chapter02.md#building-in-a-non-standard-environment) で概説しています。 -wolfSSL マニュアルの第 2 章の手順とは別に、特定のプラットフォームに対応するために移植または変更が必要なコードの領域があります。 wolfSSL はこれらの領域の多くを抽象化しており、wolfSSL を新しいプラットフォームに移植することをできるだけ簡単にしようとしています。 +wolfSSLドキュメント第2章に示した手順に加えて、特定のプラットフォームに対応するために移植または変更が必要なコード領域があります。wolfSSLはこれらの領域の多くを抽象化して、新しいプラットフォームへできるだけ簡単に移植できるようにしています。 -`./wolfssl/wolfcrypt/settings.h` ファイルには、さまざまなオペレーティング システム、TCP/IP スタック、およびチップセットに固有の定義がいくつかあります (例: MBED、FREESCALE_MQX、MICROCHIP_PIC32、MICRIUM、EBSNET など)。 wolfSSL をコンパイルして新しいプラットフォームに移植するときに、`#defines` を配置する主な場所が 2 つあります。 +`./wolfssl/wolfcrypt/settings.h` ファイルには、さまざまなオペレーティングシステム、TCP/IPスタック、およびチップセット (例: MBED、FREESCALE_MQX、MICROCHIP_PIC32、MICRIUM、EBSNET など) に固有の定義がいくつかあります。wolfSSLをコンパイルして新しいプラットフォームに移植するときに、`#defines` を配置する主な場所は2つあります。 -1. 通常、オペレーティング システムまたは TCP/IP スタック ポートの新しい定義は、wolfSSL の新しいポートが完成したときに `settings.h` ファイルに追加されます。 これにより、機能をオン/オフしたり、そのビルドの「デフォルト」にする必要があるビルド設定をカスタマイズしたりする簡単な方法が提供されます。 wolfSSL を新しいプラットフォームに移植する際に、このファイルに新しいカスタム定義を追加できます。 [GitHub](https://www.github.com/wolfssl/wolfssl) のマスター オープン ソース コード ブランチに wolfSSL のポートを提供することをお勧めします。 これにより、wolfSSL を最新の状態に保つことができ、wolfSSL プロジェクトが改善され前進するにつれて、さまざまなポートを最新の状態に保つことができます。 +1. オペレーティングシステムまたはTCP/IPスタックに対応するための新たなマクロ定義は、通常、wolfSSLのポーティングが完了すると、`settings.h` ファイルに追加しています。これにより、機能のオン/オフを簡単に切り替えたり、そのビルドの「デフォルト」となるビルド設定をカスタマイズしたりできます。wolfSSLを新しいプラットフォームに移植する際にも、このファイルに新しいカスタム定義を追加することでお使いいただけます。新しいプラットフォームへの移植が完了した際，もし差し支えなければ，wolfSSLの [Gitリポジトリ](https://www.github.com/wolfssl/wolfssl) にPull Requestを送信していただけると嬉しく思います。これにより、より多くの環境でwolfSSLを使用しやすくなります。 -2. 自分の変更を適切な wolfSSL に戻したくないユーザー、または追加のプリプロセッサー定義で wolfSSL ビルドをカスタマイズしたいユーザーの場合、wolfSSL はカスタム `user_settings.h` ヘッダー ファイルの使用を推奨します。 wolfSSL ソース ファイルをコンパイルするときに「WOLFSSL_USER_SETTINGS」が定義されている場合、wolfSSL は「user_settings.h」と呼ばれるカスタム ヘッダー ファイルを自動的にインクルードします。 このヘッダーはユーザーが作成し、インクルード パスに配置する必要があります。 これにより、ユーザーは自分の wolfSSL ビルド用に 1 つのファイルを維持でき、新しいバージョンの wolfSSL への更新がはるかに簡単になります。 +2. wolfSSL自体に変更を加えたくない場合、または追加のプリプロセッサ定義を使用して wolfSSLビルドをカスタマイズしたい場合、wolfSSLはカスタムヘッダーファイル`user_settings.h`の使用を推奨します。 wolfSSLソースファイルをコンパイルするときに `WOLFSSL_USER_SETTINGS` が定義されている場合、wolfSSLはカスタムヘッダーファイル `user_settings.h` を自動的にインクルードします。このヘッダーはユーザーが作成し、インクルードパスに配置する必要があります。これにより、ユーザーはwolfSSLビルド用に1つのファイルのみを管理すればよく、wolfSSLの新しいバージョンへの更新がはるかに簡単になります。 -wolfSSL は、直接メール ([facts@wolfssl.com](mailto:facts@wolfssl.com)) または [GitHub プル リクエスト](https://github.com/wolfssl/ wolfssl)。 +wolfSSLでは、直接のメール ([info@wolfssl.jp](mailto:infopwolfssl.jp)) または [GitHub Pull Request](https://github.com/wolfssl/wolfssl) を通じてパッチとコード変更をご送信いただくことを推奨しています。 ## wolfSSLの移植 @@ -29,12 +30,11 @@ wolfSSL は、直接メール ([facts@wolfssl.com](mailto:facts@wolfssl.com)) ### データ型 -**Q: どんな場合にこのセクションが必要ですか?** +**Q: どんな場合にこの章の内容が役立ちますか?** A: プラットフォームに適したデータ型のサイズを設定することは常に重要です。 -wolfSSL は、64 ビット タイプを使用できるため、速度が向上します。 プラットフォームの sizeof(long) と sizeof(long long) の結果と一致するように SIZEOF_LONG と SIZEOF_LONG_LONG を定義します。 これは、`settings.h` ファイルまたは `user_settings.h` のカスタム定義に追加できます。 たとえば、`MY_NEW_PLATFORM` のサンプル定義の下にある `settings.h` では: - +wolfSSL は、64ビット型を利用できることで速度面でメリットを得ています。プラットフォームの `sizeof(long)` と `sizeof(long long)` の結果と一致するように `SIZEOF_LONG` と `SIZEOF_LONG_LONG` を定義します。これは、`settings.h` または `user_settings.h` のカスタム定義に追加できます。たとえば、`MY_NEW_PLATFORM` のサンプル定義の下の `settings.h` では次のように示します。 ```c #ifdef MY_NEW_PLATFORM @@ -45,38 +45,37 @@ wolfSSL は、64 ビット タイプを使用できるため、速度が向上 ``` -`word32` と `word16` と呼ばれる、wolfSSL と wolfCrypt で使用される 2 つの追加のデータ型があります。 これらのデフォルトのタイプ マッピングは次のとおりです。 +wolfSSLとwolfCryptでは、`word32` と `word16` という2つの追加データ型を使用します。これらのデフォルトの型マッピングは次のとおりです。 ```c #ifndef WOLFSSL_TYPES #ifndef byte - typedef unsigned char byte + typedef unsigned char byte #endif -typedef unsigned short word16; - typedef unsigned int word32; - typedef byte word24[3]; + typedef unsigned short word16; + typedef unsigned int word32; + typedef byte word24[3]; #endif ``` -「word32」はコンパイラの 32 ビット型に、「word16」はコンパイラの 16 ビット型にマップする必要があります。 これらのデフォルトのマッピングがお使いのプラットフォームで正しくない場合は、`settings.h` または `user_settings.h` で `WOLFSSL_TYPES` を定義し、word32 と word16 に独自のカスタム typedef を割り当てる必要があります。 +`word32` はコンパイラの32ビット型にマッピングされ、`word16` はコンパイラの16ビット型にマッピングされます。これらのデフォルトのマッピングがプラットフォームに適していない場合は、`settings.h` または `user_settings.h` で `WOLFSSL_TYPES` を定義し、word32およびword16に独自のカスタムtypedefを割り当てる必要があります。 -wolfSSL の fastmath ライブラリは、`fp_digit` および `fp_word` タイプを使用します。 デフォルトでは、これらはビルド構成に応じて `` にマッピングされます。 +wolfSSLのfastmathライブラリは、`fp_digit` および `fp_word` 型を使用します。デフォルトでは、これらはビルド構成に応じて `` にマッピングされます。 -`fp_word` は `fp_digit` の 2 倍のサイズにする必要があります。 デフォルトのケースがプラットフォームに当てはまらない場合は、`settings.h` または `user_settings.h` で `WOLFSSL_BIGINT_TYPES` を定義し、`fp_word` と `fp_digit` に独自のカスタム typedef を割り当てる必要があります。 +`fp_word` は `fp_digit` の2倍のサイズである必要があります。デフォルトのケースがプラットフォームに当てはまらない場合は、`settings.h` または `user_settings.h` で `WOLFSSL_BIGINT_TYPES` を定義し、`fp_word` および `fp_digit` に独自のカスタムtypedefを割り当てる必要があります。 -一部の操作で利用可能な場合、wolfSSL は 64 ビット型を使用します。 wolfSSL ビルドは、`SIZEOF_LONG` と `SIZEOF_LONG_LONG` の設定に基づいて、`word64` の正しい基本データ型を検出して設定しようとします。 2 つの 32 ビット型が一緒に使用される、真の 64 ビット型を持たない一部のプラットフォームでは、パフォーマンスが低下する可能性があります。 64 ビット型の使用をコンパイルするには、「NO_64BIT」を定義します。 +wolfSSLは、一部の操作において使用可能な場合は64ビット型を使用します。ビルド時には、`SIZEOF_LONG` および `SIZEOF_LONG_LONG` の設定に基づいて、`word64` の正しいデータ型を検出して設定しようとします。 真の64ビット型を持たない一部のプラットフォームでは、2つの32ビット型を合わせて使用するため、パフォーマンスが低下する可能性があります。コンパイル時に`NO_64BIT`を定義することで，64ビット型を使用しないこともできます。 ### エンディアン -**Q: どんな場合にこのセクションが必要ですか?** +**Q: どんな場合にこの章の内容が役立ちますか?** -A: あなたのプラットフォームがビッグ エンディアンの場合です。 - -プラットフォームはビッグ エンディアンですか、それともリトル エンディアンですか? wolfSSL のデフォルトはリトル エンディアン システムです。 システムがビッグ エンディアンの場合、wolfSSL をビルドするときに `BIG_ENDIAN_ORDER` を定義します。 `settings.h` でこれを設定する例: +A: あなたのプラットフォームがビッグエンディアンの場合です。 +お使いのプラットフォームはビッグエンディアンとリトルエンディアン，どちらでしょうか．wolfSSLはデフォルトでリトルエンディアンを使用しています。システムがビッグエンディアンの場合は、wolfSSL をビルドする際に `BIG_ENDIAN_ORDER` を定義します。例えば，`settings.h` で次のように設定できます． ```c #ifdef MY_NEW_PLATFORM @@ -91,41 +90,41 @@ A: あなたのプラットフォームがビッグ エンディアンの場合 ### writev -**Q: どんな場合にこのセクションが必要ですか?** +**Q: どんな場合にこの章の内容が役立ちますか?** -A: `` は利用できない場合です。 +A: `` を利用できない場合です。 -デフォルトでは、wolfSSL API は、`writev()` セマンティクスをシミュレートする `wolfSSL_writev()` をアプリケーションで利用できるようにします。 `` ヘッダーが利用できないシステムでは、`NO_WRITEV` を定義してこの機能を除外します。 +デフォルトでは、wolfSSL APIは、`writev()` セマンティクスをシミュレートする `wolfSSL_writev()` をアプリケーションに提供します。 `` ヘッダーが利用できないシステムでは、`NO_WRITEV` を定義してこの機能を除外します。 -＃＃＃ 入出力 +### ネットワークI/O -**Q: どんな場合にこのセクションが必要ですか?** +**Q: どんな場合にこの章の内容が役立ちますか?** -A: BSD スタイルのソケット API は利用できない場合、カスタム トランスポート層または TCP/IP スタックを使用しているか、静的バッファのみを使用したい場合です。 +A: BSD スタイルのソケットAPIを利用できない、あるいはカスタムトランスポート層またはTCP/IPスタックを使用している、または静的バッファーのみを使用したい場合です。 -wolfSSL はデフォルトで BSD スタイルのソケット インターフェイスを使用します。 トランスポート層が BSD ソケット インターフェイスを提供する場合、カスタム ヘッダーが必要でない限り、wolfSSL はそのまま統合する必要があります。 +wolfSSLはデフォルトでBSDスタイルのソケットインターフェイスを使用します。トランスポート層がBSDソケットインターフェイスを提供する場合、カスタムヘッダーが必要でない限り、wolfSSLはそのまま統合する必要があります。 -wolfSSL はカスタム I/O 抽象化レイヤーを提供し、ユーザーは自分のシステムに合わせて wolfSSL の I/O 機能を調整できます。 詳細は [セクション 5.1.2 にあります](chapter05.md#custom-inputoutput-abstraction-layer)。 +wolfSSLはカスタムI/O抽象化レイヤーを提供し、ユーザーはwolfSSLのI/O機能をシステムに合わせて調整できます。詳細については、[5.1.2節](chapter05.md#custom-inputoutput-abstraction-layer) をご参照ください。 -簡単に言えば、`WOLFSSL_USER_IO` を定義してから、wolfSSL のデフォルトの `EmbedSend()` と `EmbedReceive()` をテンプレートとして使用して、独自の I/O コールバック関数を書くことができます。 これら 2 つの関数は `./src/io.c` にあります。 +具体的には `WOLFSSL_USER_IO` を定義し、wolfSSLデフォルトの `EmbedSend()` と `EmbedReceive()` をテンプレートとして使用し，独自のI/Oコールバック関数を記述します。これら2つの関数は `./src/io.c` にあります。 -wolfSSL は入力と出力に動的バッファを使用します。デフォルトは 0 バイトです。 バッファよりも大きなサイズの入力レコードが受信されると、動的バッファが一時的に使用されてリクエストが処理され、その後解放されます。 +wolfSSLは、入力と出力に動的バッファを使用します。このバッファのデフォルトは0バイトです。バッファよりも大きいサイズの入力レコードを受信した場合、動的バッファが一時的にリクエストの処理に使用され、その後解放されます。 -動的メモリをまったく必要としない大きな 16kB の静的バッファを使用したい場合は、`LARGE_STATIC_BUFFERS` を定義してこのオプションを有効にできます。 +動的メモリを必要としない16kBの大きな静的バッファを使用する場合は、`LARGE_STATIC_BUFFERS` を定義することでこのオプションを使用できます。 -動的バッファが使用され、ユーザーがバッファ サイズよりも大きい `wolfSSL_write()` を要求した場合、最大で `MAX_RECORD_SIZE` までの動的ブロックがデータの送信に使用されます。 `RECORD_SIZE` で定義されているように、最大で現在のバッファ サイズのチャンクでのみデータを送信したいユーザーは、`STATIC_CHUNKS_ONLY` を定義することでこれを行うことができます。 この定義を使用すると、「RECORD_SIZE」のデフォルトは 128 バイトになります。 +動的バッファが使用され、ユーザーがバッファサイズよりも大きい `wolfSSL_write()` を要求した場合、最大 `MAX_RECORD_SIZE` までの動的ブロックを使用してデータを送信します。`RECORD_SIZE` で定義されている現在のバッファサイズの最大のチャンクでのみデータを送信したいユーザーは、`STATIC_CHUNKS_ONLY` を定義することでこれを実現できます。この定義を使用する場合、`RECORD_SIZE` はデフォルトで 128 バイトになります。 -＃＃＃ ファイルシステム +### ファイルシステム -**Q: どんな場合にこのセクションが必要ですか?** +**Q: どんな場合にこの章の内容が役立ちますか?** -A: ファイル システムが利用できないか、標準のファイル システム機能が利用できないか、カスタム ファイル システムを使用している場合です。 +A: ファイルシステムを利用できない、あるいは標準のファイルシステム機能を利用できない、または独自のファイルシステムを使用している場合です。 -wolfSSL はファイルシステムを使用して、鍵と証明書を SSL セッションまたはコンテキストにロードします。 wolfSSL では、これらをメモリ バッファからロードすることもできます。 メモリ バッファを厳密に使用する場合、ファイルシステムは必要ありません。 +wolfSSLは、TLSセッションまたはコンテキストに鍵と証明書をロードするためにファイルシステムを使用します。wolfSSLでは、これらをメモリバッファからロードすることもできます。メモリバッファのみを使用する場合、ファイルシステムは必要ありません。 -ライブラリをビルドするときに `NO_FILESYSTEM` を定義することで、wolfSSL によるファイルシステムの使用を無効にすることができます。 これは、ファイルではなくメモリ バッファから証明書とキーをロードする必要があることを意味します。 `settings.h` でこれを設定する例: +ライブラリをビルドするときに `NO_FILESYSTEM` を定義することで、wolfSSLによるファイルシステムの使用を無効にできます。つまり、証明書と鍵はファイルではなくメモリバッファからロードする必要があります。`settings.h` で，以下のように設定できます． ```c @@ -137,18 +136,17 @@ wolfSSL はファイルシステムを使用して、鍵と証明書を SSL セ ``` -テスト キーと証明書のバッファは、`./wolfssl/certs_test.h` ヘッダー ファイルにあります。 これらは、`./certs` ディレクトリにある対応する証明書とキーに一致します。 +テスト用の鍵と証明書バッファーは、`./wolfssl/certs_test.h` ヘッダーファイルにあります。これらは、`./certs` ディレクトリにある対応する証明書や鍵と一致します。 -`certs_test.h` ヘッダー ファイルは、必要に応じて `./gencertbuf.pl` スクリプトを使用して更新できます。 `gencertbuf.pl` の中には、`fileList_1024` と `fileList_2048` の 2 つの配列があります。 キーのサイズに応じて、追加の証明書またはキーをそれぞれのアレイに追加することができ、DER 形式である必要があります。 上記の配列は、証明書/鍵ファイルの場所を目的のバッファー名にマップします。 `gencertbuf.pl` を変更した後、wolfSSL ルート ディレクトリから実行すると、`./wolfssl/certs_test.h` の証明書とキー バッファが更新されます。 +`certs_test.h` ヘッダーファイルは、必要に応じて `./gencertbuf.pl` スクリプトを使用して更新できます。`gencertbuf.pl` 内には、`fileList_1024` と `fileList_2048` の2つの配列があります。鍵サイズに応じて、追加の証明書またはキーをそれぞれの配列に追加できます。なお，DER形式である必要があります。上記の配列は、証明書・鍵ファイルの場所を目的のバッファー名にマップします。`gencertbuf.pl` を変更した後、wolfSSLルートディレクトリから実行すると、`./wolfssl/certs_test.h` の証明書・鍵のバッファーが更新されます。 -``` +```sh ./gencertbuf.pl ``` -デフォルト以外のファイルシステムを使用したい場合、ファイルシステム抽象化レイヤーは `./wolfssl/wolfcrypt/wc_port.h` にあります。 ここには、EBSNET、FREESCALE_MQX、MICRIUM など、さまざまなプラットフォームのファイル システム ポートが表示されます。 必要に応じて、プラットフォームのカスタム定義を追加できます。これにより、「XFILE」、「XFOPEN」、「XFSEEK」などでファイル システム関数を定義できます。たとえば、Micrium の µC/ OS(MICRIUM)は以下の通りです。 - +デフォルト以外のファイルシステムを使用する場合、ファイルシステム抽象化レイヤーは `./wolfssl/wolfcrypt/wc_port.h` にあります。ここには、EBSNET、FREESCALE_MQX、MICRIUM などのさまざまなプラットフォームのファイルシステムポートがあります。必要に応じて、プラットフォームのカスタム定義を追加できます。これにより、`XFILE`、`XFOPEN`、`XFSEEK` などを使用してファイルシステム関数を定義できます。たとえば、Micrium の µC/OS (MICRIUM) の `wc_port.h` のファイルシステムレイヤーは次のとおりです。 ```c #elif defined(MICRIUM) @@ -166,90 +164,97 @@ wolfSSL はファイルシステムを使用して、鍵と証明書を SSL セ ### スレッド化 -**Q: どんな場合にこのセクションが必要ですか?** +**Q: どんな場合にこの章の内容が役立ちますか?** -A: マルチスレッド環境で wolfSSL を使用したい、またはシングルスレッドモードでコンパイルしたい場合です。 +A: マルチスレッド環境でwolfSSLを使用したい、またはシングルスレッドモードでコンパイルしたい場合です。 -wolfSSL がシングル スレッド環境でのみ使用される場合、wolfSSL をコンパイルするときに `SINGLE_THREADED` を定義して wolfSSL ミューテックス レイヤーを無効にすることができます。 これにより、wolfSSL ミューテックス層を移植する必要がなくなります。 +wolfSSLをシングルスレッド環境でのみ使用する場合、wolfSSLをコンパイルするときに `SINGLE_THREADED` を定義することでwolfSSLミューテックスレイヤーを無効にできます。これにより、wolfSSLミューテックスレイヤーを移植する必要がなくなります。 -wolfSSL をマルチスレッド環境で使用する必要がある場合、wolfSSL ミューテックス レイヤーを新しい環境に移植する必要があります。 ミューテックス層は `./wolfssl/wolfcrypt/wc_port.h` と `./wolfcrypt/src/wc_port.c` にあります。 `wc_port.h` で新しいシステム用に `wolfSSL_Mutex` を定義する必要があります。 `wc_port.h` と `wc_port.c` を検索して、いくつかの既存のプラットフォーム ポート レイヤー (EBSNET、FREESCALE_MQX など) の例を確認できます。 +wolfSSLをマルチスレッド環境で使用する場合、wolfSSLミューテックスレイヤーを新しい環境に移植する必要があります。ミューテックスレイヤーは `./wolfssl/wolfcrypt/wc_port.h` および `./wolfcrypt/src/wc_port.c` にあります。新しいシステムでは、`wc_port.h` に `wolfSSL_Mutex` を定義し、`wc_port.c` にミューテックス関数 (`wc_InitMutex`、`wc_FreeMutex`、`wc_LockMutex`、`wc_UnLockMutex`) を定義する必要があります。`wc_port.h` と `wc_port.c` を検索すると、既存のプラットフォームポートレイヤー (EBSNET、FREESCALE_MQX など) の例を参照できます。 ### ランダムシード -**Q: どんな場合にこのセクションが必要ですか?** +**Q: どんな場合にこの章の内容が役立ちますか?** -A: `/dev/random` または `/dev/urandom` が利用できないか、ハードウェア RNG に統合したい場合です。 +A: `/dev/random` や `/dev/urandom` を利用できない、あるいはハードウェアRNGに統合する必要がある場合です。 -デフォルトでは、wolfSSL は `/dev/urandom` または `/dev/random` を使用して RNG シードを生成します。 `NO_DEV_RANDOM` 定義は、wolfSSL をビルドしてデフォルトの `GenerateSeed()` 関数を無効にするときに使用できます。 これが定義されている場合、ターゲット プラットフォームに固有のカスタムの `GenerateSeed()` 関数を `./wolfcrypt/src/random.c` に記述する必要があります。 これにより、可能であれば、ハードウェアベースのランダムエントロピーソースで wolfSSL の PRNG をシードできます。 +デフォルトでは、wolfSSLは `/dev/urandom` または `/dev/random` を使用して RNG シードを生成します。wolfSSLをビルドするときに `NO_DEV_RANDOM` 定義を使用して、デフォルトの `GenerateSeed()` 関数を無効にすることができます。これが定義されている場合は、ターゲットプラットフォームに固有の `./wolfcrypt/src/random.c` にカスタム `GenerateSeed()` 関数を記述する必要があります。これにより、ハードウェアベースのランダムエントロピーソースが利用可能な場合は、wolfSSLのPRNGにシードを設定できます。 `GenerateSeed()` の記述方法の例については、`./wolfcrypt/src/random.c` にある wolfSSL の既存の `GenerateSeed()` 実装を参照してください。 ### メモリー -**Q: どんな場合にこのセクションが必要ですか?** +**Q: どんな場合にこの章の内容が役立ちますか?** + +A: 標準のメモリ関数が利用できない、あるいはオプションの数学ライブラリ間のメモリ使用量の違いに関心がある場合です。 -A: 標準メモリ関数を利用できない場合、またはオプションの数学ライブラリ間のメモリ使用量の違いに関心がある場合です。 +wolfSSL本体はデフォルトで `malloc()` と `free()` の両方を使用します。旧来使用されてきた第1世代の整数演算ライブラリ(Normal Math)を使用する場合、wolfCryptは `realloc()` も使用します。 -wolfSSL は、デフォルトで `malloc()` と `free()` の両方を使用します。 通常の大整数演算ライブラリを使用する場合、wolfCrypt は `realloc()` も使用します。 +現在、整数演算ライブラリとして最初期に開発された第1世代のNormal Mathライブラリ、パブリックドメインのTFM(Tom's Fast Math)をベースに開発した第2世代のFast Mathライブラリ、SP(Single Precision)最適化を適用した第3世代のSP Mathライブラリが存在します。 +このうち、第2世代以降のFast Math, SP Mathライブラリでは、暗号操作において動的メモリを使用しません。 -デフォルトでは、wolfSSL/wolfCrypt は通常の大きな整数演算ライブラリを使用しますが、これはかなりの動的メモリを使用します。 wolfSSL をビルドするとき、fastmath ライブラリを有効にすることができます。これは高速であり、暗号操作に動的メモリを使用しません (すべてスタック上)。 fastmath を使用することで、wolfSSL は `realloc()` の実装をまったく必要としなくなります。 wolfSSL の SSL レイヤーはまだ動的メモリを使用しているため、「malloc()」と「free()」が引き続き必要です。 +メモリ使用量とスピードの観点から、私たちはSP Mathライブラリの使用を推奨しています。 +wolfSSL 5.4.0以降ではデフォルトで採用しており、第1世代のNormal Mathライブラリは廃止予定です。 +詳細は以下のページをご覧ください。 -big integer math ライブラリと fastmath ライブラリのリソース使用量 (スタック/ヒープ) の比較については、リソースの使用に関するドキュメントを参照してください。 +- [wolfSSLの新たな Multi-Precision 演算ライブラリ](https://wolfssl.jp/wolfblog/2021/02/03/multi-precision-math-library/) +- [wolfSSL Math Library Comparison Matrix](https://www.wolfssl.com/wolfssl-math-library-comparison-matrix/) +- [レガシー数学ライブラリを廃止します](https://wolfssl.jp/wolfblog/2023/03/13/deprecation-of-wolfssl-normal-math-library/) -fastmath を有効にするには、「USE_FAST_MATH」を定義し、「./wolfcrypt/src/integer.c」の代わりに「./wolfcrypt/src/tfm.c」をビルドします。 fastmath を使用するとスタックメモリが大きくなる可能性があるため、 TFM_TIMING_RESISTANT も定義することをお勧めします。 +wolfSSLのTLSレイヤーは依然としていくらかの動的メモリを使用するため、`malloc()` と `free()` は依然として必要です。 -通常の `malloc()`、`free()`、場合によっては `realloc()` 関数が利用できない場合は、`XMALLOC_USER` を定義してから、ターゲット環境に固有の `./wolfssl/wolfcrypt/types.h` にカスタム メモリ関数フックを提供します。 +通常の `malloc()`、`free()`、および場合によっては `realloc()` 関数が使用できない場合は、`XMALLOC_USER` を定義し、ターゲット環境に固有の `./wolfssl/wolfcrypt/types.h` でカスタムメモリ関数フックを提供します。 -`XMALLOC_USER` の使用に関する詳細については、[セクション 5.1.1.1 を読む](chapter05.md#memory-use) を参照してください。 +`XMALLOC_USER` の使用の詳細については、[5.1.1.1節](chapter05.md#memory-use) をご参照ください。 ### 時間 -**Q: どんな場合にこのセクションが必要ですか?** +**Q: どんな場合にこの章の内容が役立ちますか?** -A: 標準の時間関数 (`time()`、`gmtime()`) が利用できない場合、またはカスタムのクロック ティック関数を指定する必要がある場合です。 +A: 標準の時間関数 (`time()`、`gmtime()`) を利用できない、あるいはカスタムのクロックティック関数を指定する必要がある場合です。 -デフォルトでは、wolfSSL は `./wolfcrypt/src/asn.c` で指定されているように `time()`、`gmtime()`、および `ValidateDate()` を使用します。 これらは `XTIME`、`XGMTIME`、`XVALIDATE_DATE` に抽象化されます。 標準時間関数と time.h が利用できない場合、ユーザーは USER_TIME を定義できます。 `USER_TIME` を定義した後、ユーザーは独自の `XTIME`、`XGMTIME`、および `XVALIDATE_DATE` 関数を定義できます。 +デフォルトでは、wolfSSLは `./wolfcrypt/src/asn.c` で指定されているように、`time()`、`gmtime()`、および `ValidateDate()` を使用します。これらは、`XTIME`、`XGMTIME`、および `XVALIDATE_DATE` に抽象化されています。標準の時間関数と `time.h` を利用できない場合は、ユーザーは `USER_TIME` を定義できます。`USER_TIME` を定義した後、ユーザーは独自の `XTIME`、`XGMTIME`、および `XVALIDATE_DATE` 関数を定義できます。 -wolfSSL はデフォルトでクロック ティック関数に「time(0)」を使用します。 これは、`LowResTimer()` 関数内の `./src/internal.c` にあります。 +wolfSSLは、クロックティック関数にデフォルトで `time(0)` を使用します。これは、`LowResTimer()` 関数内の `./src/internal.c` にあります。 -`USER_TICKS` を定義すると、`time(0)` が不要な場合、ユーザーは独自のクロック ティック関数を定義できます。 カスタム関数には 2 番目の精度が必要ですが、EPOCH に関連付ける必要はありません。 `./src/internal.c` の `LowResTimer()` 関数を参照してください。 +`USER_TICKS` を定義すると、`time(0)` が必要ない場合にユーザーが独自のクロックティック関数を定義できるようになります。カスタム関数には秒単位の精度が必要ですが、エポックと相関させる必要はありません。参考として、`./src/internal.c` の `LowResTimer()` 関数を参照してください。 -### C 標準ライブラリ +### C標準ライブラリ -**Q: どんな場合にこのセクションが必要ですか?** +**Q: どんな場合にこの章の内容が役立ちますか?** -A: C 標準ライブラリが利用できない場合、またはカスタム ライブラリがある場合です。 +A: C標準ライブラリを使用できない、あるいは独自のライブラリがある場合です． -開発者に高いレベルの移植性と柔軟性を提供するために、C 標準ライブラリなしで wolfSSL を構築することができます。 その際、ユーザーは C 標準関数の代わりに使用したい関数をマップする必要があります。 +wolfSSLは、開発者に高いレベルの移植性と柔軟性を提供するために、C標準ライブラリなしで構築できるようにしています。その場合、ユーザーはC標準の関数の代わりに使用したい関数をマップする必要があります。 -上記のセクション 7 では、メモリ機能について説明しました。 メモリ関数の抽象化に加えて、wolfSSL は文字列関数と数学関数も抽象化します。特定の関数は通常、`X` の形式で定義に抽象化されます。ここで、`` は対象となる関数の名前です。 +第7章では、メモリ関数について説明しました。メモリ関数の抽象化に加えて、wolfSSLは文字列関数と数学関数も抽象化します。特定の関数は通常、`X` 形式の定義に抽象化されます。`` は抽象化される関数の名前です。 -詳細については、[セクション 5.1](chapter05.md) をお読みください。 +詳細については、[5.1章](chapter05.md) をご覧ください。 ### ロギング -**Q: どんな場合にこのセクションが必要ですか?** +**Q: どんな場合にこの章の内容が役立ちますか?** -A: デバッグ メッセージを有効にしたいが、利用可能な stderr が無い場合です。 +A: デバッグメッセージを有効にしたいが、stderr を使用できない場合です。 -デフォルトでは、wolfSSL は stderr を介してデバッグ出力を提供します。 デバッグ メッセージを有効にするには、`DEBUG_WOLFSSL` を定義して wolfSSL をコンパイルし、アプリケーション コードから `wolfSSL_Debugging_ON()` を呼び出す必要があります。 `wolfSSL_Debugging_OFF()` は、アプリケーション層で wolfSSL デバッグ メッセージをオフにするために使用できます。 +デフォルトでは、wolfSSLはstderrを介してデバッグ出力を提供します。デバッグメッセージを有効にするには、wolfSSLを `DEBUG_WOLFSSL` を定義してコンパイルし、アプリケーションコードから `wolfSSL_Debugging_ON()` を呼び出す必要があります。同様に，アプリケーションから`wolfSSL_Debugging_OFF()` を呼び出すことで、wolfSSLデバッグメッセージをオフにすることもできます。 -stderr を使用できない環境、またはデバッグ メッセージを別の出力ストリームまたは別の形式で出力したい環境では、アプリケーションがロギング コールバックを登録できます。 +stderrを使用できない，あるいは別の出力ストリームや別の形式でデバッグメッセージを出力したい環境には、独自のコールバック関数を使用できるようにしています． -詳細については、[セクション 8.1](chapter08.md) をお読みください。 +詳細については、[8.1章](chapter08.md) をご覧ください。 ### 公開鍵操作 -**Q: どんな場合にこのセクションが必要ですか?** +**Q: どんな場合にこの章の内容が役立ちますか?** -A: wolfSSL で独自の公開鍵の実装を使用したい場合です。 +A: wolfSSLで独自の公開鍵実装を使用したい場合です。 -wolfSSL では、SSL/TLS レイヤーが公開鍵操作を行う必要があるときに呼び出される独自の公開鍵コールバックをユーザーが作成できます。 ユーザーはオプションで 6 つの機能を定義できます。 +wolfSSLでは、SSL/TLSレイヤーが公開鍵操作を行う必要があるときに呼び出される，独自の公開鍵コールバックをユーザーが作成できます。 ユーザーはオプションで6つの機能を定義できます。 @@ -258,67 +263,66 @@ wolfSSL では、SSL/TLS レイヤーが公開鍵操作を行う必要がある 3. RSA 署名 コールバック 4. RSA 検証 コールバック 5. RSA 暗号化コールバック -6. RSA 復号化コールバック +6. RSA 復号 コールバック -詳細については、[セクション 6.4](chapter06.md#public-key-callbacks) をお読みください。 +詳細については、[6.4章](chapter06.md#public-key-callbacks) をご覧ください。 -### アトミック レコード レイヤーの処理 +### アトミックレコードレイヤーの処理 -**Q: どんな場合にこのセクションが必要ですか?** +**Q: どんな場合にこの章の内容が役立ちますか?** -A: レコード レイヤーの独自の処理、特に MAC/暗号化および復号化/検証操作を行いたい場合です。 +A: レコードレイヤーの処理、特にMAC/暗号化および復号/検証操作を独自に実行したい場合です。 -デフォルトでは、wolfSSL はその暗号化ライブラリである wolfCrypt を使用して、ユーザーのレコード層処理を処理します。 wolfSSL は、SSL/TLS 接続中に MAC/暗号化および復号化/検証機能をより詳細に制御したいユーザーのために、アトミック レコード処理コールバックを提供します。 +デフォルトでは、wolfSSLは暗号ライブラリwolfCryptを使用し、ユーザーに代わってレコードレイヤーの処理を行います。wolfSSLは、SSL/TLS接続中に MAC/暗号化および復号/検証機能をより細かく制御したいユーザーのために、アトミックレコード処理コールバックを提供します。 -ユーザーは 2 つの関数を定義する必要があります。 +ユーザーは2つの関数を定義できます． -1.MAC/暗号化 コールバック関数 -2.復号化/検証コールバック関数 +1. MAC/暗号化コールバック関数 +2. 復号/検証コールバック関数 -詳細については、[セクション 6.3](chapter06.md#user-atomic-record-layer-processing) をお読みください。 +詳細については、[6.3章](chapter06.md#user-atomic-record-layer-processing) をご覧ください． ### 機能 -**Q: どんな場合にこのセクションが必要ですか?** +**Q: どんな場合にこの章の内容が役立ちますか?** A: 特定の機能を無効にしたい場合です。 -適切な定義を使用して wolfSSL を構築するときに、機能を無効にすることができます。 利用可能な定義のリストについては、[第 2 章](chapter02.md) を参照してください。 +wolfSSLをビルドする際，マクロ定義を使用して特定の機能を無効化できます。 +使用可能なマクロ定義については、[2章](chapter02.md) をご覧ください。 ## 次のステップ -### wolfCrypt テストアプリケーション +### wolfCryptテストアプリケーション -wolfSSL をターゲット プラットフォーム上でビルドできるようになったら、次の適切なステップは wolfCrypt テスト アプリケーションを移植することです。 このアプリケーションをターゲット システムで実行すると、NIST テスト ベクトルを使用して、すべての暗号化アルゴリズムが正しく機能していることを確認できます。 +wolfSSLをターゲットプラットフォームで適切にビルドできるようになったら、次のステップとして wolfCryptテストアプリケーションを移植するのがよいでしょう。このアプリケーションをターゲットシステムで実行すると、NISTテストベクトルを使用して、すべての暗号アルゴリズムが正しく動作しているかどうか検証されます。 -この手順をスキップして、代わりに SSL 接続の確立に直接進むと、基になる暗号化操作の失敗によって発生する問題のデバッグがより困難になる可能性があります。 +このステップを省略してSSL/TLS接続に進むと、基盤となる暗号操作の失敗によって発生する問題のデバッグが難しくなる可能性があります。 -wolfCrypt テスト アプリケーションは `./wolfcrypt/test/test.c` にあります。 組み込みアプリケーションに独自の `main()` 関数がある場合、`./wolfcrypt/test/test.c` をコンパイルするときに `NO_MAIN_DRIVER` を定義する必要があります。 これにより、アプリケーションの `main()` は、各暗号/アルゴリズム テストを独自に個別に呼び出すことができます。 +wolfCryptテストアプリケーションは `./wolfcrypt/test/test.c` にあります。組み込みアプリケーションに独自の `main()` 関数がある場合は、`./wolfcrypt/test/test.c` をコンパイルするときに `NO_MAIN_DRIVER` を定義する必要があります。これにより、アプリケーションの `main()` が各暗号/アルゴリズム テストを個別に呼び出すことができます。 -組み込みデバイスに wolfCrypt テスト アプリケーション全体を実行するのに十分なリソースがない場合、個々のテストを `test.c` から分割して個別にコンパイルできます。 `test.c` から分離された暗号テストを抽出するときは、特定のテスト ケースに必要な正しいヘッダー ファイルがビルドに含まれていることを確認してください。 +組み込みデバイスにwolfCryptテストアプリケーション全体を実行するのに十分なリソースがない場合は、個々のテストを `test.c` から切り離して個別にコンパイルできます。 `test.c` から分離された暗号テストを抽出するときは、特定のテストケースに必要な正しいヘッダーファイルがビルドに含まれていることを確認してください。 ## サポート -一般的なサポートの質問は、電子メール、サポート フォーラム、または wolfSSL の Zendesk チケット トラッキング システムを介して wolfSSL に直接送信できます。 - -Website: [https://www.wolfssl.com](https://www.wolfssl.com) +一般的なサポートの質問は、メール、サポートフォーラム(英語)、またはwolfSSLのZendeskチケットトラッキングシステムを介してwolfSSLに直接送信できます。 -Support Email: [support@wolfssl.com](mailto:support@wolfssl.com) +Webサイト: [https://www.wolfssl.com](https://www.wolfssl.com) -Zendesk: [https://wolfssl.zendesk.com](https://wolfssl.zendesk.com) +サポート用メールアドレス: [support@wolfssl.com](mailto:support@wolfssl.com) -Forums: [https://www.wolfssl.com/forums](https://www.wolfssl.com/forums) +Zendesk: [https://wolfssl.zendesk.com](https://wolfssl.zendesk.com) -wolfSSL は、ユーザーと顧客が wolfSSL を新しい環境に移植するのを支援するために、いくつかのサポート パッケージとコンサルティング サービスを提供しています。 +フォーラム: [https://www.wolfssl.com/forums](https://www.wolfssl.com/forums) -Support Packages: [https://www.wolfssl.com/wolfSSL/Support/support_tiers.php](https://www.wolfssl.com/wolfSSL/Support/support_tiers.php) +wolfSSLは、ユーザーと顧客がwolfSSLを新しい環境に移植するのを支援するために、いくつかのサポートパッケージとコンサルティングサービスを提供しています。 -Consulting Services: [https://www.wolfssl.com/wolfSSL/wolfssl-consulting.html](https://www.wolfssl.com/wolfSSL/wolfssl-consulting.html) +サポートパッケージ: [https://wolfssl.jp/license/support-packages/](https://wolfssl.jp/license/support-packages/) -General Inquiries: [facts@wolfssl.com](mailto:facts@wolfssl.com) +お問い合わせ: [info@wolfssl.jp](mailto:info@wolfssl.jp)