Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion wolfBoot/src-ja/chapter06.md
Original file line number Diff line number Diff line change
Expand Up @@ -199,7 +199,7 @@ ED25519鍵を使ってKeyStoreを作成する例を示します:

- first.der 第1の秘密鍵
- second.der 第2の秘密鍵
- src/keystore.c 第1第2の秘密鍵に対応した2つの公開鍵を含んだC KeyStore
- src/keystore.c 第1第2の秘密鍵に対応した2つの公開鍵を含んだC KeyStore

keystore.cは以下の様に見えるはずです:

Expand Down
2 changes: 1 addition & 1 deletion wolfProvider/src-ja/chapter04.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# FIPS 140-2のサポート

wolfProviderはFIPSで検証されたバージョンのwolfCryptに対して適切にコンパイルされた場合にのみ、FIPS140-2に対応した動作を行うよう設計しています。
wolfProviderはFIPSで検証されたバージョンのwolfCryptに対して適切にコンパイルされた場合にのみ、FIPS140-2に対応した動作を行うよう設計しています。
この使用シナリオには、wolfSSL Inc. から入手した、適切にライセンスされ、検証されたバージョンのwolfCryptが必要です。

wolfCrypt FIPSライブラリは、非FIPSモードに「切り替える」ことができません。
Expand Down
2 changes: 1 addition & 1 deletion wolfSSL-Porting/src-ja/section01.md
Original file line number Diff line number Diff line change
Expand Up @@ -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の新しいバージョンへの更新がはるかに簡単になります。

Expand Down
22 changes: 11 additions & 11 deletions wolfSSL-Porting/src-ja/section02.md
Original file line number Diff line number Diff line change
Expand Up @@ -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ビット型を使用しないこともできます。


## エンディアン
Expand All @@ -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
Expand Down Expand Up @@ -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バイトです。バッファよりも大きいサイズの入力レコードを受信した場合、動的バッファが一時的にリクエストの処理に使用され、その後解放されます。

Expand All @@ -94,7 +94,7 @@ A: ファイルシステムを利用できない、あるいは標準のファ

wolfSSLは、TLSセッションまたはコンテキストに鍵と証明書をロードするためにファイルシステムを使用します。wolfSSLでは、これらをメモリバッファからロードすることもできます。メモリバッファのみを使用する場合、ファイルシステムは必要ありません。

ライブラリをビルドするときに `NO_FILESYSTEM` を定義することで、wolfSSLによるファイルシステムの使用を無効にできます。つまり、証明書と鍵はファイルではなくメモリバッファからロードする必要があります。`settings.h` で以下のように設定できます
ライブラリをビルドするときに `NO_FILESYSTEM` を定義することで、wolfSSLによるファイルシステムの使用を無効にできます。つまり、証明書と鍵はファイルではなくメモリバッファからロードする必要があります。`settings.h` で以下のように設定できます

```c
#ifdef MY_NEW_PLATFORM
Expand All @@ -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
Expand Down Expand Up @@ -194,7 +194,7 @@ wolfSSLは、クロックティック関数にデフォルトで `time(0)` を

**Q: どんな場合にこの章の内容が役立ちますか?**

A: C標準ライブラリを使用できない、あるいは独自のライブラリがある場合です
A: C標準ライブラリを使用できない、あるいは独自のライブラリがある場合です

wolfSSLは、開発者に高いレベルの移植性と柔軟性を提供するために、C標準ライブラリなしで構築できるようにしています。その場合、ユーザーはC標準の関数の代わりに使用したい関数をマップする必要があります。

Expand All @@ -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)をお読みください。

Expand All @@ -222,7 +222,7 @@ stderrを使用できない,あるいは別の出力ストリームや別の

A: wolfSSLで独自の公開鍵実装を使用したい場合です。

wolfSSLでは、SSL/TLSレイヤーが公開鍵操作を行う必要があるときに呼び出される独自の公開鍵コールバックをユーザーが作成できます。 ユーザーはオプションで6つの機能を定義できます。
wolfSSLでは、SSL/TLSレイヤーが公開鍵操作を行う必要があるときに呼び出される独自の公開鍵コールバックをユーザーが作成できます。 ユーザーはオプションで6つの機能を定義できます。

1. ECC 署名 コールバック
2. ECC 検証 コールバック
Expand All @@ -242,7 +242,7 @@ A: レコードレイヤーの処理、特にMAC/暗号化および復号/検証

デフォルトでは、wolfSSLは暗号ライブラリwolfCryptを使用し、ユーザーに代わってレコードレイヤーの処理を行います。wolfSSLは、SSL/TLS接続中に MAC/暗号化および復号/検証機能をより細かく制御したいユーザーのために、アトミックレコード処理コールバックを提供します。

ユーザーは2つの関数を定義できます
ユーザーは2つの関数を定義できます

1. MAC/暗号化コールバック関数
2. 復号/検証コールバック関数
Expand All @@ -256,5 +256,5 @@ A: レコードレイヤーの処理、特にMAC/暗号化および復号/検証

A: 特定の機能を無効にしたい場合です。

wolfSSLをビルドする際マクロ定義を使用して特定の機能を無効化できます。
wolfSSLをビルドする際マクロ定義を使用して特定の機能を無効化できます。
使用可能なマクロ定義については、wolfSSLマニュアルの[2章](https://www.wolfssl.com/documentation/manuals/jp/wolfssl/chapter02.html)をご覧ください。