Question

所以我一直在为CBC和GCM的不同AES实现进行广泛的搜索，我不想在我犯错误的情况下实现这一点，所以我找到了以下AES CBC代码并测试了它们的速度在我的RX63NB（瑞萨测试板）上。

                    Encrypt                 Decrypt 
                    bytes   speed (us)      bytes   speed (us)
Tiny AES            64      1500            64      8900
                    128     2880            128     17820
aes-byte-29-08-08   64      1250            64      4900
                    128     1220            128     9740
Cyclone             64      230             64      237
                    128     375             128     387

我很惊讶Cyclone的速度有多快，澄清我从CycloneSSL获取了AES，CBC和Endian文件并仅使用了这些文件。

然后我从CycloneSSl尝试了GCM，这是输出：

                    Encrypt                 Decrypt 
                    bytes   speed μs        bytes   speed μs
Cyclone   GCM       64      9340            64      9340
                    128     14900           128     14900

我已经考虑了HMAC时间（来自CycloneSSL），看看会花多少时间：

HMAC        bytes   speed μs
Sha1        64      746
            128     857
Sha224      64      918
            128     1066
Sha256      64      918
            128     1066
Sha384      64      2395
            128     2840
Sha512      64      2400
            128     2840
Sha512_224  64      2390
            128     2835
Sha512_356  64      2390
            128     2835
MD5         64      308
            128     345
Whirlpool   64      5630
            128     6420
Tiger       64      832
            128     952

最慢的是漩涡。

如果将128字节的cbc加密时间添加到128字节的漩涡的hmac，则得到6795μs，这大约是GCM所用时间的一半。

现在我可以理解，GHASH比HMAC需要更长的时间，因为有了galios字段，但是比我知道的最慢的HASH算法慢了2倍。

所以我开始怀疑我是否做错了或者CycloneSLL gcm实现是否真的显示出来。不幸的是，我还没有在c中找到其他易于使用的GCM实现来与之进行比较。

我使用的所有代码都可以是found on pastebin，不同的文件由--------------------

分隔

这是我用GCM加密的代码：

static void test_encrypt(void)
{
  uint8_t key[] = { 0x2b, 0x7e, 0x15, 0x16, 0x28, 0xae, 0xd2, 0xa6, 0xab, 0xf7, 0x15, 0x88, 0x09, 0xcf, 0x4f, 0x3c };
  uint8_t iv[]  = { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f };
  uint8_t in[]  = { 0x48, 0x61, 0x6c, 0x6c, 0x6f, 0x20, 0x68, 0x6f, 0x65, 0x20, 0x67, 0x61, 0x61, 0x74, 0x20, 0x68,
                    0x65, 0x74, 0x20, 0x6d, 0x65, 0x74, 0x20, 0x6a, 0x6f, 0x75, 0x20, 0x76, 0x61, 0x6e, 0x64, 0x61,
                    0x61, 0x67, 0x2c, 0x20, 0x6d, 0x65, 0x74, 0x20, 0x6d, 0x69, 0x6a, 0x20, 0x67, 0x61, 0x61, 0x74,
                    0x20, 0x68, 0x65, 0x74, 0x20, 0x67, 0x6f, 0x65, 0x64, 0x20, 0x68, 0x6f, 0x6f, 0x72, 0x2e, 0x21,
                    0x48, 0x61, 0x6c, 0x6c, 0x6f, 0x20, 0x68, 0x6f, 0x65, 0x20, 0x67, 0x61, 0x61, 0x74, 0x20, 0x68,
                    0x65, 0x74, 0x20, 0x6d, 0x65, 0x74, 0x20, 0x6a, 0x6f, 0x75, 0x20, 0x76, 0x61, 0x6e, 0x64, 0x61,
                    0x61, 0x67, 0x2c, 0x20, 0x6d, 0x65, 0x74, 0x20, 0x6d, 0x69, 0x6a, 0x20, 0x67, 0x61, 0x61, 0x74,
                    0x20, 0x68, 0x65, 0x74, 0x20, 0x67, 0x6f, 0x65, 0x64, 0x20, 0x68, 0x6f, 0x6f, 0x72, 0x2e, 0x21};

  AesContext context;
  aesInit(&context, key, 16 ); // 16 byte = 128 bit      
  error_crypto_t error = gcmEncrypt(AES_CIPHER_ALGO, &context, iv, 16, 0, 0, in, in, 128, key, 16);
}

