   DiffieHellman key exchange
  I was trying to follow it on wikipedia and on http://www.mindcontrol.org/~hplus/authentication.html,they talk about the algorithm and an implementation.What I do not understand is if the algorithm is a one time handshake? I mean, after the key is calculated on both machines then now what? how can machines transfer the messages? if there is a packet sniffer the key will be sniffed?or is the key calculated everytime a message needs to be sent?   
  Diffie-Hellman key exchange is just that, a key exchange. You use the key that you've exchanged in a symmetric cipher, such as AES.Infact the first line on Wikipedia says this:Quote:Diffie-Hellman key exchange (D-H) is a cryptographic protocol that allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure communications  channel. This key can then be used to encrypt subsequent communications using a symmetric key cipher.RegardselFarto   ;  The article states specifically that authentication is about making sure that you are who you say you are, not anything about protecting packets in transit. If someone can attach to your network, to the degree that they can read your packets and spoof your source IP address, you've already lost.Also note that D-H is not safe against a man-in-the-middle attack. Specifically, a MitM can open one connection to the server, and then accept a connection from the client, and run one D-H exchange each way. This means that the client and the server both believe they have a negotiated key, but the MitM will decrypt data sent by one, and encrypt it for receipt by the other, seeing the cleartext in the middle.It is not possible to create something fully secure without a separate shared state channel somewhere. For example, HTTPS/SSL uses a trusted third party as shared state -- but to trust that third party, you need a root certificate, which generally comes pre-installed with your web browser/OS. (or you can download such a certifiacte using un-secured communications, but then you're as vulnerable as that channel is)If you really care, generate a strong public/private key pair. Ship the client software on CD. Put the public key on the CD, so the user knows the key hasn't been tampered with, and put the private key on your server. Make sure it never gets compromised. Use this key pair to initiate communication. This solves secrecy of communications, but does not solve authenticity.;  what I am interested in doing is very simply submitting a highscore without cheating.Here is the full scenario:- server is in php, which expects a POST with a score number- client is in flash and needs to submit the score.The logic:- when the user logs in, I store the user id in a session variable.- when the user submits a score, I check the saved uid and set the score.The protection:- when user logs in, I generate a random shared key and send it to the user.- any communication with the server needs to use that key.The hacks:- any man in the middle attack can read the key.- if the user wants to cheat, it is just a matter of installing a packet sniffer and reading the values I am sending via POST. Then they would send a new highscore, it is that easy.The improvement:- adding an MD5 to the send request, for example, while sending the score, the user also sends an MD5 of the score + the shared random key or + a value we agree on.- the server calculate the md5 and checks if correct then this is a legit user.A possible hack scenario:- the user decompiles the flash file and thus reads the formula or MD5 values being used.Any ideas for making it harder on cheaters? As I want something that I cannot crack myself.   ;Quote:Original post by ZeRaWA possible hack scenario:- the user decompiles the flash file and thus reads the formula or MD5 values being used.As long as the user has physical access to his or her own machine, this scenario is always possible.If you just want to make it inconvenient, use a public/private keypair to let your client obtain a one-time (timed) session key from your server.  Use that session key to wrap the data posted to your server.  This would eliminate replay attacks, the encyption would eliminate cleartext attacks, and there is no way to eliminate the decompile/MitM attacks, so it's about as good as you're going to get for your purposes.   