pki与对称加密的性能差异是什么？
我们希望对我们的项目提出一些严格的安全要求，并且我们需要进行大量高性能的加密。
我认为我知道 PKI 比对称加密慢得多且复杂得多，但我找不到数字来支持我的感觉。
We are looking to do some heavy security requirements on our project, and we need to do a lot of encryption that is highly performant.
I think that I know that PKI is much slower and more complex than symmetric encryption, but I can't find the numbers to back up my feelings.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
在运行 OS X 10.5.5 和 OpenSSL 原生版本的 Macbook 上，“openssl speed”以每秒 46,000 个 1024 位块的速度运行 AES-128-CBC。 同一个盒子以每秒 169 个签名的速度运行 1024 位 RSA。 AES-128-CBC是“教科书”块加密算法，RSA 1024是“教科书”公钥算法。 这是从苹果到橘子的问题，但答案是：RSA 慢得多。
但这并不是您不应该使用公钥加密的原因。 真正的原因如下：
公钥加密操作不适用于原始数据加密。 Diffie-Hellman 和 RSA 等算法被设计为块加密算法交换密钥的一种方式。 因此，例如，您可以使用安全随机数生成器为 AES 生成 128 位随机密钥，并使用 RSA 加密这 16 个字节。
像 RSA 这样的算法远不如 AES 那样“用户友好”。 使用随机密钥，您提供给 AES 的明文块对于任何没有密钥的人来说都是随机的。 实际上 RSA 的情况并非如此，它比 AES 更重要——只是一个数学方程。 因此，除了正确存储和管理密钥之外，您还必须非常小心格式化 RSA 明文块的方式，否则最终会出现漏洞。
如果没有密钥管理基础设施，公钥就无法工作。 如果没有验证公钥的方案，攻击者可以用自己的密钥对替换真实的密钥对来发起“中间人”攻击。 这就是 SSL 强制您完成繁琐的证书的原因。 像 AES 这样的块加密算法确实也会遇到这个问题，但如果没有 PKI，AES 的安全性并不比 RSA 差。
公钥加密操作比 AES 更容易受到更多实施漏洞的影响。 例如，RSA 交易的双方必须就参数达成一致，这些参数是输入到 RSA 方程的数字。 攻击者可以替换一些邪恶的值来默默地禁用加密。 迪菲·赫尔曼 (Diffie Hellman) 也是如此，椭圆曲线 (Elliptic Curve) 更是如此。 另一个例子是 2 年前在多个高端 SSL 实现中发生的 RSA 签名伪造漏洞。
使用公钥证明您正在做“不寻常”的事情。 与众不同正是您永远不希望密码学出现的情况； 除了算法之外，加密设计还要经过多年的审核和测试才能被认为是安全的。
对于想要在应用程序中使用加密技术的客户，我们提出两条建议：
对于“静态数据”，请使用 PGP。 真的吗！ PGP 已经被淘汰了十多年，并且被认为不会出现愚蠢的实施错误。 它有开源和商业变体。
对于“传输中的数据”，请使用 TLS/SSL。 世界上没有任何安全协议比 TLS 更容易被理解和更好地测试； 世界各地的金融机构都接受它作为移动最敏感数据的安全方法。
这是一篇不错的文章 [matasano.com] 我专业密码学家内特·劳森 (Nate Lawson) 几年前写过一篇文章。 它更详细地涵盖了这些要点。
On a Macbook running OS X 10.5.5 and a stock build of OpenSSL, "openssl speed" clocks AES-128-CBC at 46,000 1024 bit blocks per second. That same box clocks 1024 bit RSA at 169 signatures per second. AES-128-CBC is the "textbook" block encryption algorithm, and RSA 1024 is the "textbook" public key algorithm. It's apples-to-oranges, but the answer is: RSA is much, much slower.
That's not why you shouldn't be using public key encryption, however. Here's the real reasons:
Public key crypto operations aren't intended for raw data encryption. Algorithms like Diffie-Hellman and RSA were devised as a way of exchanging keys for block crypto algorithms. So, for instance, you'd use a secure random number generator to generate a 128 bit random key for AES, and encrypt those 16 bytes with RSA.
Algorithms like RSA are much less "user-friendly" than AES. With a random key, a plaintext block you feed to AES is going to come out random to anyone without the key. That is actually not the case with RSA, which is --- more so than AES --- just a math equation. So in addition to storing and managing keys properly, you have to be extremely careful with the way you format your RSA plaintext blocks, or you end up with vulnerabilities.
Public key doesn't work without a key management infrastructure. If you don't have a scheme to verify public keys, attackers can substitute their own keypairs for the real ones to launch "man in the middle" attacks. This is why SSL forces you to go through the rigamarole of certificates. Block crypto algorithms like AES do suffer from this problem too, but without a PKI, AES is no less safe than RSA.
Public key crypto operations are susceptible to more implementation vulnerabilities than AES. For example, both sides of an RSA transaction have to agree on parameters, which are numbers fed to the RSA equation. There are evil values attackers can substitute in to silently disable encryption. The same goes for Diffie Hellman and even more so for Elliptic Curve. Another example is the RSA Signature Forgery vulnerability that occurred 2 years ago in multiple high-end SSL implementations.
Using public key is evidence that you're doing something "out of the ordinary". Out of the ordinary is exactly what you never want to be with cryptography; beyond just the algorithms, crypto designs are audited and tested for years before they're considered safe.
To our clients who want to use cryptography in their applications, we make two recommendations:
For "data at rest", use PGP. Really! PGP has been beat up for more than a decade and is considered safe from dumb implementation mistakes. There are open source and commercial variants of it.
For "data in flight", use TLS/SSL. No security protocol in the world is better understood and better tested than TLS; financial institutions everywhere accept it as a secure method to move the most sensitive data.
Here's a decent writeup [matasano.com] me and Nate Lawson, a professional cryptographer, wrote up a few years back. It covers these points in more detail.
使用 OpenSSL
speed子命令进行基准测试算法并亲自看看。Use the OpenSSL
speedsubcommand to benchmark the algorithms and see for yourself.实用的基于PKI的加密系统使用非对称加密来加密对称密钥，然后使用该密钥进行对称加密来加密数据（话虽如此，有人会指出一个反例）。
因此，非对称加密算法相对于对称加密算法带来的额外开销是固定的——它不取决于数据大小，只取决于密钥大小。
上次我对此进行测试时，在运行频率为 100MHz 左右的 ARM 上验证由 3 个左右的 X.509 证书组成的链[编辑添加：以及它们签名的数据]只需要不到一秒的时间（多次重复的平均值，明显地）。 我不记得有多小——不是可以忽略不计，但远低于一秒。
抱歉，我不记得确切的细节，但总结是，除非您使用的系统非常受限制或进行了大量加密（例如您想每秒接受尽可能多的 SSL 连接），否则 NIST 批准的非对称加密方法速度很快。
Practical PKI-based encryption systems use asymmetric encryption to encrypt a symmetric key, and then symmetric encryption with that key to encrypt the data (having said that, someone will point out a counter-example).
So the additional overhead imposed by asymmetric crypto algorithms over that of symmetric is fixed - it doesn't depend on the data size, just on the key sizes.
Last time I tested this, validating a chain of 3 or so X.509 certificates [edit to add: and the data they were signing] was taking a fraction of a second on an ARM running at 100MHz or so (averaged over many repetitions, obviously). I can't remember how small - not negligible, but well under a second.
Sorry I can't remember the exact details, but the summary is that unless you're on a very restricted system or doing a lot of encryption (like if you want to accept as many as possible SSL connections a second), NIST-approved asymmetric encryption methods are fast.
显然情况要糟糕 1000 倍。 (http://windowsitpro.com/article/articleid/93787 /对称-vs-非对称-ciphers.html）。 但除非你真的处理大量数据，否则这并不重要。 您可以做的是使用非对称加密来交换对称加密密钥。
Apparently it is 1000x worse. (http://windowsitpro.com/article/articleid/93787/symmetric-vs-asymmetric-ciphers.html). But unless you're really working through a lot of data it isn't going to matter. What you can do is use asymmetric encryption to exchange a symmetric encryption key.
也许您可以添加一些有关您的项目的详细信息，以便获得更高质量的答案。 你想保护什么？ 从谁？ 如果您可以解释您的安全要求，您将得到更好的答案。 如果加密机制不能保护您认为的内容，那么性能就没有多大意义。
例如，X509 证书是保护客户端/服务器端点的工业标准方法。 PGP 防护可用于保护许可证文件。 为简单起见，如果您控制两个端点，则使用 Blowfish（以及许多其他密码）进行密码块链接很容易在 Perl 或 Java 中使用。
谢谢。
Perhaps you can add some details about your project so that you get better quality answers. What are you trying to secure? From whom? If you could explain the requirements of your security, you'll get a much better answer. Performance doesn't mean much if the encryption mechanism isn't protecting what you think it is.
For instance, X509 certs are an industrial standard way of securing client/server endpoints. PGP armoring can be used to secure license files. For simplicity, Cipher block chaining with Blowfish (and a host of other ciphers) is easy to use in Perl or Java, if you control both end points.
Thanks.
是的，PGP、TLS 和 CMS 等标准化加密方案提供的混合加密确实会给每条消息或会话带来固定的性能成本。 这种影响有多大取决于所选的算法以及您正在谈论的操作。
对于 RSA，解密和签名操作相对较慢，因为它需要使用较大的私有指数进行模幂运算。 另一方面，RSA 加密和签名验证速度非常快，因为它使用较小的公共指数。 这种差异与密钥长度呈二次方关系。
在 ECC 下，由于对等体使用相似大小的密钥进行相同的数学计算，因此操作比 RSA 更加平衡。 在集成加密方案中，可以生成临时EC密钥，并将其用于密钥协商算法； 这需要消息发送者做一些额外的工作。 ECDH 密钥协商比 RSA 加密慢得多，但比 RSA 解密快得多。
就相对数字而言，使用 AES 解密可能比使用 RSA 解密快 100,000 倍。 就绝对数字而言，很大程度上取决于硬件，AES 每个块可能需要几纳秒，而 RSA 需要一到两毫秒。 这就提出了一个问题，为什么有人会使用非对称算法呢？
答案是这些算法在混合加密方案中出于不同的目的一起使用。 AES 等快速、对称算法用于保护消息本身，而 RSA 等慢速、非对称算法则用于保护对称算法所需的密钥。 这使得以前从未共享过任何秘密信息的各方（例如您和您的搜索引擎）能够彼此安全地通信。
Yes, the hybrid encryption offered by standardized cryptographic schemes like PGP, TLS, and CMS does impose a fixed performance cost on each message or session. How big that impact is depends on the algorithms selected and which operation you are talking about.
For RSA, decryption and signing operations are relatively slow, because it requires modular exponentiation with a large private exponent. RSA encryption and signature verification, on the other hand, is very fast, because it uses the small public exponent. This difference scales quadratically with the key length.
Under ECC, because peers are doing the same math with keys of similar size, operations are more balanced than RSA. In an integrated encryption scheme, an ephemeral EC key can be generated, and used in a key agreement algorithm; that requires a little extra work for the message sender. ECDH key agreement is much, much slower than RSA encryption, but much faster than RSA decryption.
In terms of relative numbers, decrypting with AES might be 100,000x faster than decrypting with RSA. In terms of absolute numbers, depending heavily on hardware, AES might take a few nanoseconds per block, while RSA takes a millisecond or two. And that prompts the question, why would anyone use asymmetric algorithms, ever?
The answer is that these algorithms are used together, for different purposes, in hybrid encryption schemes. Fast, symmetric algorithms like AES are used to protect the message itself, and slow, asymmetric algorithms like RSA are used in turn to protect the keys needed by the symmetric algorithms. This is what allows parties that have never previously shared any secret information, like you and your search engine, to communicate securely with each other.
是的，纯粹的非对称加密比对称密码（如 DES 或 AES）慢得多，这就是为什么实际应用程序使用混合加密加密术：昂贵的公钥操作仅用于加密（和交换）用于加密真实消息的对称算法的加密密钥。
公钥密码学解决的问题是没有共享秘密。 使用对称加密，您必须信任所有相关方来保守密钥的秘密。 这个问题应该比性能更值得关注（可以通过混合方法来缓解）
Yes, purely asymmetric encryption is much slower than symmetric cyphers (like DES or AES), which is why real applications use hybrid cryptography: the expensive public-key operations are performed only to encrypt (and exchange) an encryption key for the symmetric algorithm that is going to be used for encrypting the real message.
The problem that public-key cryptography solves is that there is no shared secret. With a symmetric encryption you have to trust all involved parties to keep the key secret. This issue should be a much bigger concern than performance (which can be mitigated with a hybrid approach)