c# - AesManaged 的​​加密设置和 secret 管理

Question

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

算法/类选择:似乎应该“坚持使用 AES，除非你有充分的理由不这样做”。 AesManaged 是一个不错的选择吗？ Difference between symmetric crypto algorithms

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

[编辑:固定上下 256 位。添加问题。]

对于“非政府工作”来说，256 位 key 和 16 字节 IV 是否足够强大？

我读到 256 位 key 容易受到某种攻击(我认为这不适用于我的情况)。有什么理由改用 128 位 key 吗？什么是性能差异？

默认 key 大小大于 block 大小是否正常？

[编辑:完成。]

默认 key 和 IV 的强度:是否有任何理由使用 RNGCryptoServiceProvider.GetBytes() 或者 AesManaged 已经在做什么？

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

是否可以推断并保证同意任何其他属性，或者我应该为 key 生成、加密和解密明确设置它们？

key 生成代码:

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# 中你想坚持使用你拥有的免费东西。

我建议设置值而不是将它们保留为默认值。这保证了无声故障的可能性较小。当然，您必须确切地知道您在做什么。但安全就是了解您的行为。

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

我现在说的话不会让你满意。共享 secret 使您的所有努力都变得毫无用处。如果窃听者可以窃取 secret ，那么加密就完全没有用了。

对于存储的数据，这种选择可能没问题，只要您每次想要解密 block 时都要求提供 key 并且永远不要将 secret 存储在磁盘上(很像 KeePassX 要求输入密码才能打开 key 文件)。

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

如您所见，共享 secret 是这里的真正问题。显而易见的解决方案是 SSL，但它是不对称的，并且 C# 实现非常不稳定，特别是对于可能在 mono/Linux/OpenSSL 上运行的多平台应用程序。如果你走那条路，请准备好迎接一场噩梦。

没有 SSL 或外部通信 channel 的 Internet 上真正可行的安全性？没有骰子。

根据您的用例，您可能希望避免将 secret 存储在字符串中。

如果涉及到生命或金钱，你想做的不止于此。考虑到用户可能会在网吧等公共(public)计算机上安装客户端。查看SecureString以及以递增方式对字符进行哈希处理并且从不实际将字符串存储在内存中的算法。

编辑:

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