Encrypted NSData to NSString in obj-c?

Question

I have an iPhone app which encrypts an inputted NSString using CCCrypt (AES256) and a plaintext key. The string and key are given to the encryption method which returns an NSData object.

Requesting [data description] where 'data' is the encrypted string data gives an NSString like: "<0b368353 a707e7de 3eee5992 ee69827e e3603dc2 b0dbbc0b 861ca87d f39ce72a>" but when I try to convert that to an NSString, I get "(null)".

I need to return an NSString to the user, which can be used to decrypt back to the original string using the same plaintext key. If the 'description' property of the NSData object can return a string, is there any way I can produce an NSString from the NSData object without getting "(null)"?

UPDATE: Thanks to Quinn, who suggests using Base64 encoding to produce the muddled string. From what I understand, Base64 encoding does not simply swap characters, but the character exchange depends on the position, so that's fine.

My only concern is that I want to be able to encrypt the message with a 'passphrase', and require the identical passphrase to be entered when the muddled string needs to be decoded - can anybody suggest ways to implement this?

Solution 1

First off, DO NOT use -[NSData description] to create an NSString for such purposes. (It's best to treat -description as debugging output. I apologize if my previous answer misled you, I was merely printing the description to demonstrate that the NSData can be encrypted and decrypted.) Instead, use NSString's -dataUsingEncoding: and -initWithData:encoding: methods to convert between NSData and NSString. Even with these, note that AES-encrypted data will probably not translate well into strings as-is — some byte sequences just won't play nicely, so it's a good idea to encode the data before creating the string.

I'd suggest you try Base64 encoding the NSData, since Base64 data can always be represented as an ASCII string. (Of course, when you do that, you'll have to decode from Base64 before decrypting.)

Here are some helpful resources...

• Colloquy has some code that does encoding/decoding on NSData (header and implementation)
• Google Toolbox for Mac has similar functionality (header and implementation)
• A Cocoa With Love blog post on the topic.
• A CocoaDev.com wiki page on the topic.

---

Edit: I was assuming you'd combine this with my answer to your previous question on AES encryption of NSString objects. Encoding data as Base64 doesn't place any restrictions on the data itself — it can certainly be AES-enrypted data itself. Here's what to do if you just want string input and output:

• Encryption
  • Provide the NSString to be encrypted, and the passphrase to use for encrypting.
  • Convert the string to an NSData and perform AES encryption on it (see previous question).
  • Base64-encode the NSData, then create and return and NSString of the encoded output.
• Decryption
  • Provide the encrypted and encoded string, and the passphrase to use for decrypting.
  • Create an NSData from the first string, then Base64-decode the data.
  • Perform AES decryption on the data, then create and return an NSString.

It's really just a matter of chaining the two parts together and performing them in reverse on the way out. From my previous answer, you can modify encryptString:withKey: to perform the last step and return a string, and change decryptData:withKey: to be decryptString:withKey: and accept two strings. It's pretty straightforward.

Solution 2

I have put together a complete bundle of categories for NSData and NSString to provide AES256 encryption for strings.

Please see my answer on the 'original' question for more details.

Comments

[Quinn Taylor]

I've updated my answer to address this below. You're correct, Base64 is not a substitution algorithm — it basically expands 3 bytes to 4 bytes, so encoded data is 1.37x as large as its non-encoded counterpart. Basically, it takes 3 8-bit chunks and redivides it into 4 6-bit chunks, then reinterprets each of those as 8-bit chunks, which can easily be represented in ASCII. Wikipedia has more detail.

[Quinn Taylor]

@FreeAsInBeer Please don't mark other people's answers as Community Wiki when you edit them. That's not what it's for.

[FreeAsInBeer]

@QuinnTaylor The FAQ states that you are the only one who specifically has access to the Community Wiki checkbox. My edit may have inadvertently caused it to enter Community Wiki mode, but that was completely unintentional. Please don't accuse other people of doing things they cannot do. Reference

[Quinn Taylor]

@FreeAsInBeer My apologies, it wasn't your fault after all. I was unaware that an answer automatically converts to CW if: "The post has been edited ten (10) times by the original owner." I just happened to see that it was CW when I viewed your edit, but it was after my previous edit that it happened. Sorry for jumping to conclusions. :-P

[FreeAsInBeer]

@QuinnTaylor It's all good. These things happen. Afterall, (even if we think we're all-powerful computer wizards) we're only human.

[Duncan Babbage]

The documentation for NSData .description merely states A string that contains a hexadecimal representation of the object’s contents in a property list format. There is no suggestion this should only be used for debugging purposes. If it works for a known data format, is there an actual reason to not use it? [Edit: Ah, perhaps I need to read this answer specifically in the context of the original question re encrypted data.]