0
$\begingroup$

The string is encrypted with the following properties (using C#):

myAes.Mode = CipherMode.CBC

myAes.KeySize = 128

myAes.Padding = PaddingMode.PKCS7

myAes.BlockSize = 128

myAes.FeedbackSize = 128

Key: 5753B8AA97BE5B5D9584864DF3134E64

This is my decryption function:

int AESdecrypt(unsigned char *ciphertext, size_t ciphertext_len, unsigned char *key, unsigned char *iv, unsigned char *plaintext)
  {
    EVP_CIPHER_CTX *ctx;

    int len;
      int retErrors=1;

    int plaintext_len;

    /* Create and initialise the context */
    if(!(ctx = EVP_CIPHER_CTX_new()))
    {
        LOGF_TRACE("\t Error in EVP_CIPHER_CTX_new");
        EVP_CIPHER_CTX_free(ctx);
        return 0;
    }

    /*
     * Initialise the decryption operation. IMPORTANT - ensure you use a key
     * and IV size appropriate for your cipher
     * In this example we are using 256 bit AES (i.e. a 256 bit key). The
     * IV size for *most* modes is the same as the block size. For AES this
     * is 128 bits
     */
    if(1 != EVP_DecryptInit_ex(ctx, EVP_aes_128_cbc(), NULL, key, iv))
    {
      LOGF_TRACE("\t Error in EVP_DecryptInit_ex");
      EVP_CIPHER_CTX_free(ctx);
      return 0;
    }

    /*
     * Provide the message to be decrypted, and obtain the plaintext output.
     * EVP_DecryptUpdate can be called multiple times if necessary.
     */
    if(1 != EVP_DecryptUpdate(ctx, plaintext, &len, ciphertext, ciphertext_len))
    {
      LOGF_TRACE("\t EVP_DecryptUpdate");
      EVP_CIPHER_CTX_free(ctx);
      return 0;
    }
        
    plaintext_len = len;

    /*
     * Finalise the decryption. Further plaintext bytes may be written at
     * this stage.
     */
    if(1 != EVP_DecryptFinal_ex(ctx, plaintext + len, &len))
    {
      LOGF_TRACE("\t EVP_DecryptFinal_ex");
      EVP_CIPHER_CTX_free(ctx);
      return 0;
    }
        
    plaintext_len += len;

    /* Clean up */
    EVP_CIPHER_CTX_free(ctx);

    return plaintext_len;
  }

However, when I try to decrypt the resulting string has 16 (0x10) extra bytes: (Removed some characters for security reasons).

0000 - 2e 3c 81 6b ed 2e 6b 59-fe 38 ae b7 56 11 1f c2   .<.k..kY.8..V...

0010 - 45 53 54 41 20 45 53 20-55 4e 41 20 50 52 55 45   ESTA ES UNA PRUE

0020 - 42 41 20 44 45 20 43 49-46 52 41 44 4f 20 41 45   BA DE CIFRADO AE

0030 - 53 20 50 41 52 41 20 45-54 48 45 52 4e 45 54 20   S PARA ETHERNET

0040 - XX XX XX XX XX XX XX XX-XX XX XX                  XXXXXXXX

I'd like to knnow if this is normal and I should just remove the first 16 bytes or how to avoid having those extra bytes (it doesn't feel normal for me).

Could this have anything to do with the IV they're using for encryption?

Thanks.

$\endgroup$
3
$\begingroup$

From your symptoms, it would appear that the IV is included with the ciphertext (as the first 16 bytes); you're leaving it on when you're calling AESdecrypt.

If so, then you have two options:

  • Extract the first 16 bytes from the ciphertext; pass those 16 bytes as the IV, and the rest (that is, with the first 16 bytes removed) as the ciphertext

  • Do what you're doing, and trim off the first 16 bytes of the decrypted plaintext.

BTW: with CBC mode, it is generally a good idea to include some sort of message authentication code (be it CMAC, HMAC or something else), that makes sure that someone cannot modify the ciphertext without being detected (as an attacker might otherwise be able to modify the ciphertext and have some control over how that modifies the decryption). Are you doing something to protect against that?

$\endgroup$
9
  • $\begingroup$ Would it be solved if the ciphertext is generated with and IV of 16 zeros? Because I am using an IV of 16 zeros for decryption. About the authentication we're still working on it. $\endgroup$ Jul 7 at 17:22
  • $\begingroup$ Also, can we be sure OpenSSL uses PKCS#7 for decryption as default? $\endgroup$ Jul 7 at 17:24
  • $\begingroup$ @DavidMerinos: an IV of all 0's is fine if that's the only message that'll be encrypted with this key; if you're reusing the key to encrypt multiple messages (which is usually, but not always, the case), you should select an unpredictable IV for each. $\endgroup$
    – poncho
    Jul 7 at 17:47
  • $\begingroup$ Interesting. But would that solve the extra 16 bytes issue? $\endgroup$ Jul 7 at 18:13
  • 1
    $\begingroup$ @DavidMerinos: yes, OpenSSL EVP for block modes by default uses the padding called either PKCS5 or PKCS7 depending when the naming was done. If it didn't, you would have garbage added or correct values removed at the end of the plaintext. Other parts of OpenSSL are different. $\endgroup$ Jul 8 at 2:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.