iOS AES256 decryption

Question

I need to decrypt a string encrypted with AES256.

For example: This is an encrypted string: "U2FsdGVkX18egiyzJUY5gHS++2trNSYNSEXpJicKPBE=" using this key: "70ca7c5b0f58ca290d39613fa3644251" with the AES256 algorithm

The example string has been encrypted using:

https://code.google.com/p/crypto-js/

There are multiple tools that can be used to decrypt an AES256 encrypted string: https://github.com/AlanQuatermain/aqtoolkit/tree/master/CommonCrypto

https://github.com/RNCryptor/RNCryptor

https://github.com/Gurpartap/AESCrypt-ObjC

I have tried them all but none of them was able to decrypt my string. I'm sure it's encrypted correctly because I can decrypt it using this online tool:

http://www.appcove.com/tool/aes

Please help me.

Thank you, George

-------------- EDIT --------------

Can you recommend a symmetric encryption/decryption algorithm for API(js)/iOS? Something that you used to encrypt strings on the API and decrypt them on your iOS app.

Thank you

Answer 1

To get you started:

This is an encrypted string: "U2FsdGVkX18egiyzJUY5gHS++2trNSYNSEXpJicKPBE="

This is not an encrypted string. It is the Base64 rendering of an array of encrypted bytes. In order to decrypt it you first need to convert it from Base64 back into a byte array.

using this key: "70ca7c5b0f58ca290d39613fa3644251"

This is not a key. It is the hex string representation of the byte array which either is the actual key or can be used to derive the actual key. You need to convert it from a hex string back into a byte array.

with the AES256 algorithm

You need more information here: mode and padding at least.

What mode is being used? AES-ECB, AES-CBC, AES-CTR or some other mode? Look through the description to try and find out. The lack of an IV or a Nonce would probably indicate ECB mode, as Zaph's comment says. ECB mode is insecure, do not use it for any production code.

You also need to know what padding was used. Zaph says PKCS7 padding, which is very common, but the problem source should have told you that. You need to set the decryption method to expect the correct padding.

Answer 2

I'll give you a simple flow to show how AES works:

For the sake of clarity I'll use pseudo-objective-c to make it both understandable for you and fast for me.

// Here comes encryption process:
NSString *key           = @"fsd7f897sfd8sfds…";
NSString *secretMessage = @"Confidential text";

AES *aes = [AES sharedAES];
NSString *encryptedMessage = [aes encryptWithKey:key message:secretMessage];

// Now is time for decryption:
Base64   *base64           = [Base64 sharedBase64];
NSString *messageToDecrypt = [base64 decode:encryptedMessage];
NSString *decryptedMesage  = [aes decryptWithKey:key message:messageToDecrypt];

// Now you should have the result:
NSLog(decryptedMesage);

---

Take a look at http://travistidwell.com/jsencrypt/

Answer 3

From the google docs:

For the key, when you pass a string, it's treated as a passphrase and used to derive an actual key and IV. Or you can pass a WordArray that represents the actual key. If you pass the actual key, you must also pass the actual IV.

For CryptoJS.AES.encrypt()

Is a string is passed in as the key another key will be derived and also an iv. This is going to be a compatibility problem because the method of actual key derivation would have to be know as well as the iv derivation and duplicated in iOS.

None of the above is a standard.

The solution is in JavaScript to pass in the key as a WordArray of the correct size (256 bits) and a WordArray iv.

Or per the docs:

"You can define your own formats in order to be compatible with other crypto implementations. A format is an object with two methods—stringify and parse—that converts between CipherParams objects and ciphertext strings.

Then with these the same encryption/decryption can be matched in iOS.

Here is some information I figured out, this is WRT the encrypted data prior to base64 encoding:

The first 8 bytes are "Salted__" Probably used by the Javascript decryption to know the method to use.
The next 8 bytes are random. They are different for each encryption of the same data with same key They may be derived from the key with a random component.
The next bytes are in groups of 16 bytes (blocksize), just enough to contain the data + padding. Padding always adds at least one extra byte.

Because the iv is random the encrypted bytes will be different for each encryption with the same data and key but can be recovered by somehow using the key and leading bytes to re-generate the key and iv. The method is not secret, just unknown to me.

Of course this does not particularly help but does show the problem.