If you have a .Net application (or any other application for that matter,) how do you safely store internal encryption keys? I'm not talking about user-entered keys, but keys that are hard-coded in the program itself, for talking between other instances of the program. For example, if you have a peer to peer type program, you may want to encrypt the packets so you're sure you're talking to another instance of your program, and not someone else's. My solution would be to hard-code a key into the clients, and simply encrypt/decrypt everything that way.
I'm wondering, however, if this is safe to do in .Net. I haven't worked extensively with Reflector or anything of the sort, but from what I hear, it sounds fairly easy to deconstruct .Net applications from CIL. Would going and finding my magic number be trivial for someone with one of these applications?
There is absolutely no way to verify that the executable on the other end of the connection is the one you wrote. If you encrypt a key with a key, where do you store the second key? If you Diffie-Hellman that with the server's to get a secret key, where do you store that key? (hint: in memory, where it can be dumped from then read). It's a recursive problem that you can never solve.
I've read that AOL Instant Messenger's servers would periodically poll the AIM client for the hash of specific addresses of code (i.e. calculate SHA1(address1 -> address2)) and then disconnect the client if the hash was not correct. This was because it is illegal to redistribute the executable (and unfeasible to build a table of the hash between every two intervals), so this is merely a legal challenge and not a technical one.
If you want software that really tries hard to defeat reverse engineering (and actually does a good job), try attaching a debugger to Skype :-)