[pycrypto] Can pycrypt do a key exchange?

[Bill Broadley]

James A. Donald wrote:
> Gre7g Luterman wrote:
>  > Hey list -
>  >
>  > I'm working on a Python application where clients will
>  > open encrypted connections to a custom server
>  > application. The data isn't something super-important,
>  > like credit card numbers, but I'd rather not have it
>  > snooped or otherwise mucked with by outsiders.

How controlled is the client environment, can you just setup a VPN?  Stunnel?
SSH port forwarding?  Certainly using an existing encryption system is is
likely to be the most secure, granted it might not be a good fit for your
application.  There's at least two python wrappers/bindings for openssl.

Are you writing the client software or is it via some published API where
other clients might want to connect?

>  > pycrypt makes this easy, but how do I share the key
>  > securely? pycrypt has code for calculating
>  > public/private keys, encrypting with them, decrypting
>  > with them, etc., but I don't see an obvious way to do
>  > an exchange with it.
> 
> Key distribution is in the general case a major unsolved
> problem

Openssl, SSH, PGP/GPG, and various p2p related libraries have implemented
various approaches.  I guess maybe not sufficiently general case, IMO a
pychrypto DH implementation would be a big step in the right direction.  Not
that key exchange is the same as key distribution.

>, and there are no libraries to handle it -
> worse, there are no protocols to handle it, worse still,
> there are no successful examples to imitate, other than
> SSH.

Well the SSL approach of distributing numerous root public keys with every
client and then having a chain of trust is a reasonable approach... as is ssh
of course.  x509 certs is another common approach, especially for network
services that publish and API and allow for random clients to connect (see
ec2, libvert, enomaly, s3, etc).

Certainly write no more code then you have to, there are many pitfalls, but
that doesn't mean you shouldn't try.  I found a reasonably looking perl
implementation of DH in 110 lines of code or so:
 http://package-import.ubuntu.com/libc/libcrypt-dh-perl/intrepid-upstream/annotate/head%3A/lib/Crypt/DH.pm

I can't vouch for the implementation, but it certainly looks reasonably close
to what I'd expect for a DH implementation.

> You, however, are not solving the general case, so might
> hand roll your own custom solution, perhaps starting
> with a single widely known trusted master public key
> embedded in both client and server, whose secret key,
> which you alone possess, is used to sign durable client
> keys and server keys, which are used in combination with
> transient client keys and transient server keys - the
> skype solution.

Sure, although I personally prefer the ssh approach, granted to avoid a man in
the middle attack you have to personally verify the remote key via a back
channel.  Granted I suspect 99.9% of ssh users just assume the first
connection is safe, certainly getting an alarm if someone else claims to be
the server is a very good thing.

> Now, of course, all the experts say "never hand roll
> your own custom solution", which is true if the experts
> have something ready to roll that actually works. Which,
> for key distribution, they generally do not.
> 
> The particular special case solution will depend on the
> particulars of your particular special case.

Indeed, even generating a random number can be fraught with peril.  Certainly
if you write a python DH implementation (like the 110 lines of Perl at the
URL) certainly let the list know.  I've similar needs and might even be
willing to help depending on the timing and implementation details.