暗号化でBase64エンコーディングを使用することのセキュリティへの影響
使用する前にバイト配列の暗号化キーをBase64文字列に変換することによるセキュリティへの影響はありますか？
プロジェクトの汎用暗号化ヘルパーを作成しています。一貫性と一般性のために、すべての入力と出力（プレーンデータ、キー、ソルトなど）にバイト配列を使用しています
ただし、内部で使用する暗号化ライブラリは文字列を想定しています。使用前にキーをbase64文字列としてエンコードすると、エントロピーなどの点で強度が低下するのではないかと心配しています。
何かご意見は？一般に、Base64エンコードは暗号化の強度に何らかの影響を与えますか？
最新の暗号化ライブラリが文字を操作する方法はありません。最新の暗号はすべてバイトで動作するように定義されています（一部はビットで動作するように定義されていますが、ほとんどのライブラリではバイトがデータの最小単位であると想定しています）。ライブラリがcharacter文字列を受け入れる場合、それらは内部のバイトに変換されます。たとえば、 std:stringはnotには文字列を含める必要があります。バイト文字列（別名オクテット文字列）も含めることができます。
一方、ほとんどの暗号化ライブラリは、キースペースの全範囲を使用します。これは、キーを構成するバイトが任意の値を持つことができることを意味します。したがって、base 64でエンコードされたキーに有効なキーサイズがある限り、それを受け入れることができます。その場合の唯一の問題は、base64に完全にランダムなキーのエントロピーの4分の3が含まれることです。したがって、192ビットのAESキーがある場合、AES 256ビットのキーに変換されます。その場合、スキーム内のpossibleキーの量は2 ^ 192であるため、256ビットのセキュリティを要求しないでください。
暗号化ライブラリ自体がbase64をデコードする場合、鍵は最初に1：1でbase64に変換され、次に元の鍵に再び戻されます。明らかにそのような場合、base64は違いを生みません。ライブラリについては、base64または16進数からの変換が十分に文書化されていることを期待します。
Synercoding.Encryptionに関する貴重な情報はほとんどないようです。これは良い兆候ではありません。
キーがキーではなく、PBKDF2に入力されたパスワードである場合は、十分なエントロピーを提供する必要があります。それが直接PBKDF2に供給される場合、または最初にbase64としてエンコードされる場合、違いはありません。
パスワードベースの関数として十分面白いPBKDF2も、バイトを操作するように定義されています。したがって、APIは文字エンコードも指定する必要があります。通常はASCIIと互換性があるため、base 64が機能する可能性があります。PBKDF2の実装間の何らかの互換性レイヤーとしても使用できます。
キーが使用前にバイナリ形式に変換されている限り、base-64エンコーディングによって引き起こされたビット希釈は元に戻されます。
ただし、アプリケーションの周りでキーを渡す場合は、その方法に注意してください。テキストバッファーをワイプし、メソッドとアプリケーション間のトランジットを最小限に抑えます。
すべてのまともな暗号化アルゴリズムはビットまたはバイトのシーケンスで動作するように定義されているため、「暗号化ライブラリ」には2つの可能性しかありません。
- 文字列を内部的にバイトに変換します。
- または、文字に基づくカスタムアルゴリズムを使用します。
最初のケースでは、ライブラリにずさんなAPIがあります。人為的に文字列に限定するべきではありません。 2番目のケースでは、これはさらに悪くなります。カスタムの自家製アルゴリズムは常に弱いです。
いずれにせよ、最も重要なのはライブラリではなくアルゴリズムです。ライブラリは、アルゴリズムを正しく実装する責任がありますが、セキュリティは、基盤となるアルゴリズムとその使用方法に由来します（暗号化アルゴリズムのアセンブリは、しばしばプロトコルと呼ばれます）。ライブラリが行うことを「暗号化を行う」としか知らない場合は、質問に対して重要な答えを出す方法はありません。ライブラリが実装するプロトコルを明確に定義され研究された標準として指定していない場合、実行できる唯一の健全なアクションは、そのライブラリを削除して、より適切なものを見つけることです。