Simple AES encryption decryption with openssl library in C

Question

I want to encrypt a struct containing few String and then decrypt it. I tried following code. The original code is found from the web and it was working perfectly. I change

Answer 1

The problem might be in the struct you are using, basically because of the struct padding and member sizes. Try to serialize your input and it must work. in a simple way, try to allocate one char buffer and copy your struct contents to the buffer one by one and try to encrypt that buffer and while decrypting also follow the same method. Post here what you are observing after that. We must be able to comment better on that.

Answer 2

I would almost go so far as to say this is a problem with OpenSSL. It seems that when the length parameter passed to AES_cbc_encrypt is > AES_BLOCK_SIZE but not an integral multiple thereof (i.e. length mod AES_BLOCK_SIZE != 0), then the last block is encrypted using the initial IV and not the previous block of ciphertext as should be the case for CBC mode.

You can fix this in one of two ways:

Copy your struct to a buffer whose size is an integral multiple of AES_BLOCK_SIZE, or encrypt in two parts - the full blocks, followed by a single partial block. The latter has the advantage of avoiding additional memory usage and can be done as follows:

size_t fullBlocks = inputslength - (inputslength % AES_BLOCK_SIZE);
size_t remainingBlock = inputslength - fullBlocks;

AES_cbc_encrypt((unsigned char *)&ticket, enc_out, fullBlocks, &enc_key, iv_enc, AES_ENCRYPT);
AES_cbc_encrypt((unsigned char *)&ticket + fullBlocks, enc_out + fullBlocks, remainingBlock, &enc_key, iv_enc, AES_ENCRYPT);

You should then be able to decrypt as you currently are without issue. It's worth noting however that you should declare dec_out as the same size as enc_out, because you're currently overrunning the dec_out buffer when decrypting.

Edit:

I raised this as a bug in OpenSSL: https://rt.openssl.org/Ticket/Display.html?id=3182&user=guest&pass=guest and whilst there is some argument over whether this is actually a bug, or just (undocumented) undefined behavior, the general consensus is that the EVP routines should be used instead, rather than these low-level functions.

Answer 3

The original code has done the padding for you. The problem is that you passed the wrong plaintext length to AES function. You should pass encslength(padded length) to AES_cbc_encrypt. Just change this line

AES_cbc_encrypt((unsigned char *)&ticket, enc_out, inputslength, &enc_key, iv_enc, AES_ENCRYPT);

to

AES_cbc_encrypt((unsigned char *)&ticket, enc_out, encslength, &enc_key, iv_enc, AES_ENCRYPT);

This should solve your problem.

Answer 4

At least I also think it is not a good practise to use struct and sizeof(a_struct_type) here.

The actual binary sequence of the struct USR_TICKET and the result of sizeof will vary according to different padding and byte alignment implementation.

Here is the test result.

1) Firstly, I download the latest openssl1.0.2c and build it, and test the code here with this library on OS X 10.10.3, the code works fine.

2) And I tried to run the test for 5 times. Each time, even the original plain text will changed due to padding of struct(on my OS, the last 4 bytes will be changed every time).

3) So,the same input to the struct produced different plain text, which finally produced different cipher text. The user might be confused by the different cipher text output, when they try to encrypt the same input info(here raving, 1, 2015-6-25) with the same key and iv.

4) Furthermore, just change the struct internal definition, which will produce the same concern in description (3).

typedef struct ticket { /* test field */
int ticketId;
char username[19]; // here try to change from 20 to 19
    char date[20]; // here try to change from 20 to other size
} USR_TICKET;

PS. Some outputs result from above description(2),

Output1:

Give a key length [only 128 or 192 or 256!]:
128
Username - ravinda
Ticket Id - 1
Date - 2015-06-25
original:   01 00 00 00 72 61 76 69 6E 64 61 00 00 00 00 00 00 00 00 00 00 00 00 00 32 30 31 35 2D 30 36 2D 32 35 00 00 00 00 00 00 58 BB 3A 50 
encrypt:    BA 32 86 CC 71 55 2F 73 ED A1 C9 DE 00 32 1A 20 D9 A5 16 52 8A CD F0 F7 38 04 76 38 5A 47 35 3B A3 07 97 41 C4 C2 05 53 74 93 91 26 7E DE 40 47 
decrypt:    01 00 00 00 72 61 76 69 6E 64 61 00 00 00 00 00 00 00 00 00 00 00 00 00 32 30 31 35 2D 30 36 2D 32 35 00 00 00 00 00 00 58 BB 3A 50 
Username - ravinda
Ticket Id - 1
Date - 2015-06-25

Output2:

Give a key length [only 128 or 192 or 256!]:
128
Username - ravinda
Ticket Id - 1
Date - 2015-06-25
original:   01 00 00 00 72 61 76 69 6E 64 61 00 00 00 00 00 00 00 00 00 00 00 00 00 32 30 31 35 2D 30 36 2D 32 35 00 00 00 00 00 00 58 0B 10 5A 
encrypt:    BE 60 0F FC 17 A3 42 4A 95 7C 39 DB BF 2C BA 59 42 DC 0C AD B2 20 76 6A 04 E3 DE 11 3E D0 AF 88 A5 B9 D2 25 D4 AE F0 B7 82 9F 13 39 80 39 61 9D 
decrypt:    01 00 00 00 72 61 76 69 6E 64 61 00 00 00 00 00 00 00 00 00 00 00 00 00 32 30 31 35 2D 30 36 2D 32 35 00 00 00 00 00 00 58 0B 10 5A 
Username - ravinda
Ticket Id - 1
Date - 2015-06-25