I want to compute the CBC-MAC of a given plaintext with openssl. I have the following plaintext (hexdump):
hexdump -C example.txt
00000000 4d 41 43 73 20 61 72 65 20 76 65 72 79 20 75 73 |MACs are very us|
00000010 65 66 75 6c 20 69 6e 20 63 72 79 70 74 6f 67 72 |eful in cryptogr|
00000020 61 70 68 79 21 20 20 20 20 20 20 20 20 20 20 20 |aphy! |
If I use the command line function of openssl I get the following solution:
openssl aes-256-cbc -in example.txt -K 8000000000000000000000000000000000000000000000000000000000000001 -e -iv 00 | hexdump -C
00000000 e8 e9 a4 ce 5d 20 c4 ad f5 52 b2 c6 38 2e 12 4e |....] ...R..8..N|
00000010 20 f5 63 65 b4 b3 96 9f ad 8d ca e4 e8 34 2a e5 | .ce.........4*.|
00000020 0d 82 0e 3a 1e 10 5d 30 72 16 fc 00 c7 a5 b4 49 |...:..]0r......I|
00000030 f5 63 9f 85 ff e3 a4 a4 23 6e 6f 09 20 ed b1 ae |.c......#no. ...|
So far so good. I have one extra block because the first block should be the encrypted IV. Now the last line should be my CBC-MAC, if I understood it correctly. Next I tried to do the same thing in C, here is the example code:
#include <stdio.h>
#include <string.h>
#include <openssl/sha.h>
#include <openssl/aes.h>
int main(int argc, char *argv[])
{
unsigned char obuf[64] = {0};
unsigned char decbuf[48] = {0};
unsigned char msg1[] = {0x4d, 0x41, 0x43, 0x73, 0x20, 0x61, 0x72, 0x65, 0x20, 0x76, 0x65, 0x72, 0x79, 0x20, 0x75, 0x73,
0x65, 0x66, 0x75, 0x6c, 0x20, 0x69, 0x6e, 0x20, 0x63, 0x72, 0x79, 0x70, 0x74, 0x6f, 0x67, 0x72,
0x61, 0x70, 0x68, 0x79, 0x21, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20};
unsigned char key[] = {0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01};
unsigned char ivenc[] ={0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
unsigned char ivdec[] ={0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
int i=0;
AES_KEY enc_key, dec_key;
AES_set_encrypt_key(key, 256, &enc_key);
AES_cbc_encrypt(msg1, obuf, 48, &enc_key, ivenc, AES_ENCRYPT);
for (i = 0; i < 64; i++) {
if (!(i%16))
printf("\n");
printf("%02x ", obuf[i]);
}
printf("\n");
AES_set_decrypt_key(key, 256, &dec_key);
AES_cbc_encrypt(obuf, decbuf, 64, &dec_key, ivdec, AES_DECRYPT);
for (i = 0; i < 48; i++) {
if (!(i%16))
printf("\n");
printf("%02x ", decbuf[i]);
}
printf("\n");
return 0;
}
I decrypt the encrypted message afterwards to verify my code. The output of my code is pretty surprising:
e8 e9 a4 ce 5d 20 c4 ad f5 52 b2 c6 38 2e 12 4e
20 f5 63 65 b4 b3 96 9f ad 8d ca e4 e8 34 2a e5
0d 82 0e 3a 1e 10 5d 30 72 16 fc 00 c7 a5 b4 49
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
4d 41 43 73 20 61 72 65 20 76 65 72 79 20 75 73
65 66 75 6c 20 69 6e 20 63 72 79 70 74 6f 67 72
61 70 68 79 21 20 20 20 20 20 20 20 20 20 20 20
The encrypted message is completely identical to the command line output, except the last line is all 0. I thought, that the first line is the encrypted IV and the three following lines are the encrypted message, so with my interpretation the last line of the message wasn't encrypted. But to my surprise the decryption results exactly to the text I used as input, so it seems that there is no loss of information.
Questions:
Your mistake is here:
I have one extra block because the first block should be the encrypted IV.
The extra block is because OpenSSL adds padding to the plain text, so that it is a multiple of the block size (16 bytes for AES). In this case the plain text is already a multiple of 16 bytes, but the padding scheme used (PKCS7) always adds padding, so here an entire block is added before encryption.
It’s common to add the IV to the front of the ciphertext, but that’s not what’s happening here.
In order to get the same result from your code you will need to add this padding yourself. In this case it is fairly simple, just add sixteen 0x10 bytes to the end of msg1 (so its toal length is 64), and change the 48 in the call to AES_cbc_encrypt to 64. The zeros you are seeing a just the value you initialize obuf to, since you are only writing 48 bytes into this buffer.