what's an alternative to use instead of a CommonCrypto on iphone?

Getting ready to submit my app to the Apple's Itunes store and got puzzled by a question during the submission process: "Export laws require that products containing encryption be properly authorized for export...... Does your product use encryption?"

I've used CommonCrypto CommonCryptor.h to encode settings file against its unauthorized modifications. So now I'm not sure if I 开发者_JS百科have to remove all the encryption completely and leave just an xml file basically as is or should I use some other method to protect the file. What other simple protection mechanisms I can use to protect it and at the same time do not use any encryption so I can submit my app without tons of extra paperwork?

---

Your use of "encryption" is not subject to US export rules because it's not for "information security" (I think you answer "yes, yes, yes, no" or so, ICBW, or they could have changed the order). Essentially, if it doesn't stop the NSA from spying on you, they're happy to let you use it.

However, encryption traditionally provides confidentiality, not message integrity. If you want to ensure that the user hasn't tampered with the settings file (e.g. by editing the iPhone backup), just save it with a MAC. That is,

1. Generate a MAC key (pull some bytes out of /dev/random).
2. Calculate the MAC of the file when you save it (see Objective-C sample code for HMAC-SHA1; note that the accepted answer is actually HMAC-SHA-256)
3. Append the MAC to the end of the file (or set it as a file attribute, or stick it in another file).
4. When reading, calculate the MAC on the file and verify that it's the one you saved. If it's appended to the file, you'll have to remove the last few bytes (e.g. [NSData dataWithContentsOfFile:path], then -subdataWithRange: twice to get the "message" and MAC, then verify the MAC, and parse the "message" if verification succeeds.

It won't stop someone with a jailbroken phone from extracting the MAC key from your binary, but not much will. It also won't stop someone from reading the plaintext settings file, but that might not be such a problem.

If you're generating the file on a computer you control (e.g. it's a file downloaded from a server), then sign it. Technically, RSA signature validation is equivalent to encryption, but I don't think it counts as encryption for export purposes (if it does, it's for "authentication" purposes and still doesn't count). DSA signature validation isn't encryption (I think, the math behind it went way over my head) and should also be fine.