Score:0

Extra bytes when decryping with OpenSSL

fr flag

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.

Score:3
my flag

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?

David Merinos avatar
fr flag
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.
David Merinos avatar
fr flag
Also, can we be sure OpenSSL uses PKCS#7 for decryption as default?
poncho avatar
my flag
@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.
David Merinos avatar
fr flag
Interesting. But would that solve the extra 16 bytes issue?
poncho avatar
my flag
@DavidMerinos: for the extra 16 bytes issue, see the answer; my comment was specifically about the idea of using an all-0's IV (works if you're encrypting only one message; not so fine if you're encrypting multiple messages with the same key)
poncho avatar
my flag
@DavidMerinos: BTW: are you sure the issue is 16 extra bytes at front, rather than the first 16 bytes decrypted as gibberish (and the rest are fine) - the latter indicates that you got the IV wrong (and everything else was correct)
David Merinos avatar
fr flag
Well, I do know the decryped message is: "ESTA ES UNA PRUEBA DE CIFRADO AES PARA ETHERNET XXXXXXXX" I'm not getting any IV from the encrypting side; what I'm doing is setting IV as an array of 16 zeros. I will try extracting those first 16 bytes. Does that mean that I need to trim it before attempt decrypting?
dave_thompson_085 avatar
cn flag
@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.
David Merinos avatar
fr flag
Today I ran a test where I encrypt the same message using IV of zeros, then decrypt it with the same IV and I get no extra bytes so we can conclude the problem is that.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.