Sunday, February 15, 2009

Strong Encryption for Cocoa / Cocoa Touch

Please do not use this code! Instead, check out Jim Dovey's Common Crypto code from AQToolkit.

AES is a strong encryption standard that has mostly replaced the aging DES standard. AES is widely used and fairly secure encryption mechanism (but I am not an expert at cryptography by any stretch of the imagination; I'm trusting experts for that opinion). AES supports three different key sizes, 128, 192, and 256 (the larger the key, the more secure the encryption and the more processing power it takes to encrypt or decrypt). Apple uses AES-128 and AES-256 in several places in Mac OS X, including for Disk Image encryption.

There are several public-domain implementations of AES. I chose a public domain implementation of AES by Philip J. Erdelsky to use as the basis some Objective-C categories that make encrypting and decrypting files and data using AES-256 easy.

The first category is on NSFileManager, and allows you to encrypt a file in the filesystem. It takes a file at a particular pathname, encrypts it using a passphrase, and then writes the encrypted contents to a new specified file location. This version has relatively low memory overhead, as it streams the data in chunks both for reading and writing, so only the chunk currently being encrypted is in memory. The category adds two methods to NSFileManager, one for encrypting, the other for decrypting. These methods are the best choice when your source data already exists in the file system, especially on the iPhone, because of how little memory it uses to do the work. Here is an example of using the category on NSFileManager to encrypt a file:
    NSError *error = nil;
if (![[NSFileManager defaultManager] AESEncryptFile:@"/path/to/input file" toFile:@"/path/to/output file" usingPassphrase:@"My secret password" error:&error])
{   
        NSLog(@"Failed to write encrypted file. Error = %@", [[error userInfo] objectForKey:AESEncryptionErrorDescriptionKey]);
}

There is also a category on NSData that will let you encrypt a chunk of data that's already in memory. This version creates a new NSData object with the encrypted contents of the original NSData instance. If your data is already in memory, and you want an encrypted or decrypted version of it, then the NSData methods are the way to go. Here is an example of using encrypting an NSData object with AES:
    NSData *encryptedData = [data AESEncryptWithPassphrase:@"My secret password"];

Pretty easy, huh? Okay, now, this is a symmetric block cypher, it is not public-key encryption, so if you store your passphrase as a string in your application (as opposed to making the user enter it or storing it in the keychain) then you're giving somebody the ability to decrypt your encrypted application data, so just be forewarned.

Also, I make no warranties about how secure this is. As far as I know, AES-256 has not been broken yet, however I cannot say for certaint that there are no weaknesses in the AES implementation I've used. I don't see any obvious problems but I am not a cryptographer. I haven't heard of any weaknesses in this particular implementation, but any use of this is completely at your own risk.

Here is a zip file containing the two categories and the AES implementation. Just add these to your Xcode project, include the appropriate headers, and encrypt away.

Oh, and, one more important thing: If you use this in an iPhone application that you plan to sell on the App Store, it may lengthen the review process, as you will have to declare that you are using encryption, and will likely have to create and upload a CCATS form and wait for Apple to review it before your app will go up for sale. Read the iTunes Connect Developer Guide for more information on CCATS and the process before deciding to use this in an iPhone application for sale, please.

UPDATE: Jim Dovey author of the terrific Output iPhone App, posted a category on NSMutableData in the comments to this post that uses the crypto libraries already available on the Mac and iPhone to do AES-256 encryption. According to Jim, this means you don't need a CCATS form because Apple's exporting the encryption code, not you, so check it out Thanks, Jim.



74 comments:

alanQuatermain said...

Here's an NSData category which uses built-in encryption methods, meaning you can sidestep CCATS (you're not exporting the encryption tech, Apple is).

#import <CommonCrypto/CommonCryptor.h>

@implementation NSMutableData (AES256)

