哪种 BouncyCastle API 支持的加密算法对于 C# .NET 中的短字符串加密最快且非常安全?
Posted
技术标签:
【中文标题】哪种 BouncyCastle API 支持的加密算法对于 C# .NET 中的短字符串加密最快且非常安全?【英文标题】:Which BouncyCastle API-supported Encryption algorithm is fastest for short string encryption in C# .NET and pretty safe? 【发布时间】:2021-09-21 03:52:22 【问题描述】:我尝试在 *** 中搜索此特定问题的答案,但找不到好的答案。
BouncyCastle API 为 .NET 提供了大量不同的加密算法。在这种情况下,我必须为以下用例选择一种加密算法:
加密数千个短字符串以存储在未加密文件中,通常长度为 10-30 个字符。
加密只需要适度安全,所有字符串都将使用相同的密钥但不同的初始化向量进行加密。不需要授权之类的东西(例如在 AES-GCM 中)。
哪一种加密算法最快和最直接的应用来加密和解密这样一组几千个小字符串?我将每个字符串的加密数据作为BASE64存储在文件中。
感谢您的建议!
【问题讨论】:
在什么硬件上最快?在什么软件上?单独加密“数千”字符串然后存储在一个非结构化文件中的目的是什么?我想您将遇到的最大瓶颈是 IO(读取/写入相同的非结构化文件) 基于 .NET Framework 4.x 的 Office VSTO 解决方案。我们希望该软件在使用了 7 年的 Haswell 笔记本电脑上仍能快速运行(在公司里有很多旧笔记本电脑)。文件 I/O 不是问题,它们是我们编写文件的方式,这些数千个字符串在几毫秒内写入文件。如果我们可以在基于 Core i5-4250u 的笔记本电脑上在 5 毫秒内加密和解密 5000 个小字符串(10-30 个字符),并且性能足以满足我们的目的,则不会显着降低用户体验。 【参考方案1】:该处理器仍然具有 AES-NI,因此通过 AES.Create
使用它似乎是最合乎逻辑的。更高端的解决方案是在 ECB 之外创建 CTR 模式(并缓存密钥流)。
否则,您正在寻找软件中的快速流密码。您可以检查 Salsa20 是否适合您。不幸的是,这是我在 Bouncy Castle for C# 中找到的唯一与 eStream 兼容的密码。
请注意,您可能想研究多线程,我肯定会检查在使用流密码时是否可以使用顺序随机数,因为为每次加密生成 128 位随机值似乎很浪费。
【讨论】:
谢谢你,Maarten 我也会去看看 Salsa20。我用 128 BITS AES CBC 测试了 System.Security.Cryptography 库,对于数千个小字符串来说它很慢,我没有使用准确的测量工具,但这是用户体验(以及使用 .NET 秒表进行的一些测量)。是的,在我们的场景中可以使用多线程(还有其他处理可以是并行的,因为它是非依赖的)。顺序随机数也很好,我们不寻求超过适度的安全性。 顺序随机数是完全安全的,但重复随机数对于流/计数器模式加密来说是灾难性的,所以要小心,特别是如果您要使用多个线程。 很高兴直观地知道我认为顺序的并不真正安全,但当然在加密算法背后有一些复杂的数学:)。 好吧,在重复随机数的情况下,您只需要 XOR 和一个计数器来获得两个明文值的 XOR。我不知道你所说的“复杂数学”,但打破多时间垫通常是加密课程的第一个或第二个练习作业。 我做了更多研究,似乎 Salsa20 在 优化 实现中速度非常快。它还具有快速的初始键设置(如果您了解实现细节,这并不奇怪),这意味着它应该非常适合较小的字符串。我可以找到 Sosemanuk 和 Rabbit 作为其他可能(稍快)的密码,但你必须为这些密码获取另一个库。除此之外,我只认为 XTEA 可能会引起人们的兴趣 - 至少包括那个。奇怪的是,我找不到 64 位优化的流密码。以上是关于哪种 BouncyCastle API 支持的加密算法对于 C# .NET 中的短字符串加密最快且非常安全?的主要内容,如果未能解决你的问题,请参考以下文章
使用 Bouncycastle 在 Java 中进行格式保留加密 (FPE)
为 RSACryptoProvider 和 BouncyCastle 生成密钥/加密/解密