我想使用.NET安全命名空间中可用的加密算法，但我想了解如何生成密钥，例如AES算法需要256位，即16字节键，以及一些初始化向量，这也是几个字节。如何为加密算法创建加密密钥？
我可以在我的Key和IV中使用任何值的组合吗？例如Key和IV中的所有零是有效的还是不是？我知道做很多xors的算法的细节，所以零不会提供任何好处，但是这些算法是否有任何限制？
还是我必须使用一些程序来生成密钥，并将其保存永久的地方？
我想加密后的数据在数据库中存储，如用户名，密码，电话号码等，而关键的安全配置文件数据将提供给在连接字符串中只提到了，并给管理员数据库用户。
如果您正在使用加密来交换数据，那么你将需要一个密钥交换协议，但你不自己做一个，而不是使用一个现成的，货架像TLS或SSL。
如果您使用加密来存储数据，则使用CryptGenRandom（或其.net等效的RandomNumberGenerator.GetBytes）生成IV并将其保存在文档中（清楚地说明，不需要保护IV）。你永远不会写下钥匙，钥匙是由用户提供的。 Usualy从密码短语中使用CryptDeriveKey或其.Net等效的PasswordDeriveKey.CryptDeriveKey获得密钥。
更新
要存储在数据库中的一个秘密就是只提供给用户，并且需要使用3个键管理员：
理论上你加密与DK的数据，然后加密与英国DK和保存，加密与AK的DK和保存。这样用户可以再次使用英国解密DK然后解密数据，并且管理员可以使用AK解密DK然后解密数据。最大的问题是系统始终是自动化的，所以系统需要访问管理员的密钥，这意味着它不是管理员的真实密钥，而是一个系统密钥（它不能用于非管理员的目的，例如拒绝）。
作为一个负责人，了解IV是什么或如何使用C＃中的AES以及密码算法是如何工作的，在解决这类问题时将获得完全0（零）的牵引力。这个问题从来不是什么IV和关键，这个问题总是关键配置。对于实际的加密操作，只需使用数据库的内置支持，请参阅Cryptography in SQL Server。我可以很容易地争辩说，您需要的只有设施是TDE（Transparent Data Encryption），以防止意外丢失媒体。
我想在加密后将数据存储在数据库中，安全配置文件数据如用户名，密码，电话号码只有连接字符串中提到的数据库用户以及管理员才能使用该密钥。 – 2010-03-23 20:47:27
简而言之，我只需要保护来自访问服务器和备份的其他开发人员的敏感用户信息，虽然他们很少访问服务器，但备份可以在任何地方，但没有密钥，敏感部分不应以纯文本形式可见。 – 2010-03-23 21:08:37
密码应该是散列（单向加密）未加密。其他敏感数据可以加密。但只对包含敏感数据的列进行加密，而不对整个数据库进行加密，导致性能后果和开销。 – 2015-02-12 06:36:06
生成特定长度的随机字母/十六进制代码。
此功能（从here拍摄）在一个特定的长度返回一个随机密钥：
private static string CreateSalt(int size)
{
//Generate a cryptographic random number.
RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();
byte[] buff = new byte[size];
rng.GetBytes(buff);
// Return a Base64 string representation of the random number.
return Convert.ToBase64String(buff);
}
这真的取决于你定义与键做什么。
如果键是要由计算机生成（并且可以是任何随机值）一般我需要几个的GUID的SHA256。这与你在没有硬件随机数发生器的情况下随机取得一样。
您可以使用全0键，但显然它不会是非常安全的。
所以简而言之，我可以随便生成一些随机垃圾并永久保存它，好吧，一旦密钥全部丢失了？当然，我会尝试将副本保存在辅助媒体上。 – 2010-03-23 20:53:49
这是正确的。密钥越随机，密钥越安全（当然，这取决于密钥存储的安全性。） – 2010-03-25 07:03:56
使用System.Security.Cryptography.RandomNumberGenerator生成随机字节：
var rnd = new System.Security.Cryptography.RandomNumberGenerator.Create();
var key = new byte[50];
rnd.GetBytes(key);
你真的应该这样做的正确的方式:)
1）使用安全产生的随机IV
2）使用安全产生的随机关键
3）不要使用ECB模式 - EVER
AesManaged aes = new AesManaged();
aes.GenerateKey();
aes.GenerateIV();
上面的代码将正确安全地为您生成一个随机的IV和随机密钥。
由于我刚刚阅读了这个内容，所以答复晚了：实例化AESManaged类已经为您生成了密钥，只需读取.Key和.IV属性即可。 – 2012-08-21 08:16:38
你说你永远不应该使用ECB模式，尽管我同意你的意见，但我会说有时你可能会想使用它。这是非常罕见的，但作为一个例子，如果你想在CTR（计数器模式）下实现AES，那么你需要在ECB模式下使用该算法。对于普通用户，您的陈述是绝对正确的，我绝不会主张您在未充分了解潜在隐患的情况下使用ECB模式。 http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation提供了一个很好的分组密码模式。 – 2015-03-24 17:43:29
听起来像你需要读入Rfc2898DeriveBytes类。
Rfc2898DeriveBytes.GetBytes();
它有一个方法（上文），可以允许，简单地通过将一个int值来调整该被送入上的对称加密算法的。重点和.IV属性字节数组的大小。 MS官方的70-536版书籍建议通过将KeySize属性/ 8分开来进行此操作。例如，TripleDes或AESManaged。无论你使用什么，算法本身都会有一些需要先满足的预先需求。即满足关键尺寸条件。 RunTime会自动填充属性和字段等，为您提供最好，最强大的值。但是IV和Key需要来自你。这如何可以做到以下几点：
RijndaelManaged myAlg = new RiRijndaelManaged();
byte[] salt = Encoding.ASCII.GetBytes("Some salt value");
Rfc2898DeriveBytes key = new Rfc2898DeriveBytes("some password", salt);
myAlg.Key = key.GetBytes(myAlg.KeySize/8);
myAlg.IV = key.GetBytes(myAlg.BlockSize/8);
// myAld should now fully set-up.
上面可以看到我的意思做亲语法，因为它应该非常 做这一切为你，没有你竟然真的有蝙蝠的眼睛 - 满足它的预先要求。
Microsoft 70-536书指出，.Key属性期望您按字节提供 的字节数组，而不是位。 RFC类以字节形式工作，其中算法KeySize属性以位为单位工作。 1个字节= 8位。你能看到这是怎么回事吗？ 这应该给你一个想法，为什么上面的示例peice代码完成了它的方式！我研究过它，这对我来说非常合适！
上述答案应该允许您使用提供的密码和静态盐值创建算法对象，该值可以是两端的硬代码。您只需要担心如何确保存储在.Key和.IV中的字节数组安全地传输到收件人，以便可以成功解密您加密的邮件。通过安全地重建相同的算法对象。
OBTW：
AESManaged具有密钥大小REQ'：128位= 16个字节!!! （8 * 8 = 64,64Bit/8bits per Byte = 8 Bytes）因此，
64 * 2 = 128Bit，8 * 2，> 16字节密钥大小！
256Bit = 32Bytes !!!!
根据70-536官方培训包的书，Aes限于128位的密钥大小。例如256位，192和128密钥大小可以与Rijndael类一起使用。
你可以从另一方面完全忘记了所有的垃圾，并简单地使用.GenerateKey和GenerateIV方法，而不是救你整理出一个预共享，并同意密码和静态盐值的所有麻烦。您唯一需要考虑的是找出存储和检索密钥和IV字节数组的方法。二进制格式化程序？ 。
如果你想使用AES256，那么你的密钥应该是32个字节，并设置KeySize属性= 256。否则它将使用AES 128.你可以使用全零，但在安全上下文中，它不安全。是的，最好生成随机密钥（如在迈克尔霍华德 - 微软的答案），并安全地存储。 – 2015-02-12 06:36:46