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

[Yesterday Paid]

I'm making cipher program with random.seed(), random.random() as the
key table of encryption.
I'm not good at security things and don't know much about the
algorithm used by random module.

Is it really random or safe enough to keep my data safe?

 

[Chris Angelico]

I'm making cipher program with random.seed(), random.random() as the
key table of encryption.
I'm not good at security things and don't know much about the
algorithm used by random module.

For security, you don't want any algorithm, you want something like
/dev/random (on Unix-like platforms).

I'm pretty sure Python includes crypto facilities. Unless it (most
oddly) lacks these batteries, I would recommend using one of them
instead.

ChrisA

 

[Paul Rubin]

I'm making cipher program with random.seed(), random.random() as the
key table of encryption...
Is it really random or safe enough to keep my data safe?

No. Use os.urandom instead.

 

[Jon Clements]

For security, you don't want any algorithm, you want something like
/dev/random (on Unix-like platforms).

I'm pretty sure Python includes crypto facilities. Unless it (most
oddly) lacks these batteries, I would recommend using one of them
instead.

ChrisA

Cryptography is a complex subject - I've had the (mis)fortune to study it
briefly.

Whatever you do - *do not* attempt to write your own algorithm.

Python includes hashlib (forms of SHA and MD5) and uuid modules, but I
take it a symmetric or possibly public/private key system is required -
depending on what you want to secure, where it's stored and who needs
access.

I generally find a separate partition with an encrypted file-system
(which is fairly straight forward on *nix systems or I think there's a
product out there that works with Windows), is a lot easier and puts the
load on the filesystem/OS instead of having to be handled in your
application is a lot simpler.

Jon

 

[Steven D'Aprano]

I'm making cipher program with random.seed(), random.random() as the key
table of encryption.
I'm not good at security things and don't know much about the algorithm
used by random module.

Start by reading the Fine Manual:

http://docs.python.org/library/random.html

which answers your question:

"it is not suitable for all purposes, and is completely
unsuitable for cryptographic purposes."


Please don't write yet another broken cipher program that doesn't work.
Use a proper one that has been mathematically analysed by professionals.
I don't mean to cast aspersions on you, but any fool can write a cipher
program that *they* can't break themselves. It takes many years of study
to design a cipher that professionals can't break.

At the very least, start with PyCrypto.

http://pypi.python.org/pypi/pycrypto

If all you want is to play around obfuscating data, you might be
interested in my toy encryption module:

http://pypi.python.org/pypi/obfuscate/

(which is also completely unsuitable for cryptographic purposes, but may
be useful if you have some interest in the history of cryptography).

Is it really random or safe enough to keep my data safe?

Safe from what? What is your threat model? Are you worried about your
little sister reading your diary? Or the NSA discovering your plans to
assassinate the President? Or something in between?

Python's random module is not cryptographically strong, which means that
it will probably take an organisation like the NSA, MI5, ASIO, Mossad,
etc. about 10 or 20 minutes to crack your password. But your little
sister will probably take a hundred million years to guess it.

 

[Chris Angelico]

Safe from what? What is your threat model? Are you worried about your
little sister reading your diary? Or the NSA discovering your plans to
assassinate the President? Or something in between?

Python's random module is not cryptographically strong, which means that
it will probably take an organisation like the NSA, MI5, ASIO, Mossad,
etc. about 10 or 20 minutes to crack your password. But your little
sister will probably take a hundred million years to guess it.

Your little sister would quite possibly be kept off by rot13, which
everyone knows isn't cryptographically secure. All it takes is making
something look encrypted and most people won't bother to try (plus
it's the whole "this isn't public kthx" thing, which many people will
respect).

Of course, if you're just trying to fool the BOFH's technical manager,
it's even easier.

http://bofh.ch/newbofh/bofh4oct.html

ChrisA

 