- (BOOL) encryptWithKey: (NSString *) key
{
// 'key' should be 32 bytes for AES256, will be null-padded otherwise
char * keyPtr[kCCKeySizeAES256+1]; // room for terminator (unused)
bzero( keyPtr, sizeof(keyPtr) ); // fill with zeroes (for padding)

// fetch key data
[key getCString: keyPtr maxLength: sizeof(keyPtr) encoding: NSUTF8StringEncoding];

// encrypts in-place, since this is a mutable data object
size_t numBytesEncrypted = 0;
CCCryptorStatus result = CCCrypt( kCCEncrypt, , kCCAlgorithmAES128, kCCOptionPKCS7Padding,
keyPtr, kCCKeySizeAES256,
NULL /* initialization vector (optional) */,
[self mutableBytes], [self length], /* input */
[self mutableBytes], [self length], /* output */
&numBytesEncrypted );
return ( result == kCCSuccess );
}

- (BOOL) decryptWithKey: (NSString *) key
{
// 'key' should be 32 bytes for AES256, will be null-padded otherwise
char * keyPtr[kCCKeySizeAES256+1]; // room for terminator (unused)
bzero( keyPtr, sizeof(keyPtr) ); // fill with zeroes (for padding)

// fetch key data
[key getCString: keyPtr maxLength: sizeof(keyPtr) encoding: NSUTF8StringEncoding];

// encrypts in-place, since this is a mutable data object
size_t numBytesEncrypted = 0;
CCCryptorStatus result = CCCrypt( kCCDecrypt, , kCCAlgorithmAES128, kCCOptionPKCS7Padding,
keyPtr, kCCKeySizeAES256,
NULL /* initialization vector (optional) */,
[self mutableBytes], [self length], /* input */
[self mutableBytes], [self length], /* output */
&numBytesEncrypted );

return ( result == kCCSuccess );
}

@end

Jeff LaMarche said...

Sweet! Thanks!

brianhammond.com said...

The problem with this method for the iPhone is that you are embedding the password used to encrypt/decrypt the data right in the source code as a string literal. This ends up in the final binary, easily found by anyone who has access to the binary (e.g. jailbreakers) and knows how to run something like 'strings' or a hex editor. It's next to impossible to keep secret data secret on the iPhone.

I have an open bug report with Apple that suggests they provide some mechanism to let developers ship secure items with the app and have them entered into the app's keychain at installation time.

fbronner said...

It depends if your key is a word or a bunch or letters/characters which have no meaning. I have used this where it actually looked like some assembly code, was about 64 bytes long and I was picking up only every fifth byte out of the assembly code in a round robin fashion until I got to 32 bytes.

Unless you were actually dis-assembling and tracing the actual execution code you wouldn't have found it casually...

And if you had gone thru the effort of understanding and then tracing my code, well good for you, you had the key.

alanQuatermain said...

@brianhammond.com:

This is just an example; it uses a static string for illustrative purposes. There's nothing to stop the key being something entered by the user or even randomly-generated, then stored in the Keychain or similar.

brianhammond.com said...

@fbronner - that's pretty good obfuscation.

@alan - yep, indeed. just pointing it out.

Jeff LaMarche said...

Brian - you've hit on the fatal flaw of most DRM - if you want somebody to be able to use the encrypted content, you've got to give them the key to decrypt it, or its useless. You can make it harder, but you can't prevent people tech savvy end-users to whom you've given the key from taking the decrypted content and using it.

Even if Apple provided a mechanism for us, it wouldn't stop jailbreakers from getting the content. It might slow them down, make it harder for them, but it won't stop them.

But, there are many valid uses for encryption - to encrypt data being exchanged between two machines, for allowing a user to protect their created data, etc.

brianhammond.com said...

@jeff - of course those are good uses for encryption. I'm not debating that. I'm looking for a way to keep a secret "client key" secret on the iPhone, away from jailbreakers and potential impostors. Think the secret client key needed to access Amazon Web Services. I think the best I'm going to be able to do is obfuscation.

