Decryption with AES and CryptoAPI? When you know the KEY/SALT

Question

Okay so i have a packed a proprietary binary format. That is basically a loose packing of several different raster datasets. Anyways in the past just reading this and unpacking was an easy task. But now in the next version the raster xml data is now to be encrypted using AES-256(Not my choice nor do we have a choice).

Now we basically were sent the AES Key along with the SALT they are using so we can modify our unpackager.

NOTE THESE ARE NOT THE KEYS JUST AN EXAMPLE:

They are each 63 byte long ASCII characters:

Key: "QS;x||COdn'YQ@vs-`X\/xf}6T7Fe)[qnr^U*HkLv(yF~n~E23DwA5^#-YK|]v."
Salt: "|$-3C]IWo%g6,!K~FvL0Fy`1s&N<|1fg24Eg#{)lO=o;xXY6o%ux42AvB][j#/&"

We basically want to use the C++ CryptoAPI to decrypt this(I also am the only programmer here this week, and this is going live tomorrow. Not our fault). I've looked around for a simple tutorial of implementing this. Unfortunately i cannot even find a tutorial where they have both the salt and key separately. Basically all i have really right now is a small function that takes in an array of BYTE. Along with its length. How can i do this?

I've spent most of the morning trying to make heads/tails of the cryptoAPI. But its not going well period :(

EDIT

So i asked for how they encrypt it. They use C#, and use RijndaelManaged, which from my knowledge is not equivalent to AES.

EDIT2

Okay finally got exactly what was going on, and they sent us the wrong keys.

They are doing the following:

Padding = PKCS7 CipherMode = CBC The Key is defined as a set of 32 Bytes in hex. The IV is defined as a set of 32 bytes in hex too.

They took away the salt when i asked them.

How hard is it to set these things in CryptoAPI using the wincrypt.h header file.?

Answer 1

AES-256 uses 256 bit keys. Ideally, each key in your system should be equally likely. A 63 byte string would be 504 bits. You first need to figure out how the string of 63 characters needs to be converted to 256 bits (The sample ones you gave are not base64 encoded). Next, "salt" isn't an intrinsic part of AES. You might be referring to either an initialization vector (IV) in Cipher-Block-Chaining mode or you could be referring to somehow updating the key.

If I were to guess, I'm assuming that by "SALT" you mean IV and specifically CBC mode.

You will need to know all of this when using CAPI functions (e.g. decrypt).

If all of this sounds confusing, then it might be best to change your design so that you don't have to worry about getting all of this right. Crypto is hard. One bad step could invalidate all the security. Consider looking at this comment on my Stick Figure Guide to AES.

UPDATE: You can look at this for a rough starting point for C++ CAPI. You'll need a 64 character hex string to get 256 bits ( 256 bits / (4 bits / char) == 64 chars). You can convert the chars to bits yourself.

Again, I must caution that playing fast and loose with IV's and keys can have disastrous consequences. I've studied AES/Rijndael in depth down to the math and gate level and have even written my own implementation. However, in my production code, I stick to using a well-tested TLS implementation if at all possible for data in transit. Even for data at rest, it'd be better to use a higher level library.

Answer 2

Rijndael is the algorithm name for AES