openSSL 加密足够了吗？
我将敏感信息存储在数据库中，该数据库经历以下过程：
- 用户通过网络表单输入信息。
- 输入的信息使用 AES 256 位进行加密，并使用每个用户的唯一 ID 进行加盐处理（尽管这些信息存储在相同数据库中，有时甚至存储在同一个表中）。
- 加密的第 1 遍数据然后通过 openssl_pub_encrypt 函数进行解析，
- 数据存储在 mysql 数据库中，字段类型：varbinary
解密数据：
- 私钥存储在服务器之外，每次需要检索数据时都必须上传到临时文件中
- 代码通过 openssl_private_decrypt 运行
- 代码通过使用相同盐和 AES-256 脚本的解密运行。
我想知道的是，在这种情况下通过 AES-256 位运行信息是否值得（因为密钥处于离线状态，并且如果数据遭到泄露，盐已经存储在表中）？
I have sensitive information stored in a database which goes through the following process:
- user enters information through webform.
- information entered is encrypted using AES 256-bit and salted using unique id to each user (although this is stored in the same database, and sometimes same table).
- The encrypted pass 1 data is THEN parse through openssl_pub_encrypt function
- data is stored in mysql database with fieldtype: varbinary
to decrypt the data:
- the private key is stored OFF the server and must be uploaded in a temporary file EVERY time the data needs to be retrieved
- the code runs through openssl_private_decrypt
- the code is run through a decrypt with the same salt and AES-256 script.
What I am wondering is running the information through the AES-256 bit in this instance even worth it (since key is offline, and the salt is already stored within the table if the data ever became compromised)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
加盐对于对称加密数据没有任何意义，而对称加密数据正是 AES-256 所提供的。如果有什么不同的话，那就是通过在数据中放入一些已知的明文来使任何潜在的破解者的工作变得更容易。毕竟，任何密钥都可以“解密”数据，但只有一个密钥才能产生原始数据。通过在其中放入一大块已知的明文，您可以更轻松地确定所使用的密钥是否有效（“那里是否有盐文本，如果密钥有效”）。
如果数据非常敏感以至于您必须采取这些预防措施，我会更担心密钥文件实际存储在服务器上时的暴露窗口，以及它将在内存和磁盘上留下的痕迹，即使您删除了该文件。
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.
使用与加密数据位于同一位置的密钥来加密数据是没有意义的。
但是，如果您为每个用户使用单独的公钥/私钥对，这将是一个优势 - 这样，如果私钥泄漏，您只会暴露其中一个记录而不是全部记录。
顺便说一下，openssl_public_encrypt()/openssl_private_decrypt()实际上并不是正确使用的函数 - 它是一个较低级别的函数，旨在加密随机生成的密钥，而不是直接加密对数据进行操作。正确的、更高级别的函数是
openssl_seal()/openssl_open()。There is no point encrypting the data with a key that is available in the same place as the encrypted data.
However, it would be an advantage if you used a separate public/private key pair for each user - that way, if a private key leaks, you are only exposing one of your records instead of all of them.
By the way,
openssl_public_encrypt()/openssl_private_decrypt()is not really the right function to use - it's a lower-level function intended for encrypting randomly generated keys, not to directly operate on the data. The right, higher-level functions areopenssl_seal()/openssl_open().