Moritz said...

Hi,
By now I have found numerous extensions and categories to encrypt using the CommonCrypto libraries and the Security Framework's routines. One thing that I still have trouble with is the key generation. Would someone be so kind and point me in the right direction as to how I properly generate a 256 Bit AES-128 symmetric key for the iPhone?
Thanks any help is greatly appreciated
Moritz

pbrooks said...

Hi, great example at the top of the comments but I can't get it to work:

1) there is an extra comma after kCCEncrypt in both methods

2) the length of the encrypted output is greater than the input, so the method fails with kCCBufferTooSmall ('Insufficent buffer provided for specified operation.')


I'm quite new to iPhone development (but working through Beginning iPhone Development, Jeff :-) While I can solve 1), what about 2)? With the one shot CCCrypt is there a way to make the size of mutableBytes larger on the fly??

Thanks for any help,
Peter

Henri said...

Hi

I stumbled across this post while I was searching for a way to protect the data stored within my iPhone app via encryption.

I find especially the Category proposed by Jim Dovey in the first comment very promising, but I can't get it working. For testing purpose, I wrote an application for the Mac which should encrypt some dummy data to a file and later decrypt it again. So far the application compiles nicely but the data won't get encrypted --- the method 'encryptWithKey' always returns 'NO'.

So, I wonder if somebody out there got this working, and can point me to the right direction?

any help is appreciated

greetings

Henri

Jean said...
This comment has been removed by the author.
Jean said...

I’ve fixed/improved the code so that the buffer size is correctly set (otherwise you'll probably get the kCCBufferTooSmall status).
Also, this version has a different interface and is now a category of NSData.

See the improved code here: http://pastie.org/426530

Hope it will be useful to someone else.

Thanks for the initial code.

Jeremy said...

I am new to Objective C - how do I catually use the new NSMutableData implementation?

Does this create a new method that NSMutableData should respond to?

schleidl said...

Jean, thanks a lot for the new code. With it I got the right results :-)

Cipher said...

I'm new in Objective-C, so please forgive me for this silly question, where is the data or the information that is suppose to get encrypted and decrypted? and does the code snippet accomplish that?

Leo said...

Regarding the CCATS forms and all, would using MD5 to generate hash qualify for that as well?

ashy said...

Sorry i am beginner and learning to encrypt file using AES. I came across this web regarding AES, i was trying to encrypt files and i added #import "NSFileManager-AES.h" in my .m code but it always show me Error = File Open Error and i had change the file path /button.app/testing.txt... any help and guidance will be much appreciated....

ScottYelich said...

Ok, so about Apple's fetish with restricting apps -- even though the government doesn't seem to prosecute anyone after losing to Bernstein ... what do you answer when the app store asks if your app uses encryption? Yes, it does. If you say yes, then you have to provide CCATS/other documentation. If you say no, then you are lying. Has anyone actually *used* this code in an app and submitted it to Apple *and* had it approved? Maybe Apple needs to add another screen that says "are you just using the built-in CommonCrypto" ... Anyway, granted, with the arbitrariness of the app approval process, I know this doesn't mean that a second submission wouldn't summarily be rejected.

Slava said...
This comment has been removed by the author.
Scott Newman said...

Jeff,

Using your code, I'm not able to see the encrypted strings. Am I doing something obviously wrong?


NSString *passphrase = @"super-secret";
NSStringEncoding myEncoding = NSASCIIStringEncoding;

NSString *alphaStringPlain = @"This is a test.";
NSData *alphaDataPlain = [alphaStringPlain dataUsingEncoding:myEncoding];

NSData *alphaDataCypher = [alphaDataPlain AESEncryptWithPassphrase:passphrase];
NSString *alphaStringCypher = [[NSString alloc] initWithData:alphaDataCypher encoding:myEncoding];

NSLog(alphaStringCypher);

Saad said...
This comment has been removed by the author.
Saad said...
This comment has been removed by the author.
anonymouse said...