[Steven D'Aprano]

/dev/urandom isn't actually cryptographically secure; it promises not to
block, even if it has insufficient entropy. But in your instance...

Correct. /dev/random is meant to be used for long-lasting
cryptographically-significant uses, such as keys. urandom is not.

http://en.wikipedia.org/wiki//dev/random

... it probably is fine, since password reset tokens don't need to be as
secure as encryption keys (if anyone _does_ figure out how to predict
your password resets, all they'll be able to do is lock people out of
their accounts one by one, not snoop on them all unbeknownst, and you'll
be able to see log entries showing the resets - you DO log them,
right?). In fact, you could probably get away with something pretty
trivial there, like a SHA1 of the current timestamp, the user name, and
the user's current password hash. The chances that anybody would be able
to exploit that are fairly low, given that you're not a bank or other
high-profile target.

If I were an identity thief, I would *love* low-profile targets. Even
though the payoff would be reduced, the cost would be reduced even more:

- they tend to be complacent, even more so than high-profile targets;

- they tend to be smaller, with fewer resources for security;

- mandatory disclosure laws tend not to apply to them;

- they don't tend to have the resources to look for anomalous usage
patterns, if they even cared enough to want to.


If there was a Facebook-like website that wasn't Facebook[1], but still
with multiple tens of thousands of users, I reckon a cracker who didn't
vandalise people's accounts could steal private data from it for *years*
before anyone noticed, and months or years more before they did something
about it.



[1] And very likely a Facebook-like website that *was* Facebook. I reckon
the odds are about 50:50 that FB would prefer to keep a breach secret
than risk the bad publicity by fixing it.

 

[Paul Rubin]

Correct. /dev/random is meant to be used for long-lasting
cryptographically-significant uses, such as keys. urandom is not.

They are both ill-advised if you're doing anything really serious. In
practice if enough entropy has been in the system to make a key with
/dev/random, then urandom should also be ok. Unfortunately the sensible
interface is missing: block until there's enough entropy, then generate
data cryptographically, folding in new entropy when it's available.

http://web.archive.org/web/20081003041432/http://www.pinkas.net/PAPERS/gpr06.pdf
has gory details of how random/urandom work.

If you're really paranoid, get one of these: http://www.entropykey.co.uk/

 

[Jon Clements]

/dev/urandom isn't actually cryptographically secure; it promises not
to block, even if it has insufficient entropy. But in your instance...

Correct. /dev/random is meant to be used for long-lasting
cryptographically-significant uses, such as keys. urandom is not.

http://en.wikipedia.org/wiki//dev/random

... it probably is fine, since password reset tokens don't need to be
as secure as encryption keys (if anyone _does_ figure out how to
predict your password resets, all they'll be able to do is lock people
out of their accounts one by one, not snoop on them all unbeknownst,
and you'll be able to see log entries showing the resets - you DO log
them, right?). In fact, you could probably get away with something
pretty trivial there, like a SHA1 of the current timestamp, the user
name, and the user's current password hash. The chances that anybody
would be able to exploit that are fairly low, given that you're not a
bank or other high-profile target.

If I were an identity thief, I would *love* low-profile targets. Even
though the payoff would be reduced, the cost would be reduced even more:

- they tend to be complacent, even more so than high-profile targets;

- they tend to be smaller, with fewer resources for security;

- mandatory disclosure laws tend not to apply to them;

- they don't tend to have the resources to look for anomalous usage
patterns, if they even cared enough to want to.


If there was a Facebook-like website that wasn't Facebook[1], but still
with multiple tens of thousands of users, I reckon a cracker who didn't
vandalise people's accounts could steal private data from it for *years*
before anyone noticed, and months or years more before they did
something about it.



[1] And very likely a Facebook-like website that *was* Facebook. I
reckon the odds are about 50:50 that FB would prefer to keep a breach
secret than risk the bad publicity by fixing it.

I'm reminded of:

http://xkcd.com/936/
http://xkcd.com/792/

There's also one where it's pointed out it's easier to brute force a
person who has the code, than brute force the computer. [but can't find
that one at the moment]

 

[Andrew Berg]

I'm reminded of:

http://xkcd.com/936/
http://xkcd.com/792/

There's also one where it's pointed out it's easier to brute force a
person who has the code, than brute force the computer. [but can't find
that one at the moment]

http://xkcd.com/538/

 

[Thomas Rachel]

Am 18.06.2012 01:48 schrieb Paul Rubin:

They are both ill-advised if you're doing anything really serious.
Hm?


In practice if enough entropy has been in the system to make a key with
/dev/random, then urandom should also be ok.
Right.


Unfortunately the sensible
interface is missing: block until there's enough entropy, then generate
data cryptographically, folding in new entropy when it's available.

What am I missing? You exactly describe /dev/random's interface.


Thomas

 

[elvis-85496]

Whatever you do - *do not* attempt to write your own algorithm.

very true

I generally find a separate partition with an encrypted file-system
(which is fairly straight forward on *nix systems or I think there's a
product out there that works with Windows), is a lot easier and puts the
load on the filesystem/OS instead of having to be handled in your
application is a lot simpler.

That assumes he is doing storage rather than communication.

 

[Chris Angelico]

That assumes he is doing storage rather than communication.

Well, for communication it's even easier. Pick up an SSL or SSH
library and channel everything through that! 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.

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.

ChrisA

 

[D'Arcy Cain]

very true

As "they" say, random number generation is too important to be left
to chance.

 

[Roy Smith]

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.

 

[Paul Rudin]

very true

If everyone took that advice then we'd have a problem....