Archived Forum Post

Index of archived forum posts

Question:

Trouble decrypting files with aes-128-cbc

Oct 30 '12 at 08:42

Perhaps a rookie question but I’m doing something I thought would be reasonably straight forward. We have TAR files encrypted using openssl on Linux that I’m fishing over to Windows and using openssl I can decrypt them fine using this command line construction:

openssl.exe aes-128-cbc -d -k a5475Wti51q5WItv9Fu0 -in encrypted.tar -out decrypted.tar

I’d like to do this in my app with Crypt2 but the resulting files are not valid TARs – I tried the simple example first:

Chilkat.Crypt2 crypt = new Chilkat.Crypt2();
crypt.UnlockComponent("blah");

crypt.CryptAlgorithm = "aes";
crypt.CipherMode = "cbc";
crypt.KeyLength = 128;

crypt.SetEncodedKey(pPassword, "ascii");
crypt.SetEncodedIV(pPassword, "ascii");

success = crypt.CkDecryptFile(pInputFile, pOutputFile);
if (success != true)
   {
    MessageBox.Show(crypt.LastErrorText);
    return;
   }

And I tried the “Java result equivalent” example as well:

Chilkat.Crypt2 crypt = new Chilkat.Crypt2();
crypt.UnlockComponent("blah");
crypt.HashAlgorithm = "md5";
crypt.EncodingMode = "hex";
string secretKeyHex = crypt.HashStringENC(pPassword);

crypt.CryptAlgorithm = "aes";
crypt.CipherMode = "cbc";
crypt.KeyLength = 128;

crypt.SetEncodedKey(secretKeyHex, "hex");
crypt.SetEncodedIV(secretKeyHex, "hex");
success = crypt.CkDecryptFile(pInputFile, pOutputFile);
if (success != true)
   {
    MessageBox.Show(crypt.LastErrorText);
    return;
   }

Neither produces a valid TAR file I can open. So am I missing something really silly here or is openSSL doing something different that I’m not aware of?

Thanks much.

-J

---

Answer

See this Chilkat blog post for more help: http://www.cknotes.com/?p=290

For one thing, this string "a5475Wti51q5WItv9Fu0" is not hex, because a hex string would only contain the characters 0-9A-F.

---

Answer

yeah, I had stubmbled on that over the weekend - I had already tried using "crypt.SetEncodedKey(pPassword, "base64");" and such - changed the encoding mode around but no combination results in a tar file that is recognized as such.

---

Answer

The next step is to look more closely at "a5475Wti51q5WItv9Fu0".

If you decode this base-64 string to bytes, you'll find that it decodes to 15 bytes.

For example, I wrote a simple program to re-encode from Base64 to Hex using this C++ code:

void base64DecodeStringToHex(void)
    {
    CkCrypt2 crypt;

const char *sHex = crypt.reEncode("a5475Wti51q5WItv9Fu0","base64","hex");
printf("%s\n",sHex);
printf("num bytes = %d\n",strlen(sHex)/2);
}

The output is this:

6B9E3BE56B62E75AB9588B6FF45BB4
num bytes = 15

128-bit AES requires 16-bytes of key material, not 15. Therefore, maybe OpenSSL is implicitly providing a leading "00" byte for you. Maybe the key is really hex "006B9E3BE56B62E75AB9588B6FF45BB4".

My suggestion w/ encryption is that it's best to be precise and explicit. Don't leave things like this up to some implicit behavior of a particular system (such as OpenSSL).

---

Answer

hmmm... good suggestion and it makes sense but still doesn't result in a usable TAR file for me.

Appreciate you taking the time to help run it down, though - I'll have to roll with a CLI call to openssl at this point - need to move on.

thanks much

-J

---

Answer

One last bit of info..

From the OpenSSL docs:

-k password

the password to derive the key from. 
This is for compatibility with previous versions of OpenSSL. 
Superseded by the -pass argument.

The actual 128-bit (16 byte) secret key is derived from the password string. In other words, you have to know what algorithm, likely just a hash, is used to transform an arbitrary string (the password) to the actual binary secret key.