OneSadCookie Wrote:libcrypto, but you'll have to build it yourself (and you'll have to declare your app as a user of cryptography when you submit)

I have my own crypto functions included. For something like high scores you can just pick a crypto algo and drop it in. No need for a full library.

Also, with regards to declaring cryptography, you basically don't need to do anything special if its not doing encryption for the user, but just maintaining security of program components. So for something like high scores, you won't need to do any special declarations with the government.

alerus Wrote:I have my own crypto functions included. For something like high scores you can just pick a crypto algo and drop it in. No need for a full library.

Also, with regards to declaring cryptography, you basically don't need to do anything special if its not doing encryption for the user, but just maintaining security of program components. So for something like high scores, you won't need to do any special declarations with the government.

It's generally a bad idea to use your own cryptography functions. If it's your own algorithm, unless you're an expert at cryptography it's almost guaranteed to be very weak. If you're implementing an established algorithm, like AES, it's better, but you need to have very extensive testing to ensure that your implementation isn't faulty. And that's just the general block cypher, that's not even including many of the things to make it properly secure, such as using something other than ECB mode, generating secure keys, etc. There are so many places to make a mistake, with any mistake potentially compromising the entire system, that it's much better just to use an established API that has been thoroughly tested, peer reviewed, etc.

As for export restrictions, from what I understand the government has an issue if you can input arbitrary data with an arbitrary key and get the encrypted result, then be able to retrieve that data on another end. In other words, if it can reasonably be used for encrypted communication. Stuff like storing data files is fine, since you're using a single stored key, which isn't actually secure anyway. (you have to store the key somewhere, and that can always be extracted from the executable, no matter how much you try to obfuscate it) Products like Netscape got around the restrictions when it was even more restrictive by publishing part of the key, shortening the effective key length to 40 bits.

But regardless of all these issues, why are you so worried about encrypting your high scores? That seems like complete overkill to me. The only thing I can possibly see somebody doing with that is editing their file with a bogus high score. So they now have a bigger number showing on the screen. What's the big deal? No matter what data file you try to encrypt in your game, all it will succeed in doing is increase your development time and eat up more processor power to keep at most a couple people (and I'd give it a 95% chance it will be 0 people) from hacking anything, where any hacks won't make any difference in the first place.

akb825 Wrote:It's generally a bad idea to use your own cryptography functions. If it's your own algorithm, unless you're an expert at cryptography it's almost guaranteed to be very weak. If you're implementing an established algorithm, like AES, it's better, but you need to have very extensive testing to ensure that your implementation isn't faulty. And that's just the general block cypher, that's not even including many of the things to make it properly secure, such as using something other than ECB mode, generating secure keys, etc. There are so many places to make a mistake, with any mistake potentially compromising the entire system, that it's much better just to use an established API that has been thoroughly tested, peer reviewed, etc.

As for export restrictions, from what I understand the government has an issue if you can input arbitrary data with an arbitrary key and get the encrypted result, then be able to retrieve that data on another end. In other words, if it can reasonably be used for encrypted communication. Stuff like storing data files is fine, since you're using a single stored key, which isn't actually secure anyway. (you have to store the key somewhere, and that can always be extracted from the executable, no matter how much you try to obfuscate it) Products like Netscape got around the restrictions when it was even more restrictive by publishing part of the key, shortening the effective key length to 40 bits.

But regardless of all these issues, why are you so worried about encrypting your high scores? That seems like complete overkill to me. The only thing I can possibly see somebody doing with that is editing their file with a bogus high score. So they now have a bigger number showing on the screen. What's the big deal? No matter what data file you try to encrypt in your game, all it will succeed in doing is increase your development time and eat up more processor power to keep at most a couple people (and I'd give it a 95% chance it will be 0 people) from hacking anything, where any hacks won't make any difference in the first place.

I agree with your 1st part, but not with your last part.
Just because these local highscores will be uploaded to one of my servers and if somebody uploads a cheated highscore, others players would not be happy
Something similar to Doodle Jump approach is what I want.

You are right with developing my own encription algorithm, probably would not be very strong.

Can I use CommonCrypto/CCCrypt without any legal issues? (I know is a bad idea using undocumented Apple APIs)

akb825 Wrote:It's generally a bad idea to use your own cryptography functions. If it's your own algorithm, unless you're an expert at cryptography it's almost guaranteed to be very weak. If you're implementing an established algorithm, like AES, it's better, but you need to have very extensive testing to ensure that your implementation isn't faulty. And that's just the general block cypher, that's not even including many of the things to make it properly secure, such as using something other than ECB mode, generating secure keys, etc. There are so many places to make a mistake, with any mistake potentially compromising the entire system, that it's much better just to use an established API that has been thoroughly tested, peer reviewed, etc.