Alan's code has a couple of bugs which stop it compiling - keyPtr (which I also think is better named keyBuffer) should be declared as a char array not a char* array and thereis an extra "," in the call to CCCrypt:

- (BOOL) encryptWithKey: (NSString *) key
{
// 'key' should be 32 bytes for AES256, will be null-padded otherwise
char keyBuffer[kCCKeySizeAES256+1]; // room for terminator (unused)
bzero( keyBuffer, sizeof(keyBuffer) ); // fill with zeroes (for padding)

[key getCString: keyBuffer maxLength: sizeof(keyBuffer) encoding: NSUTF8StringEncoding];

// encrypts in-place, since this is a mutable data object
size_t numBytesEncrypted = 0;
CCCryptorStatus result = CCCrypt(kCCEncrypt, kCCAlgorithmAES128, kCCOptionPKCS7Padding,
keyBuffer, kCCKeySizeAES256, nil,
[self mutableBytes], [self length],
[self mutableBytes], [self length],
&numBytesEncrypted);


return ( result == kCCSuccess );
}

- (BOOL) decryptWithKey: (NSString *) key
{
// 'key' should be 32 bytes for AES256, will be null-padded otherwise
char keyBuffer[kCCKeySizeAES256+1]; // room for terminator (unused)
bzero( keyBuffer, sizeof(keyBuffer) ); // fill with zeroes (for padding)

// fetch key data
[key getCString: keyBuffer maxLength: sizeof(keyBuffer) encoding: NSUTF8StringEncoding];

// encrypts in-place, since this is a mutable data object
size_t numBytesEncrypted = 0;
CCCryptorStatus result = CCCrypt( kCCDecrypt, kCCAlgorithmAES128, kCCOptionPKCS7Padding,
keyBuffer, kCCKeySizeAES256, nil,
[self mutableBytes], [self length],
[self mutableBytes], [self length],
&numBytesEncrypted);

return ( result == kCCSuccess );
}

@end

Harris said...

Does anybody have any pointers for passing this encrypted data to a server with Java code and successfully decrypting it (and vice versa)?

I'm using javax.crypto.Cipher on the Java side, but not sure what settings will make the encryption match the above.

Thanks in advance.

Michael Waterfall said...

I've just tried to use anonymouse's version which compiles without any errors, but I'm getting a return of kCCBufferTooSmall, meaning "Insufficent buffer provided for specified operation.".

How can this be resolved? The key I'm using is just @"cryptkey".

Thanks!

Michael Waterfall said...

Whoops, should have read the following comments! No worries I got it all working ;-)

anonymouse said...

Yeah, sorry about that. I posted as soon as I got it to compile not after I'd debugged it. :-|

#import "NSData-AEC.h"


@implementation NSData (AES256)

- (NSData*) encryptedWithKey: (NSString *) key;
{
// 'key' should be 32 bytes for AES256, will be null-padded otherwise
char keyBuffer[kCCKeySizeAES128+1]; // room for terminator (unused)
bzero( keyBuffer, sizeof(keyBuffer) ); // fill with zeroes (for padding)

[key getCString: keyBuffer maxLength: sizeof(keyBuffer) encoding: NSUTF8StringEncoding];

// encrypts in-place, since this is a mutable data object
size_t numBytesEncrypted = 0;

size_t returnLength = ([self length] + kCCKeySizeAES256) & ~(kCCKeySizeAES256 - 1);

// NSMutableData* returnBuffer = [NSMutableData dataWithLength:returnLength];
char* returnBuffer = malloc(returnLength * sizeof(uint8_t) );

CCCryptorStatus result = CCCrypt(kCCEncrypt, kCCAlgorithmAES128 , kCCOptionPKCS7Padding | kCCOptionECBMode,
keyBuffer, kCCKeySizeAES128, nil,
[self bytes], [self length],
returnBuffer, returnLength,
&numBytesEncrypted);

if(result == kCCSuccess)
return [NSData dataWithBytes:returnBuffer length:numBytesEncrypted];
else
return nil;

}

