Question

我正在实施一种用于中等安全数据传输的共享密钥加密方案。当服务器配置客户端时，我可以生成一个或多个代表该秘密的字符串。然后，客户端将使用此秘密信息在将数据发送到服务器之前对其进行加密。我希望确保共享密钥尽可能强大并足以保证互操作性。

算法/类选择：除非你有充分的理由不这样做，否则应该坚持使用AES。＆＃34; AesManaged是一个不错的选择吗？ Difference between symmetric crypto algorithms

设置和默认对象：我在系统的不同部分使用.NET 4.0和.NET 4.5，并且可能会随着时间的推移而升级。我找不到KeySize和BlockSize的默认属性的文档，也没有IV的默认长度。在.NET 4.0中，默认密钥大小为32（字节，256位），默认IV大小为16（字节）。 BlockSize和FeedbackSize是128（位）。模式是CBC，Padding是PKCS7。我应该明确设置哪些属性，之后是否应该重新生成密钥和IV？

[编辑：修正了256位以上和以下。添加了问题。]

一个256位密钥和一个16字节的IV强大到足以进行非政府工作吗？＆＃34;

我已经读过256位密钥容易受到某种攻击（我不认为这种情况适用于我的情况）。有没有理由使用128位密钥？性能差异是什么？

默认密钥大小是否大于块大小？

[编辑：完成。]

默认密钥和IV的强度：有没有理由使用RNGCryptoServiceProvider.GetBytes（）或者AesManaged正在做什么？

互操作性：我假设共享密钥由密钥和IV（编码为Base64字符串）组成。从恢复的字节数组中设置Key和IV属性是否足以设置相关属性（例如KeySize）？

可以推断出任何其他属性并保证同意，还是应该明确设置它们以进行密钥生成，加密和解密？

密钥生成代码：

AesManaged myAes = new AesManaged(); // use defaults
string keyString = Convert.ToBase64String(myAes.Key);
string ivString = Convert.ToBase64String(myAes.IV);

代码和背景：我从这里大量借用：http://msdn.microsoft.com/en-us/library/vstudio/system.security.cryptography.aesmanaged%28v=vs.100%29

Answer 1

AES（或Rijndael）几乎是标准，在Linux上我会想到河豚，但是在C＃中你想要坚持使用你所拥有的东西。

我建议设置值而不是将它们保留为默认值。这保证了不太可能发生无声故障。当然，您必须完全了解您在做什么。但安全就是知道你做了什么。

其余的我只能这样说。将密钥大小从128增加到192或256位（或其他设置而不实际更改算法）相对容易，因此从常用值开始并使其工作。但是，如果您可以使用相同的代码库进行更好的加密，那么为什么要少花钱？另一方面，安全是妥协。没有什么是完全安全的，这完全取决于你愿意花多少钱。

我说的话现在不会让你高兴。共享秘密会使您的所有努力变得毫无用处。如果窃听者可以抓住秘密，加密就完全没用了。

对于选择可能正常的存储数据，只要您每次要解密该块时都要求输入密钥，并且永远不会将密钥存储在磁盘上（就像KeePassX要求输入密码来打开密钥文件一样）。

对于移动中的数据（通过网络发送），非对称加密是必不可少的，除非您有其他方式来传达秘密。也就是说，永远不要通过互联网发送秘密，而是使用互联网方式（普通旧邮件，可能是电话或面对面）。

正如你所看到的，分享秘密是真正的问题。显而易见的解决方案是SSL，但它是非对称的，C＃实现非常不稳定，特别是对于可能在mono / Linux / OpenSSL上运行的多平台应用程序。如果你走那条路，那就准备好做一场噩梦吧。

没有SSL或外部通信渠道，在互联网上真正可行的安全性？没有骰子。

根据您的使用情况，您可能希望避免将密钥存储在字符串中。

如果涉及到生命或金钱，你想做更多的事情。考虑用户可能将客户端安装在公共计算机上，例如网吧。查看SecureString和逐步散列字符并且永远不会将字符串存储在内存中的算法。

修改

由于VM管理内存和垃圾收集的方式以及虚拟内存的工作方式，您可能会冒公共PC上未使用的扇区可能包含纯文本密码的风险。当操作系统将虚拟内存交换到磁盘时会发生这种情况。 C＃中没有编程方式可以绝对确定它没有发生。在这些场景中，SecureString和内存固定可以帮助您保护.NET客户端（C＃和VB）。

AesManaged的密码设置和秘密管理

1 个答案: