在Raspberry PI 2上使用OpenSSL AES/GCM的性能差得离谱 我开发了一个简单的C++程序，以测试OpenSSL AES/GCM调用对EVP接口的性能。它所做的是获取一个1024字节的字符串，用一个密钥加密它，然后用相同的密钥加密结果，然后一次又一次地加密。我正在使用增量4字节初始化向量

当我在我的Macbook Pro（Intel i7）上测试它时，结果非常令人印象深刻：在一个内核上运行上述过程的1048576次迭代只需一秒钟。这是1 GB/s的加密速度。如果我们同时使用所有的内核，则为8 GB/s（或多或少）

现在，我在Raspberry PI 2上移植了相同的基准。然而，当我运行它时，执行1024次迭代需要0.16秒。在单个内核上，这大约是6MB/s

现在，我明白了，现代的、昂贵的i7处理器和运行在覆盆子上的小型ARM处理器之间有着巨大的差别，但速度还是快了170倍。所以在假设Raspberry PI 2真的那么糟糕之前，我想检查一下这些参数是否合理

有人在这方面做过一些基准吗？覆盆子上6 MB/s的加密速度合理吗？还是我做错了什么

（我正在通过我的Macbook USB为它供电：会不会因为它没有接收到足够的电源而如此缓慢？这听起来绝对不合理。它根本不会通电，对吗？或者会有一个倒计时机制来节省电源？）

更新1：我在Macbook和Raspberry上都使用了

openssl-evp speed aes-256-cbc

在Macbook上：

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256-cbc     534591.95k   564057.62k   566522.81k   570717.87k   574876.33k

关于覆盆子：

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256-cbc      14288.53k    16653.74k    17165.31k    17298.43k    17337.00k

---

这仍然是一个因素33，但英特尔处理器可以利用硬件加速AES调用。不过，据我所知，GCM模式应该比CBC快得多。我不知道为什么，但看起来似乎没有一个适用于GCM的openssl基准测试，但即使假设它们的性能相同，我也忽略了一个因素3

---

更新2已选中此页面：。看起来我又少了10 MB/s。总计：使用AES/CBC时为27MB/s（应该是这样），而使用AES/GCM时为6MB/s（实际上是这样）。

如果您还没有考虑到这一点，为什么不用处理能力的大约3个差异来解释因子3

Raspberry Pi 2有一个900Mhz的处理器，而典型的i7处理器有2.8Ghz，这导致Pi的处理能力大约为三分之一

另外，我不知道你从哪里得出结论，在这种情况下，GCM应该比CBC更快。CBC不提供身份验证，因此仅此一项就应该使GCM的速度显著降低（尽管可能不是您看到的4倍）

---

当然，考虑到CBC不能并行化，GCM也可以并行化，当您引入多核时，这一点就不存在了。

您的英特尔CPU使用AESNI扩展提供了专用硬件支持。 如果编译时不使用该选项，将获得大约250MB/s的速度

---

这种性能上的差异听起来是合理的。（任何CPU有多少GHz都不能说明性能，除非它是完全相同的CPU类型，只是时钟不同）

我在寻找提高pi2的SSH/SCP性能的方法时发现了这一点。你的表现有什么提高吗？我找到了，但还没有找到。我想找一些低功耗（不一定是pi）的东西，让我的SSH速度足够快，可以将低到中等分辨率的媒体从NAS传输到我的手机。@Nanook我真的很抱歉，但如果我记得清楚的话，我没有深入讨论这个问题。我想我从来没有获得过更高的表现，但我的记忆力不好。祝你好运！“尽管如此，据我所知，GCM模式应该比CBC快很多。”这是不正确的。如果您有X个块，CBC只需要X个密码计算，而GCM需要（2*X）+1个块计算，再加上中间Galouis字段的一些数学运算。Pi4有任何更新吗？现在现代CPU尽可能多地同时进行，您无法立即将时钟速度与相对性能关联起来。这就是为什么cpu的速度更快，同时保持大致相同的时钟速度。据我所知，Rasåberry ARM cpu并不具备所有这些功能。