Is that safe to use ramdom.random() for key to encrypt?

[Roy Smith]

In article <mailman.1344.1340205892.4697.python-list at python.org>,
Chris Angelico  <rosuav at gmail.com> wrote:
> Well, for communication it's even easier. Pick up an SSL or SSH
> library and channel everything through that!

+1 on this.  Actually, plus a whole bunch more than 1.  I worked on a
project which had rolled their own communication layer (including
encryption).  The decisions were made (long) before I got there, and
may well have made sense at the time, but in the end it was a mess.  I
can't count how many person-years went into fixing hard-to-replicate
bugs, not to mention lots of customer ill will when things broke at
their sites

The upside is I learned a lot about crypto that I probably would have
never learned otherwise.  That's cool and fun, but not a good
justification for putting it in your product.

> Added bonus of SSL/TLS is that, with many languages/libraries, you
> can write all your code with a simple unencrypted session and test
> it with telnet, and then "turn on" encryption without changing any
> of your code outside of your initialization.

Yup, this is a big win.

There's another consideration.  At some point, some large customer (or
potential customer) may require that all your crypto be FIPS (or
whatever national authority) certified.  If you're using some standard
crypto library, it's a lot easier to drop in a certified replacement
than if you've rolled your own.

> Whatever platform you're targeting, there's a better option than
> writing your own encryption. Guaranteed. Even if it means writing glue
> code to interface to a C library.

What he said.