0

我将敏感信息存储在数据库中，该数据库经过以下过程：

  1. 用户通过网络表单输入信息。
  2. 输入的信息使用 256 位 AES 加密，并使用每个用户的唯一 ID 进行加盐处理（尽管它存储在同一个数据库中，有时存储在同一个表中）。
  3. 然后通过 openssl_pub_encrypt 函数解析加密的 pass 1 数据
  4. 数据存储在 mysql 数据库中，字段类型为：varbinary

解密数据：

  1. 私钥存储在服务器之外，每次需要检索数据时都必须上传到临时文件中
  2. 代码通过 o​​penssl_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

使用与加密数据位于同一位置的密钥对数据进行加密是没有意义的。

但是，如果您为每个用户使用单独的公钥/私钥对，这将是一个优势 - 这样，如果私钥泄漏，您只会暴露您的一个记录而不是所有记录。

顺便说一句，openssl_public_encrypt()/openssl_private_decrypt()并不是真正使用正确的函数 - 它是一个用于加密随机生成的密钥的低级函数，而不是直接对数据进行操作。正确的高级函数是openssl_seal()/ openssl_open()。

于 2010-11-11T05:40:11.847 回答