AES256 CBC加解密速度差异咨询：解密为何远快于加密？

我编写了一个基于libgcrypt库的C程序，测试AES256 CBC算法的加解密速度。程序逻辑是在3秒内尽可能多地执行加/解密操作，之后计算处理字节总量并转换为MB/秒的速度，每次操作处理256字节的数据块。

测试发现，解密过程在相同时间内处理的数据量远多于加密，甚至达到加密的3倍。在另一台机器上运行相同代码，结果一致；但在树莓派（RPI）设备上，两者速度基本相同。我怀疑代码存在问题，希望得到相关分析与见解。

测试代码 #

enum op {
    ENC = 0,
    DEC
};

void measure_crypto_performance(enum op op)
{
    #define BUFFER_SIZE 256
    #define TEST_TIME 3

    /* Initialize the library */
    gcry_check_version(NULL);

    /* Set the decryption algorithm */
    gcry_cipher_hd_t handle;
    gcry_cipher_open(&handle, GCRY_CIPHER_AES256, GCRY_CIPHER_MODE_CBC, 0);

    /* Set the decryption key */
    char key[32];
    for (int i = 0; i < 32; ++i)
        key[i] = i;
    gcry_cipher_setkey(handle, key, sizeof(key));

    /* Set the decryption initialization vector */
    char iv[16] = "0123456789abcdef";

    /* Set up the buffer for the ciphertext and plaintext */
    char plaintext[BUFFER_SIZE];
    char ciphertext[BUFFER_SIZE];
    char decrypted_data[BUFFER_SIZE];

    gcry_randomize((void *)plaintext, BUFFER_SIZE, GCRY_STRONG_RANDOM);

    if (op == DEC)
    {
        gcry_cipher_setiv(handle, iv, sizeof(iv));
        gcry_cipher_encrypt(handle, ciphertext, BUFFER_SIZE, plaintext, BUFFER_SIZE);
    }

    size_t counter = 0;
    time_t start_time = time(NULL);
    if (op == ENC)
    {
        while (time(NULL) - start_time < TEST_TIME) {
            gcry_cipher_setiv(handle, iv, sizeof(iv));
            gcry_cipher_encrypt(handle, ciphertext, BUFFER_SIZE, plaintext, BUFFER_SIZE);
            ++counter;
        }
    } else if (op == DEC)
    {
        while (time(NULL) - start_time < TEST_TIME) {
            gcry_cipher_setiv(handle, iv, sizeof(iv));
            gcry_cipher_decrypt(handle, decrypted_data, BUFFER_SIZE, ciphertext, BUFFER_SIZE);
            ++counter;
        }
    }

    /* Calculate performance */
    double elapsed_time = difftime(time(NULL), start_time);
    double speed = ((counter * BUFFER_SIZE) / 1000000) / (elapsed_time);

    /* Print results */
    printf("Op: %s\n", op == DEC ? "Decryption" : "Encryption");
    printf("Decrypted %lld bytes in %.2lf seconds\n", counter * BUFFER_SIZE, elapsed_time);
    printf("Speed: %.2lf Mbytes/sec\n", speed);

    /* Clean up */
    gcry_cipher_close(handle);
}

int main(int argc, char **argv)
{
    gpt_test(DEC);
    gpt_test(ENC);
    return 0;
}

测试结果 #

Op: Decryption
Decrypted 9276416000 bytes in 3.00 seconds
Speed: 3092.00 Mbytes/sec
Op: Encryption
Encrypted 3099484416 bytes in 3.00 seconds
Speed: 1033.00 Mbytes/sec

分析与见解 #

1. 硬件加速优化差异 #

多数现代x86/x86_64处理器支持AES-NI指令集，libgcrypt会自动启用硬件加速。AES解密的硬件指令（如AESDEC系列）在执行效率上可能比加密指令（AESENC系列）更高，或者libgcrypt对解密路径的优化更充分。而树莓派基于ARM架构，其硬件加密扩展对AES加解密的优化程度相近，因此两者速度差异不明显。

2. 编译器优化的潜在影响 #

解密输出的decrypted_data没有被后续使用，编译器可能会优化掉部分解密操作，导致实际执行的工作量减少。而加密后的ciphertext虽然也没被使用，但libgcrypt的加密实现可能有防优化处理，或者编译器无法识别加密操作的可优化性。可以通过在循环后添加对decrypted_data和ciphertext的使用（比如计算校验和）来验证这一点。

3. 代码冗余操作 #

测试循环中每次调用gcry_cipher_setiv是不必要的：CBC模式下，只有首次加密/解密需要设置IV，后续块会自动使用前一块的密文作为IV。重复设置IV会引入额外的函数调用开销，但加密和解密路径都存在这个问题，因此这不是导致差异的直接原因，但优化后可提升整体性能。另外，main函数中调用的gpt_test是笔误，实际应为measure_crypto_performance，但不影响测试结果。

4. 计时精度误差 #

使用time(NULL)计时精度为秒，无法捕捉小于1秒的时间差，可能导致速度计算存在误差。建议使用更高精度的计时函数（如clock_gettime(CLOCK_MONOTONIC, ...)）提升准确性。

优化建议 #

• 移除循环内的gcry_cipher_setiv调用，仅在循环前设置一次IV。
• 对输出数据做实际使用（如计算CRC32），避免编译器优化掉核心操作。
• 使用高精度计时函数替代time(NULL)，提升速度计算的准确性。
• 检查libgcrypt的配置，确认是否启用了硬件加速（可通过gcry_control(GCRYCTL_GET_CAPABILITY, GCRY_CAP_AES)等接口查询）。

内容的提问来源于stack exchange，提问作者user11729819