static void test_decrypt(void)
{
  uint8_t key[] = { 0x2b, 0x7e, 0x15, 0x16, 0x28, 0xae, 0xd2, 0xa6, 0xab, 0xf7, 0x15, 0x88, 0x09, 0xcf, 0x4f, 0x3c };
  uint8_t tag[] = { 0x56, 0x56, 0x5C, 0xCD, 0x5C, 0x57, 0x36, 0x66, 0x73, 0xF7, 0xFF, 0x2A, 0x17, 0x49, 0x0E, 0xC4};
  uint8_t iv[]  = { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f };
  uint8_t out[] = { 0x05, 0x7C, 0x51, 0xFF, 0xE4, 0x9F, 0x8C, 0x90, 0xF1, 0x7D, 0x56, 0xFB, 0x87, 0xB9, 0x44, 0x79,
                    0xB1, 0x04, 0x32, 0x39, 0x78, 0xFF, 0x51, 0x60, 0x48, 0x0B, 0x21, 0x77, 0xF2, 0x26, 0x0B, 0x94,
                    0x7B, 0xA7, 0x26, 0x74, 0x87, 0xA8, 0x2C, 0x5A, 0xA1, 0x19, 0x03, 0x17, 0x66, 0x3A, 0x46, 0x9F,
                    0xE6, 0x1D, 0x3B, 0x65, 0xFD, 0xC0, 0xBA, 0xC0, 0xD9, 0x45, 0xE7, 0x17, 0x74, 0x0F, 0xB7, 0x4B,
                    0x0F, 0xF0, 0x16, 0xF6, 0xE8, 0x4F, 0xFD, 0x96, 0x64, 0x5E, 0xDB, 0x9E, 0x3A, 0x0B, 0x93, 0x8F,
                    0x87, 0x83, 0x90, 0xF8, 0xF9, 0xE6, 0xA3, 0xE7, 0x5E, 0x72, 0x3C, 0xB5, 0x98, 0x54, 0x11, 0xD7,
                    0xB4, 0x7C, 0xFF, 0xA3, 0x51, 0x1A, 0xB0, 0x69, 0x4F, 0x57, 0xBB, 0x83, 0x40, 0x2A, 0xE6, 0x75,
                    0x8B, 0xB5, 0xCA, 0xA4, 0x84, 0x82, 0x1D, 0xA8, 0x94, 0x03, 0x77, 0x9C, 0x3B, 0xF8, 0xA0, 0x60};

  AesContext context;
  aesInit(&context, key, 16 ); // 16 byte = 128 bit
  error_crypto_t error = gcmDecrypt(AES_CIPHER_ALGO, &context, iv, 16, 0, 0, out, out, 128, tag, 16);
}

out []中的数据是来自in []的gcm加密数据，它们都能正常工作。（正确解密并通过身份验证。

问题

所有GCM实施都这么慢吗？
还有其他（更好的）GCM实施吗？
如果我想要快速加密+验证，我应该使用HMAC吗？

修改

我能够从mbedTLS (PolarSSL)获得GCM方法，比旋风快11倍（加密/解密128字节需要880us）。它产生与cylcone GCM相同的输出，所以我相信这是正常的。

gcm_context gcm_ctx;
gcm_init(&gcm_ctx, POLARSSL_CIPHER_ID_AES,key, 128);
int error = gcm_auth_decrypt(&gcm_ctx, 128,iv, 16, NULL, 0, tag, 16, out, buffer );

Answer 1

您的数字看起来很奇怪，aes-byte-29-08-08的128字节比加密的64字节花费更少的时间？

假设RX63N与Cortex-M相当（它们都是32位，没有矢量单位，并且很难在RX63N上找到信息）：

SharkSSL声称的基准测试使CBC的速度比GCM快两倍，如果针对速度进行优化，则为2.6。 9340比340更大。

Cifra的基准测试显示他们的AES和AES-GCM之间的差异为10倍，尽管GCM测试还包括auth-data。仍然无法接近直接AES和GCM之间的差异。

因此，相对而言，回答1，我并不认为相对于普通的AES，所有GCM实现都很慢。

至于其他GCM的实现，还有前面提到过的Cifra（虽然直到现在我还没有听说过它，它在GitHub上只有3颗星（如果这意味着什么），所以水平审查的可能性相当低，也许您可以从FreeBSD中删除AES-GCM实施。我无法在您的平台上以绝对术语谈论性能。

无论实施如何，HMAC在没有硬件支持的平台上都可能更快，如AES-NI支持（CLMUL）。这对性能至关重要吗？你必须使用AES或分组密码吗？也许ChaCha20 + Poly1305更适合您的性能需求（参见Cifra的性能数据）。现在用于OpenSSH - chacha。*和poly1305。*

注意侧面通道攻击。 AES的软件实现可能对高速缓存定时攻击敏感，尽管我不认为这适用于无论如何都在SRAM中的所有微控制器。

* Salsa20是ChaCha20的前身

AES-CBC + HMAC和AES-GCM之间的极端时间差异

1 个答案: