Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have a server, which sends content encrypted with AES128 or RC4 to a flash client over an insecure HTTP channel. The encryption key is negotiated using Diffie Hellman.

The problem:

  • Diffie Hellman can be MITM-ed.
  • flash client can be easily reversed (can be obfuscated though), so if I use a hardcoded key, it can be easily retrieved

Is there any way to strengthen the weakest links, in this case, the key exchange and the flash client?

share|improve this question
What are your requirements? Can you basically do anything you want for key exchange (i.e., you have free reign over the software)? Does the user have a password that the server knows? – mikeazo Oct 15 '12 at 18:01
How about just hardcoding the server's public key into the client? That prevents MitM. Or throw HTTPS at the problem. – CodesInChaos Oct 15 '12 at 20:09
You need to state your threat model and context some more (e.g. how much is the client trusted and is there any relation previously set-up between the two, like an account or did the client pay to receive the content). – bob Oct 15 '12 at 21:08

The usual solution for the Man-in-the-Middle problem of Diffie-Hellman is to combine it with a public-key authentication solution.

This could either work by including the server's public Diffie-Hellman key (which then must be a long-term key, not a short-term or even session key – this way you lose your forward-security) in the client, or including a signature key (DSA, RSA, ECDSA) with the client, where the server uses the corresponding private key to sign everything what was exchanged. (All those ways of authentication are used in SSL/TLS ciphersuites, by the way.)

Of course, this then poses the problem how the client (i.e. your flash application) comes securely to the browser in the existance of a MitM – so you'll have to also use some authentication solution on the transfer of this, using another public key, maybe certified by some key the users already know (and trust).

By then, you can just use SSL/TLS for the whole communication, both for delivering your flash client as well as to receive the secret data from the server.

share|improve this answer
It's also possible to use two DH exchanges. One for authentication including the server's long term key and one with ephemeral keys for confidentiality. That way you get authentication and forward secrecy. – CodesInChaos Oct 23 '12 at 7:14

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.