AES_cbc_encrypt是否添加padding？ [英] Does AES_cbc_encrypt add padding?

问题描述

请考虑以下C ++代码片段：

Consider the following snippet of C++ code:

#include <iostream>
#include <openssl/aes.h>

#define AES_KEY_LENGTH 32

using namespace std;

int main()
{
    AES_KEY encryption_key;
    AES_KEY decryption_key;

    unsigned char key[AES_KEY_LENGTH] = {'t', 'e', 's', 't', 't', 'e', 's', 't', 't', 'e', 's', 't', 't', 'e', 's', 't', 't', 'e', 's', 't', 't', 'e', 's', 't', 't', 'e', 's', 't', 't', 'e', 's', 't'};

    unsigned char iv[AES_BLOCK_SIZE] = {'t', 'e', 's', 't', 't', 'e', 's', 't', 't', 'e', 's', 't', 't', 'e', 's', 't'};

    unsigned char iv_enc[AES_BLOCK_SIZE];
    unsigned char iv_dec[AES_BLOCK_SIZE];

    memcpy(iv_enc, iv, AES_BLOCK_SIZE);
    memcpy(iv_dec, iv, AES_BLOCK_SIZE);

    AES_set_encrypt_key(key, AES_KEY_LENGTH * 8, &(encryption_key));
    AES_set_decrypt_key(key, AES_KEY_LENGTH * 8, &(decryption_key));

    char message[] = "Attack at dawn! Attack.";

    unsigned char * encryption_output = new unsigned char[32];
    encryption_output[31] = 3;

    AES_cbc_encrypt((unsigned char *) message, encryption_output, sizeof(message), &encryption_key, iv_enc, AES_ENCRYPT);

    unsigned char * decryption_output = new unsigned char[32];

    AES_cbc_encrypt(encryption_output, decryption_output, 32, &decryption_key, iv_dec, AES_DECRYPT);
}

我在这里做的是加密，然后使用openssl aes库解密邮件。我关心的是长度encryption_output。就我的理解，由于AES加密大小为AES_BLOCK_SIZE（也称为16字节）的块，输出字节数应该等于消息的大小，舍入到最接近的AES_BLOCK_SIZE的倍数。它是否正确？特别是，如果我将消息扩展为正好32字节长，会发生什么？这将仍然工作，或将添加16空填充字节，从而导致分段错误时尝试写入字节32到47在encryption_output？

What I do here is encrypt and then decrypt a message using openssl aes library. What I am concerned about is the length encryption_output. As far as my understanding goes, since AES encrypts in blocks of size AES_BLOCK_SIZE (aka 16 bytes) the number of output bytes should be equal to the size of the message, rounded up to the closest multiple of AES_BLOCK_SIZE. Is this correct? In particular, what happens if I extend the message to be exactly 32 bytes long? Will this still work, or will 16 empty padding bytes be added thus causing a segmentation fault when trying to write bytes 32 to 47 in encryption_output?

推荐答案

正确的PKCS＃7填充：

Proper PKCS#7 padding:

• 将长度舍入为块大小的倍数

否则，当解密时，你可能不知道最后一个ciperhtext块是真实还是只有填充。 （也要指定要填充的实际字节值，但是你的最后一个块可能包含这些=>再也不能识别它）。

Else, when decrypting, you couldn´t possibly know if the last ciperhtext block is "real" or only padding. (The actual byte values to pad with are specified too, but your real last block could contain these => again not possible to recognize it).

除了PKCS＃7之外，还有其他方案，但这里不相关。

There are other schemes than PKCS#7, but this is not relevant here.

但是，使用 AES_cbc_encrypt ，你必须自己实现。 pad，在解密之后加密并移除填充。加密本身将以非多个长度工作，但是所使用的填充具有上述问题。要回答你原来的问题， AES_cbc_encrypt 不能添加块，向上舍入长度是唯一的事情。

However, with AES_cbc_encrypt, you´ll have to implement this yourself, ie. pad before encrypting and remove the padding after decrypting. The encrypting itself will work with non-multiple lengths, but the used "padding" has the problem mentioned above. To answer your original question, AES_cbc_encrypt won´t add blocks, rounding up the length is the only thing it does.

对于具有适当填充的函数（并且没有 AES_cbc_encrypt 的其他一些缺点，比如缺少AESNI支持等。 ），查看OpenSSL的EVP部分。 AES_cbc_encrypt 是一个更低级的部分，这取决于它由高级功能使用的情况。

For functions with proper padding (and without several other disadvantages of AES_cbc_encrypt, like missing AESNI support etc.etc.), look into the EVP part of OpenSSL. AES_cbc_encrypt is a more lowlevel part, depending on the situation it´s used by the highlevel function too.

Btw。，关于C ++：如果你没有得到分段错误，

这并不意味着代码是正确的。

Btw., something about C++: If you don´t get a segmentation fault,
it doesn´t mean that the code is correct.

这篇关于AES_cbc_encrypt是否添加padding？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！