比 RSA 更快的非对称密码
我一直在开发一个在大量文件中使用非对称加密的系统。我目前正在使用具有 4096 位密钥的 RSA 来加密每个文件的 256 位随机生成的 AES 密钥，但性能有些欠缺，因为一项所需的操作是扫描所有文件（系统处于运行状态时的估计数量）使用量约为 10,000）并确定哪些可以使用特定的私钥进行解密。虽然我不希望此操作是即时的，但目前花费的时间太长（每秒处理约 2 个文件）。我考虑过减少密钥长度，但即使将其减少到 2048 位也无法提供我所需的性能水平。 512 位就可以了，但这样的密钥现在可以轻松破解，这是不可能的。
有人能给我指出一个更快但具有相似加密强度的系统吗？它需要通过 Java JCA 提供程序（例如 bouncycastle 之类的东西）来实现，以便巧妙地插入到我现有的应用程序中。我知道充气城堡支持 El Gamal，但我找不到任何有关该算法有多强大的详细信息，或者它是否可能比 RSA 更快。我还听说椭圆曲线系统只需要相对较短的密钥（384 位等），但不知道在哪里可以找到其中之一的实现。
I've been working on a system that uses asymmetric encryption in a large number of files. I'm currently using RSA with 4096-bit keys to encrypt a 256-bit randomly generated AES key for each file, but performance is somewhat lacking, as one required operation is to scan through all the files (estimated number when the system is in use is around 10,000) and identify which ones can be decrypted using a specific private key. While I don't expect this operation to be instant, it is taking too long at the moment (~2 files processed per second). I considered reducing the key length, but even taking it down to 2048 bits doesn't provide the level of performance I need. 512 bits would just about cut it, but as such keys can now be cracked trivially that is out of the question.
Can anybody point me in the direction of a system that is faster but of similar cryptographic strength? It would need to be implemented via a Java JCA provider (e.g. something like bouncycastle) in order to plug in to my existing application neatly. I know bouncy castle supports El Gamal, but I can't find any details on how strong this algorithm is, or if it is even likely to be any faster than RSA. I also hear about elliptic curve systems that only need relatively short keys (384 bits or the like), but don't know where to find an implementation of one of these.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
对于您提出的问题，请尝试椭圆曲线上的 Diffie-Hellman，也称为“ECDH”。一旦我们处理当前技术无法破解的规模，估计安全性就有点困难，因为这取决于我们如何押注未来的技术发展。然而，可以说 P-256 曲线上的 ECDH 提供了“128 位”的安全性，该级别类似于从 2048 位 RSA 获得的安全级别。该级别对于所有当前用途来说足够了，或者更恰当地说，如果 P-256 不足以满足您的需要，那么您的问题有非常特殊的需求，并且加密强度可能是您最不担心的。
在我的 PC（2.4 Ghz Intel Core2，64 位模式，运行 Linux）上，OpenSSL 声称使用单个内核每秒处理大约 900 个 ECDH 实例。
编辑：要根据长度估计密钥安全性，对于多种算法，请参阅此站点。
For your question as asked, try Diffie-Hellman over elliptic curves, also known as "ECDH". Estimating security is a bit difficult once we deal with sizes that cannot be cracked with current technology, since this depends on how we bet on future technological evolutions. Yet one can say that ECDH over the P-256 curve provides "128 bits" of security, a level which is similar to what you would get from 2048-bit RSA. That level is widely sufficient for all current usages, or, more appropriately said, if P-256 is not enough for you then your problem has very special needs and cryptographic strength is likely to be the least of your worries.
On my PC (a 2.4 Ghz Intel Core2, 64-bit mode, running Linux), OpenSSL claims to crunch out about 900 ECDH instances per second, using a single core.
Edit: for estimation of key security, depending on the length, for several algorithms, see this site.
为什么不计算每个密钥的加密强哈希，然后将其与每个文件名一起以明文形式存储？然后，给定一个需要与所有文件匹配的密钥，您可以简单地散列该密钥并在表中查找它。
Why don't you calculate a cryptographically strong hash of each key, and then store that in the clear with each filename? Then, given a key that you need to match against all the files, you can simply hash the key and look it up in the table.
我会选择一种需要较少 RSA 操作的方法。 SSL/TLS，虽然它们使用 RSA 等来加密 AES 等密钥，但不要对数据使用 AES，因为它是一项计算成本高昂的操作，密钥大小足够大，以便在每个数据包或您的情况下实现安全性，每个文件的基础。
另一个公钥系统是：http://en.wikipedia.org/wiki/ElGamal_encryption。就安全性而言，我相信它尚未被攻破，但我个人目前信任 RSA。我不知道目前是否有任何椭圆曲线加密算法可用 - 也就是说，我知道它们正在研究中，但了解它们可能尚未准备好用于生产使用，而且我听说存在专利问题。
I'd go for an approach that requires less RSA operations. SSL/TLS, although they use RSA etc for encrypting AES etc keys, do not use AES for the data simply because it is a computationally expensive operation at sufficiently large key sizes for security to be done on a per-packet, or in your case, per-file basis.
Another public key system is: http://en.wikipedia.org/wiki/ElGamal_encryption. Security-wise I believe it has yet to be broken but would personally put my trust in RSA for now. I do not know if there are any elliptic curve encryption algorithms currently available - that is to say I know they are being researched but understand they may not be ready for production use and I heard there were patent issues.