I have a WCF service, currently expecting byte[] as input parameter, but I want to send NSData from iOS. These types seem incompatible.
I've read a lot about this and most suggest that I convert the NSData to a base64 string.
Will this work for obscured data? I.e. my NSData consists of NSData that was passed through an AES256 Encryption algorithm. I don't think this data can be converted back to string successfully.
Thank you Tom
I think sending the raw bytes would most probably have worked, but in the end I opted to convert the NSData to a base64 NSString and send that instead.
Works great!
PS> Could someone please give me some rep? I'd like to participate more, but no one is voting on anything I post.
Here is my profile with my 2 or 3 other questions: https://stackoverflow.com/users/1014983/matthys-du-toit
Related
I've been going around in circles from Apple's CCCrypto docs, frameworks and other SO answers and am not making any headway.
I think I need to figure out how to get a IV from an encrypted string that I receive.
I receive a JSON payload which contains a String. That string is encrypted in AES-256-CBC. (From a Laravel PHP instance that I think uses OpenSSL). The string itself, decrypted, is another JSON object.
I have a pre-defined key.
The string I receive looks something like:
eJahdkawWKajashwlkwAkajsne8ehAhdhsiwkdkdhwNIEhHEheLlwhwlLLLLhshnNWhwhabwiIWHWHwh=
(but is a lot longer).
I'm trying to use this answer here: Issue using CCCrypt (CommonCrypt) in Swift
But am a) unsure if I'm properly converting the string to data and b) how to get the IV (initialization vector) from the string I receive.
Using that answer I do get "success" however when I try to pass it to the NSJSONSerailizer I never got a good result (it always fails) but I do get data out - I think it's garbage.
Edit:
I really mis-understood my original problem - I was receiving a base64 encoded string that I needed to decode into JSON (which went fine). Then using the linked answer and importing CommonCrypto I thought I'd be able to get usable data but I am not. #Rob Napier 's answer is extremely helpful. I think my problem is that the instance of laravel in question is using OpenSSL.
There is no really commonly used standard format for AES encrypted data (there are several "standard formats" but they're not commonly used....) The only way to know how the data you have is encrypted is to look at the documentation for the data format, or failing that, the encrypting code itself.
In good encryption formats, the IV is sent along with the data. But in many common (insecure) formats, there is a hard-coded IV (sometimes 16 bytes of 0x00). If there's a password, you also need to find out how they've converted the password to a key (there are several ways to do this, some good, some horrible). In a good format, the key derivation may include some random "salt" that you need to extract from the data. You'll also need to know if there is an HMAC or similar authentication (which might be stored at the beginning or the end of the data, and may include its own salt).
There just isn't any good way to know without documentation from the sender. Any decently encrypted format is going to look like random noise, so figuring it out just by looking at the final message is pretty hard.
If this comes out of Laravel's encrypt function, then that seems to be ultimately this code:
public function encrypt($value)
{
$iv = mcrypt_create_iv($this->getIvSize(), $this->getRandomizer());
$value = base64_encode($this->padAndMcrypt($value, $iv));
// Once we have the encrypted value we will go ahead base64_encode the input
// vector and create the MAC for the encrypted value so we can verify its
// authenticity. Then, we'll JSON encode the data in a "payload" array.
$mac = $this->hash($iv = base64_encode($iv), $value);
return base64_encode(json_encode(compact('iv', 'value', 'mac')));
}
If this is correct, then you should have been passed base64-encoded JSON with three fields: the IV (iv), the ciphertext (value), and what looks like an HMAC encrypted using the same key as the plaintext (mac). The data you've given above doesn't look like JSON at all (even after base-64 decoding).
This assumes that the caller used this encrypt function, though. There are many, many ways to encrypt, though, so you need to know how the actual server you're talking to did it.
Ok. I have experienced this problem for quite sometime. Feeling like I am getting close, just need to be pointed in the right direction. So I am using this cool third party library called FBEncryptorAE:
NSString * encryptedMessage = [FBEncryptorAES encryptBase64String:localQuery keyString:key separateLines:NO];
When I post this encrypted query up to my server, I get the following error:
The AES/CBC/PKCS7Padding algorithm is not supported by the Security Provider you have chosen
Here's what my constraints are:
128 bit key
AES/CBC/PKCS5Padding, Base64
coldfusion
Based off of my readings, PKCS5Padding/ PKCS7Padding are the same thing?? If someone could be kind and help me understand:
Why I am getting the error.
Is there sample code I can view based off of my constraints I have? Appreciate any help.
PKCS5Padding and PKCS7Padding produce the same result for AES, are essentially the same.
If you are using CBC an iv is required. How is the iv made the same for both encryption on iOS and decryption on the server? FBEncryptorAES has iv capability but only for (raw data) not (base64) so it is defaulting to "nil" (from the docs). You must get this correct. Since FBEncryptorAES does not support what you need you need to use the (raw data) API and then Base64 encode with the NSData method base64EncodedDataWithOptions:.
Ensure that the key and iv are exactly the required size, for AES128 that is 16 bytes for each. Some wrappers expand undersize keys but there is no standard for that, Common Crypto does not.
Hex dump the input and outputs of all all parameters and data on both sides to ensure they match.
The problem with wrappers is that they are rather opaque as to what is actually being done and that can create interoperability problems. For this reason I always use Common Crypto and the NSData base64 encoding/decoding so I know exactly what is being done.
I'm looking for a datausingencoding parameter that doesn't swallow up plus signs. I was using NSASCIIENCODING but since I'm trying to send a uiimage to the server and the base64 string had plus signs in them, it seems like that form of encoding takes out the plus sign sending a modified encoded string to the server thereby not allowing the image to be decoded server side. I'm looking for something that won't alter the base64 string.
Nevermind guys, here is the solution I found on stackoverflow
thanks, now I figured it out. It seems I needed to run my string through the stringByAddingPercentEscapesUsingEncoding: first, then I needed to run it through replaceOccurrencesOfString:#"+" withString:#"%2B" and several more of those replaces for different characters, because stringByAddingPercentEscapesUsingEncoding: doesn't escape them all
I need to encode my image into text.
And I found this class for that:
Base64 for iOS with ARC
When I try to encode my image I see that NSPropertyListSerialization creates absolutely the same string as base64 does. Is it the right way to create base64 String with NSPropertyListSerialization or am I missing something?
Base64:
[data base64EncodedString];
NSPropertyListSerialization:
[NSString stringWithUTF8String:[[NSPropertyListSerialization dataWithPropertyList:data format:NSPropertyListXMLFormat_v1_0 options:0 error:nil] bytes]]
No you're not missing anything. Base64 is simply a standard from encoding binary data in ASCII and pLists use Base64 encoding for encoding binary data like images (using NSPropertyListSerialization) so they should create identical Base64 strings for the same binary data.
If you're wondering about which to use in your application I'd recommend you use the base64 library. While Apple has pushed to make pLists a standard and pLists will probably always encode binary data as Base64 in future, in the extremely unlikely event they change something or drop support for pLists your code will break. Besides it's best to be clear in your code (for yourself and others) that you're encode your data to base 64.
I've been asked to develop the company's backoffice for the iPad and, while developing the login screen, I've ran into an issue with the authentication process.
The passwords are concatenated with a salt, hashed using SHA-256 and stored in the database.
The backoffice is Flash-based and uses the as3crypto library to hash then password+salt and my problem is that the current implementation uses Base64 for both input and output.
This site demonstrates how this can be done: just select Hash and select Base64 for both input and output format and fire away. So far, all my attempts have yielded different results from the ones this site (and the backoffice code) give me.
While I think that in theory it should be relatively simply:
Base64 encode the pass+salt
Hash it using SHA-256
Base64 encode the result again
so far I haven't been able to do this and I'm getting quite the headache to be honest.
My code is becoming a living maze, i'll have to redo-it tomorrow I reckon.
Any ideas?
Cheers and thanks in advance
PS: Here's the Backoffice's Flash code for generating hashed passwords by the way:
var currentResult:ByteArray;
var hash:IHash = Crypto.getHash('sha256');
var data:ByteArray = Base64.decodeToByteArray(str + vatel);
currentResult = hash.hash(data);
return Base64.encodeByteArray(currentResult).toString();
The backoffice code does not do
Base64 encode the pass+salt
Hash it using SHA-256
Base64 encode the result again
(as you wrote above)
Instead, what it does is
Base64 decode the pass+salt string into a byte array
Hash the byte array using SHA-256
Base64 encode the byte array, returning a string
As per step 1 above, it's a unclear what kind of character encoding the input strings uses. You need to make sure that both systems use the same encoding for the input strings! UTF8, UTF16-LE or UTF16-BE makes a world of a difference in this case!
Start by finding out the correct character encoding to use on the iOS side.
Oh, and Matt Gallagher has written an easy to use wrapper class for hashes to use on iOS, HashValue.m, I've used it with good results.