【发布时间】：2008-09-23 00:44:31
【问题描述】：
我们希望对我们的项目执行一些严格的安全要求，并且我们需要执行大量高性能的加密。
我认为我知道 PKI 比对称加密要慢得多且复杂得多，但我找不到数据来支持我的感受。
【问题讨论】：
标签： performance encryption encryption-symmetric encryption-asymmetric
【发布时间】：2008-09-23 00:44:31
【问题描述】：
是的，纯非对称加密比对称密码（如 DES 或 AES）慢得多，这就是实际应用程序使用 hybrid cryptography 的原因：昂贵的公钥操作仅用于加密（和交换）加密密钥将用于加密真实消息的对称算法。
公钥密码学解决的问题是没有共享的秘密。使用对称加密，您必须信任所有相关方来保守密钥的秘密。这个问题应该比性能更受关注（可以通过混合方法来缓解）
【讨论】：
在运行 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 也是如此，椭圆曲线更是如此。另一个例子是 2 年前在多个高端 SSL 实施中发生的 RSA 签名伪造漏洞。
使用公钥证明您正在做一些“与众不同”的事情。与众不同正是您永远想要的密码学；除了算法之外，加密设计 在被认为是安全的之前都经过多年的审核和测试。
对于希望在其应用程序中使用加密技术的客户，我们提出两个建议：
对于“静态数据”，使用 PGP。真的！ PGP 已经被打败了十多年，被认为可以避免愚蠢的实施错误。它有开源和商业变体。
对于“传输中的数据”，请使用 TLS/SSL。世界上没有任何安全协议比 TLS 更容易理解和测试。世界各地的金融机构都接受它作为移动最敏感数据的安全方法。
Here's a decent writeup [matasano.com] 我和专业密码学家 Nate Lawson 几年前写的。它更详细地介绍了这些要点。
【讨论】：
-
您的文章链接似乎不再有效。
-
RSA 1024 不提供 AES-128 的安全性。您不应该为 RSA 原语形成自己的消息；找到一个正确执行此操作的库。我不明白你在 RSA 上下文中的参数是什么意思。您能否为 RSA 提供一个“邪恶”参数的具体示例？公钥密码术是当今最普通的密码术，用于每个 HTTPS 请求。 不使用混合加密是不寻常的，当 CMS 或 TLS 等标准支持它时，它通常是事后考虑，受到较少审查，不太可能在实施中得到支持。
使用 OpenSSL speed 子命令对算法进行基准测试并亲自查看。
[dave@hal9000 ~]$ openssl speed aes-128-cbc
Doing aes-128 cbc for 3s on 16 size blocks: 26126940 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 64 size blocks: 7160075 aes-128 cbc's in 3.00s
...
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128 cbc 139343.68k 152748.27k 155215.70k 155745.61k 157196.29k
[dave@hal9000 ~]$ openssl speed rsa2048
Doing 2048 bit private rsa's for 10s: 9267 2048 bit private RSA's in 9.99s
Doing 2048 bit public rsa's for 10s: 299665 2048 bit public RSA's in 9.99s
...
sign verify sign/s verify/s
rsa 2048 bits 0.001078s 0.000033s 927.6 29996.5
【讨论】：
实际的基于 PKI 的加密系统使用非对称加密来加密对称密钥，然后使用该密钥进行对称加密来加密数据（话虽如此，有人会指出一个反例）。
因此，非对称加密算法相对于对称加密算法的额外开销是固定的 - 它不取决于数据大小，仅取决于密钥大小。
上次我对此进行测试时，验证一连串大约 3 个 X.509 证书 [编辑添加：以及他们正在签名的数据] 在 100MHz 左右运行的 ARM 上花费了几分之一秒（平均超过很明显，重复了很多次）。我不记得有多小 - 不是可以忽略不计，但不到一秒。
抱歉，我不记得确切的细节，但总结是，除非您使用非常受限的系统或进行大量加密（例如，如果您希望每秒接受尽可能多的 SSL 连接）， NIST 批准的非对称加密方法速度很快。
【讨论】：
-
Bullrun 于 2013 年被揭露后，“NIST-approved”这个词听起来几乎就像一个笑话。它们速度很快（也许，只是可能会将您的数据泄露给 NSA）。
-
通过该评论，我的意思是答案并没有真正成熟:)
显然它差了 1000 倍。 (http://windowsitpro.com/article/articleid/93787/symmetric-vs-asymmetric-ciphers.html)。但除非你真的在处理大量数据，否则这无关紧要。您可以做的是使用非对称加密来交换对称加密密钥。
【讨论】：
也许您可以添加一些有关您的项目的详细信息，以便获得更高质量的答案。你想保护什么？从谁？如果你能解释你的安全要求，你会得到一个更好的答案。如果加密机制不能保护您认为的那样，性能就没有多大意义。
例如，X509 证书是保护客户端/服务器端点的工业标准方式。 PGP 装甲可用于保护许可证文件。为简单起见，如果您控制两个端点，使用 Blowfish（和许多其他密码）的密码块链接很容易在 Perl 或 Java 中使用。
谢谢。
【讨论】：
是的，PGP、TLS 和 CMS 等标准化加密方案提供的混合加密确实对每条消息或会话施加了固定的性能成本。这种影响有多大取决于所选的算法以及您所谈论的操作。
对于 RSA，解密和签名操作相对较慢，因为它需要使用较大的私有指数进行模幂运算。另一方面，RSA 加密和签名验证非常快，因为它使用小的公共指数。这种差异与密钥长度成二次方。
在 ECC 下，由于对等节点使用大小相似的密钥执行相同的数学运算，因此操作比 RSA 更加平衡。在集成加密方案中，可以生成临时 EC 密钥，并用于密钥协商算法；这需要消息发送者做一些额外的工作。 ECDH 密钥协议比 RSA 加密慢很多，很多，但比 RSA 解密快很多。
就相对数字而言，使用 AES 解密可能比使用 RSA 解密快 100,000 倍。就绝对数字而言，很大程度上取决于硬件，AES 每个块可能需要几纳秒，而 RSA 需要 毫秒 或两个。这就提出了一个问题，为什么有人会使用非对称算法？
答案是这些算法在混合加密方案中出于不同目的一起使用。 AES 等快速对称算法用于保护消息本身，而 RSA 等慢速非对称算法反过来用于保护对称算法所需的密钥。这使得以前从未共享任何秘密信息的各方（例如您和您的搜索引擎）能够安全地相互通信。
【讨论】：