简体繁体 English

AES256 CBC 与 AES256 GCM 性能？

[英]AES256 CBC vs AES256 GCM performance?

原文 2022-07-21 13:33:38 1 1 encryption/ aes/ aes-gcm/ initialization-vector

Based on what I have searched, AES256 CBC seems to be slower than AES256 GCM.根据我的搜索，AES256 CBC 似乎比 AES256 GCM 慢。

However today I test both modes on iPhone 13 Pro Max simulator and they makes me confused.但是今天我在 iPhone 13 Pro Max 模拟器上测试了这两种模式，它们让我感到困惑。

With AES256 CBC, I use an obj-c library called CommonCrypto, with AES256 GCM I use the CryptoKit https://developer.apple.com/documentation/cryptokit/aes/gcm对于 AES256 CBC，我使用名为 CommonCrypto 的 obj-c 库，对于 AES256 GCM，我使用 CryptoKit https://developer.apple.com/documentation/cryptokit/aes/gcm

The result was with a string of 3MB, AES256 CBC 128-bit iv took 3s to encrypt or decrypt while AES256 GCM 96-bit iv took 10s!结果是一个 3MB 的字符串，AES256 CBC 128-bit iv 需要 3s 来加密或解密，而 AES256 GCM 96-bit iv 需要 10s！

What could be wrong here?这里有什么问题？

1 个解决方案

First of all, AES CBC should never be slower than GCM if each AES block cipher operation takes the same time.首先，如果每个 AES 分组密码操作花费相同的时间，则 AES CBC 永远不会比 GCM 慢。 AES-CBC only performs a XOR between the block encrypts, and XOR's are so fast that the overhead should be negligible. AES-CBC 仅在块加密之间执行 XOR，并且 XOR 的速度如此之快，以至于开销应该可以忽略不计。 AES-GCM however consists of counter (CTR) mode & GMAC calculations.然而，AES-GCM 包括计数器 (CTR) 模式和 GMAC 计算。 CTR uses a 128-bit counter (negligible) and a XOR. CTR 使用 128 位计数器（可忽略）和 XOR。 However, the GMAC will have to be performed on top of that.但是，必须在此基础上执行 GMAC。 It depends on the hardware how fast a Galois multiplication is, but it can be made relatively fast on ARM .伽罗瓦乘法的速度取决于硬件，但它可以在 ARM 上相对较快。

However, a lot depends on the implementation specifics.但是，很大程度上取决于实现细节。 Objective-C is very fast and using managed code / swift may introduce an overhead, even if the actual implementation is again in C. This can especially hurt you if you don't allow for a warm up time in case an interpreter is used, as some operations will only be accelerated once they have been executed a few times. Objective-C 非常快，使用托管代码/swift 可能会引入开销，即使实际实现再次在 C 中。如果在使用解释器的情况下不允许预热时间，这可能会特别伤害你，因为某些操作只有在执行几次后才会加速。

CBC is quite often supplied as a streaming implementation, which means that the memory consumption can be relatively limited. CBC 通常作为流式实现提供，这意味着内存消耗相对有限。 If GCM only allows for everything in memory (as you want to verify the tag anyway before using the decrypted plaintext) then this may introduce overhead as well.如果 GCM 只允许内存中的所有内容（因为您想在使用解密的明文之前验证标签），那么这也可能会引入开销。

Note that if the key is stored in a key store vs memory then this may also make a lot of difference.请注意，如果密钥存储在密钥存储与内存中，那么这也可能会产生很大的不同。 Quite often the key will use a specific trusted environment if it is present in a key store, otherwise it would need to be copied out of the trusted environment to be used, which largely negates any benefit of having the trusted environment in the first place.如果密钥存在于密钥存储中，则密钥通常会使用特定的受信任环境，否则需要将其从受信任环境中复制出来才能使用，这在很大程度上否定了拥有受信任环境的任何好处。

Finally, simulators are not emulators;最后，模拟器不是模拟器。 they may not perform the operations in the same (relative) time.他们可能不会在相同（相对）时间内执行操作。 So relying on simulators for speed tests in itself is a flawed premise.因此，依靠模拟器进行速度测试本身就是一个有缺陷的前提。

Speed tests are notoriously tricky to get right, and if you mix in cryptography then it just got a whole lot trickier.速度测试是出了名的棘手，如果你混合使用密码学，那么它就会变得更加棘手。