views:

72

answers:

3

Hello all,

I am creating a TCP connect with Flash to a C# daemon.

Now I have come to the part of encryption... I know that Flash is decompilable and so not safe to store private keys on.

I need 2 way encryption because of the messages that have to be send back to the Flash client.

I have been thinking and googling, but cannot find a proper solution yet.

Anybody got an idea??

+2  A: 

You'd usually use a hybrid encryption.

  1. Client opens a session on the server, acquiring public key for an asymmetric encryption.
  2. Client generates a key for a symmetric encryption, and sends this key to the server, encrypted with the public key previously acquired.
  3. The rest of the communication is encrypted using a symmetric encryption with they key now known to both client and server.

greetz
back2dos

back2dos
The OP should read _Applied Cryptography_. This solution is OK and is described in that book. It has a weakness called "man in the middle" which can be accomplished with DNS hijacking or inserting a driver in the TCP/IP stack. But +1
Heath Hunnicutt
@Heath Hunnicutt: I have to admit, I never read it, but I do know about *man in the middle*. Does it also provide a solution to protect a client-server-architecture against *man in the middle*, assuming the client code is actually sent over that very insecure wire?
back2dos
A: 

back2dos' solution will work (and be the easiest) if your connection is SSL/TLS.

If you are forced to use regular sockets (e.g., the server does not have an SSL certificate), then you'll need to do the same by hand. In this case, you'll need to use a Diffie-Hellman key exchange, which enables the creation of a shared secret that is not actually sent over the wire.

Again, if possible, use back2dos' solution. It's a lot easier.

Stephen Cleary
A: 

...............

fuck
Answers are not comments. If you want to post comments, click on the "add comment" feature. You can delete you answers.
Sam
you mean can't, don't you? it's ok, I can blank them instead :)
fuck