@end

michaelwaterfall.com said...

Thanks for the revised code anonymouse! Is the decrypt method fine as it is then, as you only posted a different encrypt method? Thanks again!

anonymouse said...

No, I only need to encrypt our API key so I toasted the decrypt method from my source without fixing it :-(

The changes are not to include the terminator byte in the key buffer size you give to CCCrypt. Note that I also turned on kCCOptionECBMode. If you are encrypting something more important, you may wish to turn this off: http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Electronic_codebook_.28ECB.29

michaelwaterfall.com said...

Cheers for you quick replies! Apologies as I'm not really clued up on this level of C programming but would there be any chance for you to post the complete working NSData category? You're a star :-)

andreburri said...

@anonymouse

Is it possible for you to post the complete implementation (encrypt and decrypt)?. Thanks!

info said...

I never implemented decrypt, I just needed a password hash.

Sorry.

andreburri said...
This comment has been removed by the author.
andreburri said...

ok, thank you for the quick answer. I will do the decrypt myself, based on Alan's code.
Do you have a short sample on how you use the encryptWithKey? Thanks.

sol0 said...

Can anyone explain why encrypting a 16 byte plaintext buffer using the AES examples in this thread returns 32 bytes of data? This makes the encryoted files twice as large as the original ...

Thanks,

anonymouse said...

blocking - AES encrypts in blocks so you always get a multiple of the blocksize. Try the Wikipedia article - it's surprisingly readable.

sol0 said...

I understand the padding issue - that applies to the last block only. The result is that the ciphertext is always a multiple of 16 bytes, and may be slightly larger than the plaintext.

But when I use your encryptWithKey code, if I feed it a 1 byte plaintext I get 32 bytes (numBytesEncoded) of cipertext!

And as I call the above routine in a loop to encrypt an entire file - i.e. read 16 bytes of plaintext, write 32 bytes of ciphertext - the end result is an encrypted file twice the size as the plaintext.

And what's more, I can read the ciphertext back in and using an analogous decrypt routine produce a new plaintext file identical the the original!

sol0 said...

.. unless I am mis-using the routine: perhaps I should be feeding it the entire file, and not 16-byte chuncks! :)

anonymouse said...

you are right. The NSData should include all your plaintext.

sol0 said...

"you are right. The NSData should include all your plaintext"

Indeed! And in fact, as I've just verified, one doesn't have to fiddle with padding in or out, it's done automatically by cccrypt if kCCOptionPKCS7Padding is specified. So I just removed lots of code and replaced it with a tiny bit of code :)

1) on encode I no longer have to pad the last block to a 16-byte boundary

2) on decode I do not have to read the last byte to get the pad count, nor seek prior to those pad chars and truncate the plaintext output file

So simple. Now I can pick an appropriately large buffer size, say X, for chunking through plaintext input, and a corresponding buffer size X+16 for chunking through ciphertext.

Many thanks,

Devarshi said...
This comment has been removed by the author.
Devarshi said...

Hi Jeff,

I was just doing google search for "AES algorithm cocoa" when I got your blog. I found it to be extremely useful, so I tried a simple application with it. The sample application accepted string from a text field and displays encrypted string in another text field.
I wrote this function to perform the task:

- (IBAction)performEncryption:(id)sender{
NSLog(@"performEncryption:");
// doing encryption
NSData *data = [[decryptedText stringValue] dataUsingEncoding:NSUTF8StringEncoding];
NSData *encryptedData = [data AESEncryptWithPassphrase:@"test-key"];

// showing encrypted text
NSString *encryptedString = [[[NSString alloc] initWithData:encryptedData encoding:NSUTF8StringEncoding] autorelease];
[encryptedText setStringValue:encryptedString];
}

but it is not working!

