暗号化の質問

Question

I asked a question hereと私は部分的にアドバイスを実装することができます。 aes-256暗号化を取り除いた後、aes-128（デフォルト）のコード署名者の暗号化を残した後、データはバイナリフィールド（varbinary（500））で暗号化されて保存されます。

しかし、私はいくつかの質問があります。私はこのテーマに関して多くの記事を見つけることができないので、答えを見つけることができません。誰でも私の質問に答えたり、本を教えたり、さらに読んで、私は非常に感謝します。

1. なぜ暗号化されたデータをバイナリタイプのフィールドに格納する必要がありますか？それをlongtext、またはvarcharに格納するのは何が問題なのですか？それは暗号化を無価値にしますか？

2. なぜ私は変数をエンコードし、データをバイナリタイプのフィールドに格納するときにそれを暗号化し、varcharフィールドにデータを格納するときにそれを行う必要はないのですか？私の前の質問で

   base64_encode($clientName); 
   
   $encClientName = $this->encryption->encrypt($clientName); 
   

3. （一番上のリンクを参照してください）私はnonceを使用することをお勧めされています。私はcodeigniterライブラリでそれを使う方法を知らなかったので、私はその部分を実装しませんでした。それは私のデータの安全性を低下させますか？誰でもnonceをcodeigniterで使用する方法のスニペットコードを投稿できますか？

この件に関する資料を読む（phpを使用してデータベースに暗号化されたデータを保存する）ためのリンクもありがたく思います。

Answer 1

なぜ暗号化されたデータをバイナリタイプのフィールドに格納する必要がありますか？それをlongtext、またはvarcharに格納するのは何が問題なのですか？それは暗号化を無価値にしますか？

暗号化されたデータはバイナリです。頻繁にテキストエンコーディングで無効なバイトシーケンスが含まれているため、文字列（VARCHARやTEXTなど）が必要な列に挿入できなくなります。

VARBINARY（文字列ではなくVARCHARに似ています）またはBLOB（同様にTEXTではMEDIUMBLOB、LONGBLOBなどもあります）のいずれかのデータ型が必要です。

なぜ私は変数をエンコードし、バイナリタイプのフィールドにデータを格納するときに暗号化しなければならないのですか？varcharフィールドにデータを格納すると、その必要はありません。

あなたはありません。これは後方です。

暗号化されたデータを格納するために文字列型の列を使用する場合は、のコードをBase64で暗号化して暗号化した後に "偽造"できます。ただし、バイナリタイプの列を使用する方が優れています。追加のエンコーディングは必要ありません。

これまでの質問（上のリンクを参照）では、ノンスを使用することをお勧めしました。私はcodeigniterライブラリでそれを使う方法を知らなかったので、私はその部分を実装しませんでした。それは私のデータの安全性を低下させますか？

ドキュメンテーションには、CodeIgniter Encryptionライブラリがデフォルトで処理すると思います。あなたは何か追加する必要はありません。

Answer 2

duskwuffsの回答に加えて、私は暗号関連の観点から質問をカバーしました。私は前に彼はちょうど分を投稿するために管理:)

---

暗号化されたデータが原因文字エンコーディングが作業そのようにバイナリ型フィールドに格納する必要があります。私はあなたがまだ読んでいない場合は、この非常によくその詳細this excellent article by Joel Spolskyをお勧めします。

暗号化アルゴリズムは生のバイナリデータで動作することを覚えておくことが重要です。つまり、ビット列。多くの方法で解釈できる1と0のリテラル。このデータは、符号なしバイト値（255,255）、16進数（0xFF、0xFF）など、実際にはちょうどビット列の下に表すことができます。暗号化アルゴリズムのもう1つの特性（または少なくとも良い点）は、暗号化の結果がランダムなデータと区別できないことです。つまり、暗号化されたファイルとCSPRNGのブロブが同じ長さのランダムデータを生成した場合、どのデータがどれであるかを判断できません。

ここでは、このデータをUTF8文字列が必要なフィールドに格納すると仮定します。上記のように、このフィールドに格納するビット列にはの可能なシーケンスが含まれている可能性があるため、格納するバイトシーケンスは実際の有効なUTF8文字を示すものとはみなせません。これは、UTF8にエンコードされバイナリにデコードされたバイナリデータが元のバイナリデータを保証するものではないことを意味します。実際、それはまれです。

---

2番目の質問は、エンコードとは多少関係がありますが、ここでのエンコードはbase64です。 Base64は、バイナリデータ（非常にうまく設計されている）でうまく演奏するエンコードです。 Base64は、ほとんどの実装で共通文字（a-z、A-Z、0-9および+、/）を使用してバイナリデータを表現する方法です。使用しているencrypt関数のどちらかがbase64_decodeを使用するか、それが呼び出す関数のいずれかが使用されていることを喜んで賭けています。実際に関心を持つものは、encrypt関数の出力がbase64文字列か実際のバイナリデータかどうかです。これは、データベースで使用するデータフィールドのタイプ（バイナリvs varcharなど）に影響します。

---

CTRを使用していたと最後に質問したので、CTRのみが使用するnonceには次のようになります。

CTRはカウンタ値を暗号化し、この暗号化されたカウンタ値をデータで消去します。このカウンタの値はノンスとカウンターの実際の値の2つで構成され、通常は0から始まります。ノンスの長さは任意ですが、一般的な値は12バイトと考えられます。我々はAESについて議論しているので、カウンタ値の合計サイズは16バイトでなければならない。つまり、12バイトのnonceと4バイトのカウンタです。

これは重要な部分です。すべての暗号化操作は、次のように行う必要があります。

• この操作に使用する新しい12バイトのnonceを生成します。
• 実装では、カウンタを追加して実際の暗号化を実行する必要があります。
• 最終的な暗号テキストを取得したら、結果がlen(ciphertext) + 12)バイトになるようにこの暗号テキストにナンスを付加します。
• この最終結果をデータベースに保存します。

固定ナンスを使用するか、1回の12バイトのnonceを使用して2回以上の32回の暗号化操作を実行すると、暗号文が脆弱になります。