0
$\begingroup$

I am learning/exploring the openssl library for encrypting and decrypting data while encryption goes through fine I see standalone decryption not working as I expected.

The test vector I am using is

# Key 2b7e151628aed2a6abf7158809cf4f3c
# IV 000102030405060708090a0b0c0d0e0f
# Block #1
# Plaintext 6bc1bee22e409f96e93d7e117393172a
# Input Block 6bc0bce12a459991e134741a7f9e1925
# Output Block 7649abac8119b246cee98e9b12e9197d
# Ciphertext 7649abac8119b246cee98e9b12e9197d

I basically want to take the hexstring for CT and derive the hex string for PT, im aware that i need to convert the hex string to bytes thats not an issue.

Now while encrypting data I found that there are 16 bytes being added for padding, so i started looking into disabling padding and came across EVP_CIPHER_CTX_set_padding() but when calling this function after EVP_EncryptInit_ex() my code segfaults.

I am basically modifying the sample testapp to try and get this to work. Evp-symmetric-encrypt.c

int encrypt(unsigned char *plaintext, int plaintext_len, unsigned char *key,
            unsigned char *iv, unsigned char *ciphertext)
{
    EVP_CIPHER_CTX *ctx;
    int len;
    int ciphertext_len;

    if(!(ctx = EVP_CIPHER_CTX_new()))
        handleErrors();

    if(1 != EVP_EncryptInit_ex(ctx, EVP_aes_128_cbc(), NULL, key, iv))
        handleErrors();

    #if 0
    // adding this segfaults
    printf("[%s::%d] disabling padding ... \n",__func__, __LINE__);
    if(1 != EVP_CIPHER_CTX_set_padding(ctx, 0))
        handleErrors();
    #endif

    if(1 != EVP_EncryptUpdate(ctx, ciphertext, &len, plaintext, plaintext_len))
        handleErrors();
    ciphertext_len = len;

    if(1 != EVP_EncryptFinal_ex(ctx, ciphertext + len, &len))
        handleErrors();
    ciphertext_len += len;

    EVP_CIPHER_CTX_free(ctx);

    return ciphertext_len;
}

My goal is to be able to encrypt and decrypt nist test vectors for cbc/ctr/gcm/xts without the additional padded data got from encryption.

Is this possible ?

If not is it possible to generate the padded block ??

Ciphertext is:
************
[ 0->] p :: 0x76
[ 1->] p :: 0x49
[ 2->] p :: 0xab
[ 3->] p :: 0xac
[ 4->] p :: 0x81
[ 5->] p :: 0x19
[ 6->] p :: 0xb2
[ 7->] p :: 0x46
[ 8->] p :: 0xce
[ 9->] p :: 0xe9
[10->] p :: 0x8e
[11->] p :: 0x9b
[12->] p :: 0x12
[13->] p :: 0xe9
[14->] p :: 0x19
[15->] p :: 0x7d
-------------------
// Can this below part be generated before decryption ?
[16->] p :: 0x89
[17->] p :: 0x64
[18->] p :: 0xe0
[19->] p :: 0xb1
[20->] p :: 0x49
[21->] p :: 0xc1
[22->] p :: 0xb
[23->] p :: 0x7b
[24->] p :: 0x68
[25->] p :: 0x2e
[26->] p :: 0x6e
[27->] p :: 0x39
[28->] p :: 0xaa
[29->] p :: 0xeb
[30->] p :: 0x73
[31->] p :: 0x1c
************

Did I miss anything while calling EVP_CIPHER_CTX_set_padding() ?

Improve this question
$\endgroup$
3
  • $\begingroup$ I am seeing this padding for AES-CBC in particular, is there some reference for different padding used for various algorithms like CBC, GCM and XTS ? $\endgroup$
    – Eddy
    Oct 2, 2022 at 9:50
  • $\begingroup$ CTR and GCM do not pad data *1 and XTS uses ciphertext stealing, using the previous ciphertext as "padding". Most modern / streaming modes don't require padding, which surprises most devs that have grown up with ECB / CBC and standard libraries. *1, well GMAC can be thought of to pad data, but that's an internal operation which should be invisible from the outside, especially from EVP higher level functions. $\endgroup$
    – Maarten Bodewes - on strike ♦
    Oct 2, 2022 at 20:21
  • $\begingroup$ Thanks for the info. $\endgroup$
    – Eddy
    Oct 4, 2022 at 5:34

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Browse other questions tagged or ask your own question.