I also tried to obtain log of NSData , returned at the end of function:

- (NSData *)AESEncryptWithPassphrase:(NSString *)pass

but I am getting (null) for the log:
NSLog(@"encrypted string returned - %@",[[[NSString alloc] initWithData:ret encoding:NSUTF8StringEncoding] autorelease]);

Can you suggest me where I may be wrong??

Thanks,

Devarshi

eileenb said...

For those app developers that don't know Objective-C and Cocoa Touch and don't want to outsource development, check out localbeacon (an iphone app builder) at www.bigforge.com. Great for those who want to build just one app or developers interested in white label. Full integration of Twitter and Facebook.

Nico said...

@Devarshi: i have the same problem :( when i convert the encrypted NSData object to an NSString, it says 'null'.

I tried instead of NSUTF8StringEncoding the NSASCIIStringEncoding. With this one i got something printed, but it didn't work out well because the decrypted value didn't match up with the original string.

Nico said...

Update: I think the returning NSString from NSData object is nil because the NSUTF8Encoding. How should i properly get an NSString from the returned NSData object?

Nico said...

Another update: it's no fault of the AES encryption, i just took the wrong way creating an NSString from the NSData.

Method which worked for me:

NSString *testString = [NSString stringWithCString:[encryptedData bytes] length:[encryptedData length]];

Still now i have a problem when special characters are used in the source NSString, like 'รถ'. Still looking for this.

Nico said...

Seems you can use stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding and stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding for the special characters. All is working fine now :)

Jayanth.S said...

Hi,

I am still struggling to get this working...NSData to NSString conversion problem...Nico, can you please post a code segment if You got it working...

UOW - FYP - Group SS09/4B said...
This comment has been removed by the author.
Tony Do said...

The method AESEncryptFile in NSFileManager-AES.h works perfect on my Mac if I use the CommandLine project in Xcode.

However, when I try to implement in iPhone simulator or physical iPhone device,The encryption and decryption can run put the output totally wrong...
Here is what happened:
Encrypted file in Mac totally different in iPhone environment

When i try to decrypt on iPhone, the decrypted file is bigger and contains all funny characters, cannot get the original plaintext

Any idea????
Thanks a lot in advance

Tony Do said...

Update: If i run using the commandline tool project type, using the architecture x86_64, it run perfectly. However if change to debug using i386 architecture (same architecture as iPhone), the encryption and decryption screwed up and the outputs become rubbish, Anyone how to fix this issue???

Related to different architecture...

Thanks

The Lowrys said...
This comment has been removed by the author.
JLowry said...

Fantastic method! But I'm having an issue. I'm trying to implement this in a Cocoa desktop application and I'm getting random results. About 1/4 of the time it seems to work flawlessly. The remainder of the time the decrypted string is returning (null). I tried Nico's method of going around NSUTF8StringEncoding, but then I get garbage text for the 3/4 of the time that I was getting (null) and the other 1/4 of the time it's working again.

Any ideas as to what would cause this to happen? I sort of figured it would either work or not work.

sol0 said...

If you just want to encrypt stuff, try my version:

http://www.bigcatos.com/BigCatOs/Krypton.html

surajit said...

Hi,
I have gone through all the code snippets here.
Whats is my observation is can we develop AES256 encryption and decryption support on apple?
or only AES128 algorithm.

Best Regards,
Surajit

surajit said...

I have tryed ur

