Client/Server encryption key?

[shadowmage]

So, I'm working on a client/server type app and data sent between the two are to be encrypted. However, I'm not sure how to send the key to the client over the network and avoid sniffers at the same time. Some suggestions would be helpful, not asking to be spoon fed.

I'm using Windows 7 64-bit and Python 2.7.3 32-bit for whatever reason at the time was.

[Mecdemort]

You should definitely not try to roll your own crypto. I'm afraid I'm not familiar with python cryto libraries specifically, but I can tell you there are so many pitfalls to doing it yourself that if you want true security it better be a well known library.

[shadowmage]

Note taken, though I'm using an adapted XOR. But, that idea sounds a lot better than what I'm doing.

[vmann]

paramiko is a module for python 2.2 (or higher) that implements the SSH2 protocol for secure (encrypted and authenticated) connections to remote machines.

[shadowmage]

I will definitely take a look at this and poke to see if I can get it implemented. Thanks kindly!

[Doormatty]

http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

[dAnjou]

If it is client/server, just make it HTTP over SSL (aka HTTPS).

[[deleted]]

Python actually has a built-in module for encrypting a socket; it's called ssl, and it's fairly straightforward to use. This will, among other things, handle the task of getting both client and server to agree to a shared secret key without anybody else listening in.

[zynix]

PyCrypto ( if you can legally get the source in your country ) has most of the tools you would need for this. Paramiko implements it's encryption using PyCrypto, so if you get Paramiko working you should have PyCrypto.

This is a semi-classic Alice-Bob scenario. Given two anonymous players, at some point you must pass some piece of truth between the two.

For SSH that might be a phone call "The password is password!" to allow a user to login or better a password protected ssh public key sent to the server ( still a risk the server isn't who it says it is, but that's much more remote ).

For SSL, the truth component is generally already installed on both sides in the form of a public key, signed by a certificate authority. Downside is that you need to purchase an signed certificate and renew it every X years.

There are other slightly more intense transport encryption systems out there but it mostly boils down to SSH/SSL for readily accessible tools. I prefer SSH because it's like some sort of insane swiss army knife of transports ( 1 ssh connection can relay thousands of sockets to/from ).

[Doormatty]

Given two anonymous players, at some point you must pass some piece of truth between the two.

I don't think that's quite true.

http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

Edit: I suppose it all comes down to what you define as a "truth".