diff --git a/wolfBoot/src-ja/chapter06.md b/wolfBoot/src-ja/chapter06.md index e37f8cf4..954c7d0b 100644 --- a/wolfBoot/src-ja/chapter06.md +++ b/wolfBoot/src-ja/chapter06.md @@ -199,7 +199,7 @@ ED25519鍵を使ってKeyStoreを作成する例を示します： - first.der 第1の秘密鍵 - second.der 第2の秘密鍵 -- src/keystore.c 第１，第２の秘密鍵に対応した2つの公開鍵を含んだC KeyStore +- src/keystore.c 第１、第２の秘密鍵に対応した2つの公開鍵を含んだC KeyStore keystore.cは以下の様に見えるはずです： diff --git a/wolfProvider/src-ja/chapter04.md b/wolfProvider/src-ja/chapter04.md index f61750d8..0cfd4353 100644 --- a/wolfProvider/src-ja/chapter04.md +++ b/wolfProvider/src-ja/chapter04.md @@ -1,6 +1,6 @@ # FIPS 140-2のサポート -wolfProviderは，FIPSで検証されたバージョンのwolfCryptに対して適切にコンパイルされた場合にのみ、FIPS140-2に対応した動作を行うよう設計しています。 +wolfProviderは、FIPSで検証されたバージョンのwolfCryptに対して適切にコンパイルされた場合にのみ、FIPS140-2に対応した動作を行うよう設計しています。 この使用シナリオには、wolfSSL Inc. から入手した、適切にライセンスされ、検証されたバージョンのwolfCryptが必要です。 wolfCrypt FIPSライブラリは、非FIPSモードに「切り替える」ことができません。 diff --git a/wolfSSL-Porting/src-ja/section01.md b/wolfSSL-Porting/src-ja/section01.md index 5fc57ca5..d0d084f2 100644 --- a/wolfSSL-Porting/src-ja/section01.md +++ b/wolfSSL-Porting/src-ja/section01.md @@ -15,7 +15,7 @@ wolfSSLドキュメント第2章に示した手順に加えて、特定のプラ `./wolfssl/wolfcrypt/settings.h` ファイルには、さまざまなオペレーティングシステム、TCP/IPスタック、およびチップセット (例: MBED、FREESCALE_MQX、MICROCHIP_PIC32、MICRIUM、EBSNET など) に固有の定義がいくつかあります。wolfSSLをコンパイルして新しいプラットフォームに移植するときに、`#defines` を配置する主な場所は2つあります。 -1. オペレーティングシステムまたはTCP/IPスタックに対応するための新たなマクロ定義は、通常、wolfSSLのポーティングが完了すると、`settings.h` ファイルに追加しています。これにより、機能のオン/オフを簡単に切り替えたり、そのビルドの「デフォルト」となるビルド設定をカスタマイズしたりできます。wolfSSLを新しいプラットフォームに移植する際にも、このファイルに新しいカスタム定義を追加することでお使いいただけます。新しいプラットフォームへの移植が完了した際，もし差し支えなければ，wolfSSLの [Gitリポジトリ](https://www.github.com/wolfssl/wolfssl) にPull Requestを送信していただけると嬉しく思います。これにより、より多くの環境で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の新しいバージョンへの更新がはるかに簡単になります。 diff --git a/wolfSSL-Porting/src-ja/section02.md b/wolfSSL-Porting/src-ja/section02.md index 8de41d91..d40733b2 100644 --- a/wolfSSL-Porting/src-ja/section02.md +++ b/wolfSSL-Porting/src-ja/section02.md @@ -38,7 +38,7 @@ wolfSSLのfastmathライブラリは、`fp_digit` および `fp_word` 型を使 `fp_word` は `fp_digit` の2倍のサイズである必要があります。デフォルトのケースがプラットフォームに当てはまらない場合は、`settings.h` または `user_settings.h` で `WOLFSSL_BIGINT_TYPES` を定義し、`fp_word` および `fp_digit` に独自のカスタムtypedefを割り当てる必要があります。 -wolfSSLは、一部の操作において使用可能な場合は64ビット型を使用します。ビルド時には、`SIZEOF_LONG` および `SIZEOF_LONG_LONG` の設定に基づいて、`word64` の正しいデータ型を検出して設定しようとします。 真の64ビット型を持たない一部のプラットフォームでは、2つの32ビット型を合わせて使用するため、パフォーマンスが低下する可能性があります。コンパイル時に`NO_64BIT`を定義することで，64ビット型を使用しないこともできます。 +wolfSSLは、一部の操作において使用可能な場合は64ビット型を使用します。ビルド時には、`SIZEOF_LONG` および `SIZEOF_LONG_LONG` の設定に基づいて、`word64` の正しいデータ型を検出して設定しようとします。 真の64ビット型を持たない一部のプラットフォームでは、2つの32ビット型を合わせて使用するため、パフォーマンスが低下する可能性があります。コンパイル時に`NO_64BIT`を定義することで、64ビット型を使用しないこともできます。 ## エンディアン @@ -47,7 +47,7 @@ wolfSSLは、一部の操作において使用可能な場合は64ビット型 A: あなたのプラットフォームがビッグエンディアンの場合です。 -お使いのプラットフォームはビッグエンディアンとリトルエンディアン，どちらでしょうか．wolfSSLはデフォルトでリトルエンディアンを使用しています。システムがビッグエンディアンの場合は、wolfSSL をビルドする際に `BIG_ENDIAN_ORDER` を定義します。例えば，`settings.h` で次のように設定できます． +お使いのプラットフォームはビッグエンディアンとリトルエンディアン、どちらでしょうか。wolfSSLはデフォルトでリトルエンディアンを使用しています。システムがビッグエンディアンの場合は、wolfSSL をビルドする際に `BIG_ENDIAN_ORDER` を定義します。例えば、`settings.h` で次のように設定できます。 ```c #ifdef MY_NEW_PLATFORM @@ -77,7 +77,7 @@ wolfSSLはデフォルトでBSDスタイルのソケットインターフェイ wolfSSLはカスタムI/O抽象化レイヤーを提供し、ユーザーはwolfSSLのI/O機能をシステムに合わせて調整できます。詳細については、[5.1.2節](https://www.wolfssl.com/documentation/manuals/jp/wolfssl/chapter05.html#_2) をご参照ください。 -具体的には `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バイトです。バッファよりも大きいサイズの入力レコードを受信した場合、動的バッファが一時的にリクエストの処理に使用され、その後解放されます。 @@ -94,7 +94,7 @@ A: ファイルシステムを利用できない、あるいは標準のファ wolfSSLは、TLSセッションまたはコンテキストに鍵と証明書をロードするためにファイルシステムを使用します。wolfSSLでは、これらをメモリバッファからロードすることもできます。メモリバッファのみを使用する場合、ファイルシステムは必要ありません。 -ライブラリをビルドするときに `NO_FILESYSTEM` を定義することで、wolfSSLによるファイルシステムの使用を無効にできます。つまり、証明書と鍵はファイルではなくメモリバッファからロードする必要があります。`settings.h` で，以下のように設定できます． +ライブラリをビルドするときに `NO_FILESYSTEM` を定義することで、wolfSSLによるファイルシステムの使用を無効にできます。つまり、証明書と鍵はファイルではなくメモリバッファからロードする必要があります。`settings.h` で、以下のように設定できます。 ```c #ifdef MY_NEW_PLATFORM @@ -106,7 +106,7 @@ wolfSSLは、TLSセッションまたはコンテキストに鍵と証明書を テスト用の鍵と証明書バッファーは、`./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 @@ -194,7 +194,7 @@ wolfSSLは、クロックティック関数にデフォルトで `time(0)` を **Q: どんな場合にこの章の内容が役立ちますか?** -A: C標準ライブラリを使用できない、あるいは独自のライブラリがある場合です． +A: C標準ライブラリを使用できない、あるいは独自のライブラリがある場合です。 wolfSSLは、開発者に高いレベルの移植性と柔軟性を提供するために、C標準ライブラリなしで構築できるようにしています。その場合、ユーザーはC標準の関数の代わりに使用したい関数をマップする必要があります。 @@ -209,9 +209,9 @@ wolfSSLは、開発者に高いレベルの移植性と柔軟性を提供する A: デバッグメッセージを有効にしたいが、stderr を使用できない場合です。 -デフォルトでは、wolfSSLはstderrを介してデバッグ出力を提供します。デバッグメッセージを有効にするには、wolfSSLを `DEBUG_WOLFSSL` を定義してコンパイルし、アプリケーションコードから `wolfSSL_Debugging_ON()` を呼び出す必要があります。同様に，アプリケーションから`wolfSSL_Debugging_OFF()` を呼び出すことで、wolfSSLデバッグメッセージをオフにすることもできます。 +デフォルトでは、wolfSSLはstderrを介してデバッグ出力を提供します。デバッグメッセージを有効にするには、wolfSSLを `DEBUG_WOLFSSL` を定義してコンパイルし、アプリケーションコードから `wolfSSL_Debugging_ON()` を呼び出す必要があります。同様に、アプリケーションから`wolfSSL_Debugging_OFF()` を呼び出すことで、wolfSSLデバッグメッセージをオフにすることもできます。 -stderrを使用できない，あるいは別の出力ストリームや別の形式でデバッグメッセージを出力したい環境には、独自のコールバック関数を使用できるようにしています． +stderrを使用できない、あるいは別の出力ストリームや別の形式でデバッグメッセージを出力したい環境には、独自のコールバック関数を使用できるようにしています。 詳細については、wolfSSLマニュアルの[8.1節](https://www.wolfssl.com/documentation/manuals/jp/wolfssl/chapter08.html#_2)をお読みください。 @@ -222,7 +222,7 @@ stderrを使用できない，あるいは別の出力ストリームや別の A: wolfSSLで独自の公開鍵実装を使用したい場合です。 -wolfSSLでは、SSL/TLSレイヤーが公開鍵操作を行う必要があるときに呼び出される，独自の公開鍵コールバックをユーザーが作成できます。 ユーザーはオプションで6つの機能を定義できます。 +wolfSSLでは、SSL/TLSレイヤーが公開鍵操作を行う必要があるときに呼び出される、独自の公開鍵コールバックをユーザーが作成できます。 ユーザーはオプションで6つの機能を定義できます。 1. ECC 署名 コールバック 2. ECC 検証 コールバック @@ -242,7 +242,7 @@ A: レコードレイヤーの処理、特にMAC/暗号化および復号/検証 デフォルトでは、wolfSSLは暗号ライブラリwolfCryptを使用し、ユーザーに代わってレコードレイヤーの処理を行います。wolfSSLは、SSL/TLS接続中に MAC/暗号化および復号/検証機能をより細かく制御したいユーザーのために、アトミックレコード処理コールバックを提供します。 -ユーザーは2つの関数を定義できます． +ユーザーは2つの関数を定義できます。 1. MAC/暗号化コールバック関数 2. 復号/検証コールバック関数 @@ -256,5 +256,5 @@ A: レコードレイヤーの処理、特にMAC/暗号化および復号/検証 A: 特定の機能を無効にしたい場合です。 -wolfSSLをビルドする際，マクロ定義を使用して特定の機能を無効化できます。 +wolfSSLをビルドする際、マクロ定義を使用して特定の機能を無効化できます。 使用可能なマクロ定義については、wolfSSLマニュアルの[2章](https://www.wolfssl.com/documentation/manuals/jp/wolfssl/chapter02.html)をご覧ください。 \ No newline at end of file