-(BOOL)AESEncryptFile:(NSString *)inPath toFile:(NSString *)outPath usingPassphrase:(NSString *)pass error:(NSError **)error
{
unsigned long rk[RKLENGTH(KEYBITS)];
unsigned char key[KEYLENGTH(KEYBITS)];
const char *password = [pass UTF8String];

for (int i = 0; i < sizeof(key); i++)
key[i] = password != 0 ? *password++ : 0;

int nrounds = rijndaelSetupEncrypt(rk, key, KEYBITS);
FILE *fp = fopen([inPath UTF8String], "r");
FILE *output = fopen([outPath UTF8String], "wb");
if (output == NULL)
{
*error = [NSError errorWithDomain:@"AES Encryption" code:1000 userInfo:[NSDictionary dictionaryWithObject:NSLocalizedString(@"File Open Error", @"File Open Error") forKey:AESEncryptionErrorDescriptionKey]];
return NO;
}
while (1)
{
unsigned char plaintext[16];
unsigned char ciphertext[16];
int j;
for (j = 0; j < sizeof(plaintext); j++)
{
int c = getc(fp);
if (c == EOF)
break;
plaintext[j] = c;
}
if (j == 0)
break;
for (; j < sizeof(plaintext); j++)
plaintext[j] = ' ';
rijndaelEncrypt(rk, nrounds, plaintext, ciphertext);
if (fwrite(ciphertext, sizeof(ciphertext), 1, output) != 1)
{
fclose(output);
*error = [NSError errorWithDomain:@"AES Encryption" code:1000 userInfo:[NSDictionary dictionaryWithObject:NSLocalizedString(@"File write error", @"File write error") forKey:AESEncryptionErrorDescriptionKey]];
return NO;
}
}
fclose(output);
fclose(fp);
return YES;
}
its not working the files generated are not able to open using your decryptor. I that i am doing some thing wrong

John Verco said...

Thanks for the awesome code.

To get decryption working, if you are using an IV initialization string, you must force it to UTF8 encoding in the CCCrypt method:

[ivString UTF8String];

Prem Kumar said...

A complete implementation for newbies. All the above examples might look confusing for many newbies, please go thru the following link

http://pastie.org/966473

coolblade said...

Are we playing programmer tennis? I want to play too. Serve! http://pastie.org/967346

Prem Kumar said...

good one coolblade

coolblade said...

Fixed a bug in my original code, I believed from looking at someone else's code that CCCryptorFinal only needed to be called when the total bytes did not evenly divide into 16 blocks. Wrong. I actually ran into the one-off scenario where a 96 byte data set was returned and not having the CCCryptorFinal chopped off the last few bytes. It is fixed here: http://pastie.org/974094

puneet said...

Hi First its a great post

I have a NSString I wanna encode therefore using NSData-AES
but first I converted NSString to NSData like this

"NSData* newdata = [olddata dataUsingEncoding:NSUTF8StringEncoding];"

then encrypting it by

"NSData *encryptedData = [newdata AESEncryptWithPassphrase:@"Encrypted UDID"];"

but its not working!

error