I'm referring to implementations of something like AES, not my own custom designed crypto algorithm. You can also find straight implementations of these on the net, without needing a whole crypto library.

akb825 Wrote:As for export restrictions, from what I understand the government has an issue if you can input arbitrary data with an arbitrary key and get the encrypted result, then be able to retrieve that data on another end. In other words, if it can reasonably be used for encrypted communication. Stuff like storing data files is fine, since you're using a single stored key, which isn't actually secure anyway. (you have to store the key somewhere, and that can always be extracted from the executable, no matter how much you try to obfuscate it) Products like Netscape got around the restrictions when it was even more restrictive by publishing part of the key, shortening the effective key length to 40 bits.

Maybe I'm misunderstanding, but isn't this what I described? If you can use it for actual user encryption purposes then you have to get the government approval. If its just for security of internal data, then you don't. I read a bunch about it awhile ago, but there is a subsection in the agreement that details this. On apple's approval page they'll go through the questionnaire starting with "Do you use encryption", followed by "Does your product contain encryption for any purpose other than authentication?" If you answer no to that, then it clears the page and lets you go on. Otherwise it goes through a number of other questions that ultimately results in them requiring the government certificate if you answer yes to all of them.

akb825 Wrote:But regardless of all these issues, why are you so worried about encrypting your high scores? That seems like complete overkill to me. The only thing I can possibly see somebody doing with that is editing their file with a bogus high score. So they now have a bigger number showing on the screen. What's the big deal? No matter what data file you try to encrypt in your game, all it will succeed in doing is increase your development time and eat up more processor power to keep at most a couple people (and I'd give it a 95% chance it will be 0 people) from hacking anything, where any hacks won't make any difference in the first place.

Might matter if the game can pull from the file to upload to an online leader board.

alerus Wrote:I'm referring to implementations of something like AES, not my own custom designed crypto algorithm. You can also find straight implementations of these on the net, without needing a whole crypto library.

Finding an implementation on the net should be OK, as long as you can trust that it has been thoroughly tested and is correct. You still have to be careful, though, because even if you use a strong algorithm like AES your system won't be secure unless you use it properly. For this application it doesn't really matter, but I want to make sure that people know that in general it is best to use a more full featured API that brings together all the algorithms necessary to make a secure system for general purpose usage.

alerus Wrote:Maybe I'm misunderstanding, but isn't this what I described?

That is more or less what you described, but I thought it could use some clarification. Additionally, I wanted to clarify that it isn't that you intend your program to do arbitrary encryption, but that it is capable for it to do so that matters. For example, let's say that you make a utility that allows you to make maps for games. To make sure your customers can prevent others from stealing their maps, let's say you allow them to encrypt the map with a key, and for your library to link to the game can then decrypt the map with the same key. That sounds harmless enough, and is only used to manage internal usage of files. However, it is possible for somebody to encode a message in that map and use it for secure communication, since you can specify whatever key you want for the map files. I believe that would still be restricted under US law, since it can be used for secure encryption, even though it wasn't meant to.

riruilo Wrote:Just because these local highscores will be uploaded to one of my servers and if somebody uploads a cheated highscore, others players would not be happy

In that case it would make sense. There is another way you can do this without encryption: you can hash the high score file with an added salt when you save it out, then append the hash to the file. Whenever you read it back in to either display them locally or send them, you can hash the high scores (minus the appended hash) and compare it to the hash written out. Unless the users know the salt, they can't reproduce the hash, so it will prevent any tampering. This will be just as secure for your purposes as encrypting it and should be easier to implement.

akb825 Wrote:Finding an implementation on the net should be OK, as long as you can trust that it has been thoroughly tested and is correct. You still have to be careful, though, because even if you use a strong algorithm like AES your system won't be secure unless you use it properly. For this application it doesn't really matter, but I want to make sure that people know that in general it is best to use a more full featured API that brings together all the algorithms necessary to make a secure system for general purpose usage.

That is more or less what you described, but I thought it could use some clarification. Additionally, I wanted to clarify that it isn't that you intend your program to do arbitrary encryption, but that it is capable for it to do so that matters. For example, let's say that you make a utility that allows you to make maps for games. To make sure your customers can prevent others from stealing their maps, let's say you allow them to encrypt the map with a key, and for your library to link to the game can then decrypt the map with the same key. That sounds harmless enough, and is only used to manage internal usage of files. However, it is possible for somebody to encode a message in that map and use it for secure communication, since you can specify whatever key you want for the map files. I believe that would still be restricted under US law, since it can be used for secure encryption, even though it wasn't meant to.