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?

  • $\begingroup$ 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? $\endgroup$
    – mikeazo
    Oct 15, 2012 at 18:01
  • 2
    $\begingroup$ How about just hardcoding the server's public key into the client? That prevents MitM. Or throw HTTPS at the problem. $\endgroup$ Oct 15, 2012 at 20:09
  • 2
    $\begingroup$ 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). $\endgroup$
    – bob
    Oct 15, 2012 at 21:08

1 Answer 1


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.

  • 1
    $\begingroup$ 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. $\endgroup$ Oct 23, 2012 at 7:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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