*** -[NSConcreteMutableData getCharacters:range:]: unrecognized selector sent to instance 0x3b15f60
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[NSConcreteMutableData getCharacters:range:]: unrecognized selector sent to instance 0x3b15f60'
Stack: (
29307995,...

NukemHill said...

I've had similar problems to what puneet is relating. I ended up doing something like this:

NSMutableData *objNSData = [NSMutableData dataWithData:[[value description] dataUsingEncoding:NSUTF16StringEncoding]];

This gets me as far as encoding, and then encrypting, the data. But when I decrypt it, I get a null value back. I'm using Prem's category on NSMutableData. When I dig into that code during runtime, I get a kCCParamError when executing CCCrypt.

Is there any way to determine exactly where the parameter error is occurring? This has been frustrating as heck.

NukemHill said...

Never mind. I figured it out.

Edwin said...

scrub m65 kamagra attorney lawyer body scrub field jacket lovegra marijuana attorney injury lawyer

antywong said...

The rounded shape of speedy 30 features textile fake louis vuitton lining and leather trimmings with shiny Louis Vuitton Monogram ldylle Romance Encre golden brass. Sized at 11.8" x 8.3" x 6.7", the large capacity Hermes Original Python Birkin 30 Grey of this bag is enough for handbags review daily essentials; you can put bags wholesale everything into this city bag. It also fits for Hermes Clemence Jypsiere 34 Purple every occasion and perfectly goes with any outfits mfakng100910.

Black mash said...

Hi Jeff LaMarche! I'm newbie iphone development. I'm using your AES to encrypt data. But i build your AES to static library and using another project. I can't use function [data AESEncryptWithPassphrase:], it has error: [NSConcreteMutableData AESEncryptWithPassphrase:]: unrecognized selector sent to instance 0xf14470.

I can't fix it. Give me an advice, please!
Sorry my english.

h4ns said...

What youre saying is completely true. I know that everybody must say the same thing, but I just think that you put it in a way that everyone can understand. I also love the images you put in here. They fit so well with what youre trying to say. Im sure youll reach so many people with what youve got to say.

Arsenal vs Huddersfield Town live streaming
Arsenal vs Huddersfield Town live streaming
Wolverhampton Wanderers vs Stoke City Live Streaming
Wolverhampton Wanderers vs Stoke City Live Streaming
Notts County vs Manchester City Live Streaming
Notts County vs Manchester City Live Streaming
Bologna vs AS Roma Live Streaming
Bologna vs AS Roma Live Streaming
Juventus vs Udinese Live Streaming
Juventus vs Udinese Live Streaming
Napoli vs Sampdoria Live Streaming
Napoli vs Sampdoria Live Streaming
Fulham vs Tottenham Hotspur Live Streaming
Fulham vs Tottenham Hotspur Live Streaming
AS Monaco vs Marseille Live Streaming
AS Monaco vs Marseille Live Streaming
Alajuelense vs Perez Zeledon Live Streaming
Alajuelense vs Perez Zeledon Live Streaming
Technology News | News Today | Live Streaming TV Channels

h4ns said...

What youre saying is completely true. I know that everybody must say the same thing, but I just think that you put it in a way that everyone can understand. I also love the images you put in here. They fit so well with what youre trying to say. Im sure youll reach so many people with what youve got to say.

Arsenal vs Huddersfield Town live streaming
Arsenal vs Huddersfield Town live streaming
Wolverhampton Wanderers vs Stoke City Live Streaming
Wolverhampton Wanderers vs Stoke City Live Streaming
Notts County vs Manchester City Live Streaming
Notts County vs Manchester City Live Streaming
Bologna vs AS Roma Live Streaming
Bologna vs AS Roma Live Streaming
Juventus vs Udinese Live Streaming
Juventus vs Udinese Live Streaming
Napoli vs Sampdoria Live Streaming
Napoli vs Sampdoria Live Streaming
Fulham vs Tottenham Hotspur Live Streaming
Fulham vs Tottenham Hotspur Live Streaming
AS Monaco vs Marseille Live Streaming
AS Monaco vs Marseille Live Streaming
Alajuelense vs Perez Zeledon Live Streaming
Alajuelense vs Perez Zeledon Live Streaming
Technology News | News Today | Live Streaming TV Channels

chamroeun said...

How can i decrypt the encrypted data using .NET?
The encrypted data used the code developed by this author.

I try several .net tool. but not work. Padding error...

Please help

jazz said...

I am rather baffled by the first comment from Alain Quatermain stating that the CCTAS hassle can be avoided simply by using a category. Can anyone please confirm or discuss the correctness of this statement? Even while using this category one WILL have to answer yes to "does you app use encryption" during the apple publishing process thereby making you eligible for contact with BIS for getting an export license. So how does using existing encryption code alleviate that?

pRaMoD said...

Had any one worked on DUKPT+3DES decryption using Objective C. I have been using a credit card reader , iDynamo where the device is responding the DUKPT 3DES encrypted content, and I needed to decrypt. Any idea, how can get through this.

Thanks much.

iphonedeveloper said...

Hi,

I am using the encryption/ decryption method. It works fine but when I convert the encrypted data into in string it return nil.I want that data in string formate.
Can you please explain me where I am wrong?

Thanks