But why on earth would something decrypt like that? Do you have a simple example?
Well, I believe the reason is that each one is written differently. Since as2 bytes are accessed -127 / 127 and java bytes are accessed 0 - 256 it might be the root of the problem. I encountered this using RC4 encryption algorithm with flash / java.
Its a chat/game client/server system, so I'm not worried about too much "real" time response. I'd have to test, of course.
If it is merely a game, i really wouldn't worry about encryption unless there are transactions involved. Or perhaps you could only encrypt the important messages involving score changes or something.
Eh, well, the way I "envisioned" this is that decryption on the server side would always be the same. And public keys for ActionScript would be set during the initial server-client response and not change for that session. My socket connections are persistent, and I iterate over lists of them in separate threads to see which ones need a new request/response thread. So the public key would just be stored with the stream and accessed by the request/response thread. Why would the key need to be changed each time? Why not for each client?
It depends entirely on how you implement it. If you have a dynamic key that changes packet to packet for each client, you will have to generate the key each time it changes. If each client has a different key, and that key stays static, then you just generate it and it is stored in the memory.
Having never done anything with MD5 or SHA I'll have to look those up.
They are very quite simple. You just input a byte array or string and it will digest it and return a hash like m1abnt2nbw4mkasd4.
Here's my question on MD5 and SHA though with passwords. The idea here is that I store something in my database, apparently this should be the salted encrypted password. At what point in this process is recommended to do this.
Ok the standard way most people manage passwords goes like this. The account is created, the password is hashed and then placed in the database. When the account tries to log in, the password provided by the client is hashed and compared to the original. If it matches, then grant them access. If it fails, tell them they have the wrong password. If they forget their password, you generate a random key most likely using MD5 or SHA, store it in a database, and send an email to the user account. Once they click the link, it will bring them to a secured page in which they will be allowed to type a new password in and the process starts from the beginning.
If I do it in the client, then this new salted thing becomes the actual password and a hacker only needs to submit that value to my server.
If I salt and hash it on the server end, then again, all they need to do is get the real password in transit and pass it on.
If a hacker has access to ALL of the transmissions between the client and the server, that client has more to worry about than the password to his account being compromised. What you can do to prevent this, is to hash the new password on the server end once with a salt, and a second time with another different salt. Then when the client types his password and clicks log in , it will hash the password with the first salt, the server then recieves the message, hashes it again, compares it to the original. This will keep the password safe in transit to the server without revealing the true way you hash passwords on the back end.
It seems no matter what sha/md5 doesn't actually protect except against when users can see the passwords in my database or before it moves in transit so that they can enter it into the client themselves.
These digest algorithms are a one way encryption, meaning you encrypt it and you cant unencrypt it. It is good for something like password storage as you do not want a hacker to acquire unencrypted passwords as most idiots on the internet use the same password for every site and online bank account. This is basically just security for the mass amount of clients in case of a breach in security of the database. If you don;t properly secure these and someone can prove gross negligence, you could be sued.
What added bonus is there to doing this if I'm already using something along the lines of RSA, which, btw, apparently isn't worth using anymore?
Just because the big wigs say it shouldn't be used doesn't mean its obsolete. For what you are doing you don't need top of the line online banking SSL encryption. The only person that would be able to crack an RSA encryption is the kind of person that would want to get paid for it. IE they want to steal credit card numbers. For what you are using it for however, it is fine. I believe the only real attacks on RSA are brute force or partial decryption and these take a very long time to perform. They could most likely obfuscate and reverse engineer your game before they cracked it, unless they figured out what the key was.
One more point i want to make, even if they crack your packet encryption, what will they do then? Think about it. Are they just going to cheat or post a really high score on a high score list or something trivial like that? Just make it so your server has some logic when processing the packets from the clients. Make it so it knows when a movement packet has exceeded a certain amount of distance in a set amount of time, and flag that user that they are warp hacking. Just create basic back end logic to counter the cheaters and it would be more than enough.
