2

My app computes hash of some strings (that identify in-app purchases) using simple function of my own making. This function is very far from something sophisticated like MD5 - it is just simple hash function with result multiplied few times by large primes - the whole computation is 8 lines in Swift. The hash is then stored using NSUserDefaults. The app does not do anything else that could be considered encryption.

When submitting my app Apple asks me to fill Export Compliance starting with this question:

Is your app designed to use cryptography or does it contain or incorporate cryptography?

So does it? The Export Comliance is required by Apple due to US Export Administration Regulations. Here is the regulation guide linked by Apple and here are some notes about it by Apple.

Paulie_D
  • 107,962
  • 13
  • 142
  • 161
Rasto
  • 17,204
  • 47
  • 154
  • 245
  • 1
    No, it does not. Don't bother. – Fahri Azimov Mar 12 '16 at 12:49
  • @FahriAzimov Could you elaborate a bit more? Perhaps include citation or link? To avoid asking for permission I can do 2 things: Answer this first question NO (because hashing is not cryptography), or answer it YES and then answer next question YES (claiming my app is egible for exemption based on [Note 4 to Category 5, Part 2](http://www.bis.doc.gov/index.php/policy-guidance/encryption/identifying-encryption-items#Three)). – Rasto Mar 12 '16 at 14:15
  • 2
    Hashing is not cryptography. I can't post any citation or the link, but I can share my own experience, I have posted a lot apps which use hashing, and always selected NO, because cryptography is meant to crypt some data, and get it back with one or another way, hashing is used to generate unique irreversible key from some input. Hope this was helpful. – Fahri Azimov Mar 12 '16 at 20:12
  • @FahriAzimov Thank you Fahri it was – Rasto Mar 14 '16 at 16:18
  • If hashing is encryption then any code using a map/hash table could be considered at risk. – Dave Newton Aug 03 '18 at 14:59

2 Answers2

3
  1. Incorporating/using hashing is not using encryption, you are not incorporating cryptography.
  2. Cryptographic hash functions are one-way function, there is no reversal/decryption possible, it is not encryption.
  3. Common Crypto is not Objective-C, it is "C".
  4. Using weaker algorithms in place of standard algorithms because it is easier is not professional.
  5. MD5 should not be used in new work, use SHA256 or better. On an iPhone 6s SHA255 is about 4x faster than MD5.
  6. The Common Crypto implementation is FIPS-140-2 certified.
zaph
  • 111,848
  • 21
  • 189
  • 228
  • Add 4: I disagree. Using cannon where you only need a bow is not *professional* just an *overshoot*. It is ["gold plating"](https://en.wikipedia.org/wiki/Gold_plating_(software_engineering)) and good project manager should not let you do that. That is if the ultimate goal is shiping great app to app store asap (this case) not creating exemplary architecture app e.g. to show to students. – Rasto Mar 14 '16 at 16:33
  • Add 1, 2, 3, 5, 6: Thank for interesting info and valuable opinion. – Rasto Mar 14 '16 at 16:35
-2

Short answer: yes MD5 is a cryptographic one way function designed to be difficult to reverse. It uses a 128 bit key to perform the hash. Export restrictions require permission for any key length or 56 bits of higher

Tibrogargan
  • 4,508
  • 3
  • 19
  • 38
  • Please do **read** the question. I stated that it is *far from something sophisticated like MD5* meaning that **I do not use MD5** or anything similar. It is simple hash function. – Rasto Mar 11 '16 at 23:35
  • Computing a hash with any function is cryptography. You key length is going to be a function of the primes you select, but if any of them exceed 2^55, you fall into export restrictions. Plus, you'll be using an insecure hash. – Tibrogargan Mar 11 '16 at 23:39
  • Since when is hash length equivalent to key length for the purposes of export restrictions? **Cite please.** Restrictions on key length, as usually understood, only apply for symmetric ciphers like RC4 or AES. – Seva Alekseyev Mar 11 '16 at 23:44
  • Thank you that is some usefull information. Perhaps I can relly on [Note 4 to Category 5, Part 2](http://www.bis.doc.gov/index.php/policy-guidance/encryption/identifying-encryption-items#Three) and exclude my app from control base on that? My app is keyboard extension (primary purpose is typing not encryption) and I only use this hashing to protect in-app purchases (no hard to break I know but I thing enought for this purpose). – Rasto Mar 11 '16 at 23:48
  • @SevaAlekseyev As for the key length: I believe under EAR there are different limits for symetric and asymetric encryptions. Does hashing like this qualify as symetric? Becase hashing si usually asymetric right? In which case key length could be 512 bits which is totaly fine for all those primes combined... – Rasto Mar 11 '16 at 23:59
  • Restrictions are based on algorithm strength and key length. Since your algorithm is very weak you would probably be ok, but you may need to get permission anyway, since it's custom. Since security isn't your primary concern why not just use a standard that does not require permission? – Tibrogargan Mar 12 '16 at 00:01
  • 2
    Hashing is not encryption, period. It's one-way, there's no possibility for decryption. The notion of "symmetric" or "asymmetric" doesn't apply - it has to do with the decryption key being the same as the encryption key or not. Hashing doesn't allow for decryption and doesn't have a key. – Seva Alekseyev Mar 12 '16 at 01:32
  • @Tibrogargan I do not use standard because it is too much work. Doing it this way costs me writing 8 lines of code (and is suficient for me). Using e.g. MD5 would mean adding bridging headers from Objective-C to Swift for cryptographic libraries, learning about it, writing some code on top of that or using somebody else's code (introducing dependence on somebody else's code), quite some testing to make sure it works well... overkill. I was hoping that based on Note 4 to Category 5, Part 2 I need no premission. Simply, it states that I permission isn't needed if primary purpose isn't encryption – Rasto Mar 12 '16 at 01:56
  • @SevaAlekseyev Ok, lets say it is not encryption. But is using hashing "incorporate cryptography"? That's is the formulation used by *Export Administration Regulations* (see my original question). I could not find anywhere what they mean by *cryptography*. When they use technical terms in law they should at least bother defining them... – Rasto Mar 12 '16 at 02:01
  • This question is actually a duplicate, but I can't give you the question number - on my phone. Looks like the restrictions have been much relaxed and hashing is not considered encryption. Even if it was, you may only need permission when exporting to a "terrorist" nation – Tibrogargan Mar 12 '16 at 03:06
  • 1
    Also, this might help even though it's not swift. http://stackoverflow.com/questions/6228092/how-can-i-compute-a-sha-2-ideally-sha-256-or-sha-512-hash-in-ios – Tibrogargan Mar 12 '16 at 03:13
  • @Tibrogargan Thank you for link. The problem in swift is with `#import `. `CommonCrypto` is apparantly not Swift library only Objective-C. Bridging header would be required - not really straightforward and with my project practically I do not want to do this. Feel free to add link to "duplicate" question when you are on desktop. – Rasto Mar 12 '16 at 14:08
  • On a side note, a C implementation of MD5 is short and sweet: http://people.csail.mit.edu/rivest/Md5.c – Seva Alekseyev Mar 12 '16 at 14:32
  • 1
    Export restrictions speak of key size. Hashing doesn't have a key, ergo - not restricted in any way. Hash size != key size. – Seva Alekseyev Mar 12 '16 at 14:33
  • Here is the other question http://stackoverflow.com/questions/7213936/does-external-md5ing-count-as-encryption – Tibrogargan Mar 12 '16 at 17:07
  • 1
    @Tibrogargan 1. MD5 does not use a key, you may be confusing hashing with HMAC. Cryptographic hashing is a one-way function, there is no decryption possible, it is not encryption. – zaph Mar 12 '16 at 21:11
  • @SevaAlekseyev It is not a good idea to implement your own versions of cryptographic function because an error man be made. There are also timing and power side-channels to consider and the Common Crypto implementation is FIPS-140-2 certified. – zaph Mar 12 '16 at 21:14
  • 1
    It's pretty obvious from the question that the OP is not after a cryptographically strong hashing. – Seva Alekseyev Mar 13 '16 at 01:58
  • Also it's pretty obvious that cryptographically strong hashing is not encryption. – zaph Mar 14 '16 at 16:37