0

次のプロセスを経るデータベースに機密情報が保存されています。

  1. ユーザーは Web フォームから情報を入力します。
  2. 入力された情報は AES 256 ビットを使用して暗号化され、各ユーザーに一意の ID を使用してソルト化されます (ただし、これは同じデータベースに保存され、場合によっては同じテーブルに保存されます)。
  3. 暗号化されたパス 1 データは、openssl_pub_encrypt 関数によって解析されます。
  4. データはフィールドタイプ: varbinary で mysql データベースに保存されます

データを復号化するには:

  1. 秘密鍵はサーバー外に保存され、データを取得する必要があるたびに一時ファイルにアップロードする必要があります
  2. コードは openssl_private_decrypt を介して実行されます
  3. コードは、同じソルトと AES-256 スクリプトを使用して復号化されます。

私が疑問に思っているのは、このインスタンスで AES-256 ビットを介して情報を実行する価値があるかどうかです (キーがオフラインであり、データが危険にさらされた場合にソルトが既にテーブル内に保存されているため)?

4

2 に答える 2

3

Salting makes no sense on symetrically encrypted data, which is what you've got with AES-256. If anything, it'd just make any potential cracker's job easier by putting some known plaintext within the data. After all, ANY key will "decrypt" the data, but only one key will produce the original data. By putting a chunk of known plaintext in there, you've made it far easier to determine if the key being used is valid or not ("is salt text there, if so key is valid").

If the data's so sensitive that you have to take these precautions, I'd be more worried about the exposure window when the key file is actually stored on the server, as well as the traces it will leave behind in memory and on-disk, even after you've removed the file.

于 2010-11-10T21:09:24.897 に答える
1

暗号化されたデータと同じ場所で利用できるキーでデータを暗号化しても意味がありません。

ただし、ユーザーごとに個別の公開鍵と秘密鍵のペアを使用すると、利点があります。これにより、秘密鍵が漏洩した場合、すべてのレコードではなく、1 つのレコードのみが公開されます。

ところで、openssl_public_encrypt()/openssl_private_decrypt()は実際には使用する適切な関数ではありません。データを直接操作するためではなく、ランダムに生成されたキーを暗号化することを目的とした低レベルの関数です。右の高レベル関数はopenssl_seal()/openssl_open()です。

于 2010-11-11T05:40:11.847 に答える