如何为我的AES加密数据库条目导出密钥和初始化向量？ [英] How should I derive the key and initialization vector for my AES encrypted database entries?

问题描述

我建立了一个CMS系统，允许用户在我的客户的Intranet应用程序上创建和管理在线表单。

I've built a CMS system to allow users to create and manage online forms on my client's intranet app.

当然，这些表单处理的某些数据可能需要加密，例如如果系统用于构建处理工资明细或其他内容的表格。因此，我使用 AESManaged 类对此类数据进行对称加密，然后再将其放入我们的应用程序数据库。

Of course some of the data handled by the forms may need to be encrypted e.g. if the system is used to build a form that handles salary specifics or whatever. So I'm using the AESManaged class to symmetrically encrypt this sort of data prior to it going into our application db.

一切都很好，但是现在，在发布之前，我可以对共享机密和盐。

All is fine, but now, prior to release, I could do with a steer regarding the shared secret and salt.

我最初的想法是（动态）共享秘密通过将包含加密字段的表单的（基于GUID）ID与<$ c $的（再次基于GUID）ID组合c>问题该字段是以下问题的答案：

My original idea was to make a (dynamic) shared secret by combining the (GUID-based) ID of the Form containing the encrypted field with the (again, GUID-based) id of the Question the field is the answer to:

FormId:QuestionId

我的盐当前以相同的方式生成，但顺序为指导倒退即。

My Salt is currently generated the same way, only with the order of Guids reversed ie.

QuestionID:FormID.

我是新手，所以不确定这是否是明智的策略还是我应该做

I'm new to this stuff so not sure if this a sensible strategy or if I should be doing it some other way?

推荐答案

salt应该是随机生成的值。其目的是使字典/蛮力攻击更难执行。 Wikipedia上有一篇很好的关于加密盐的文章：
http://en.wikipedia.org/ Wiki / Salt_（cryptography ）

The salt should be a randomly generated value. Its purpose is to make dictionary/brute force attacks more difficult to execute. Wikipedia has a nice article on cryptographic salts: http://en.wikipedia.org/wiki/Salt_(cryptography)

对于共享机密，理想情况下，该值不应是未加密的数据（例如，您的ID）。通常，最佳做法是由最终用户或管理员以某种方式选择密钥，以便他们可以定期旋转密钥或在发生某种安全漏洞的情况下。此密码密钥可以由CMS的每个用户拥有

For the shared secret ideally it would not be a value that was stored unencrypted with the data that it was encrypting (such as your ids). It's generally a best practice that the key be chosen somehow by the end-user or admin so that they could rotate it periodically or if some sort of security breach occurred. This password key could be owned by each user of the CMS or perhaps by an admin account. If you have very serious security requirements you could pursue a third-party Key Management Server.

如果您的主要安全要求是非常严格的安全性，则可以使用第三方密钥管理服务器。 CMS将不会受到某种形式的安全审核，然后按照您最初的想法行事，这将防止对数据的随意访问，但可能不会通过针对正式标准的审核需要随机加盐的标准，旋转密钥的方式以及系统所有者更改密码的方式，以使您自己无法访问数据。

If the main goal here is more of obfuscation and the CMS will not be subject to some form of security audit then something along the lines of your initial idea would do. It would prevent the casual access of the data but would probably not pass an audit against formal standards that would require a random salt, a way to rotate the keys, and a way for the "owner" of the system to change the password such that you yourself could not access the data.

这篇关于如何为我的AES加密数据库条目导出密钥和初始化向量？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！