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

[Jon Clements]

On Sun, 17 Jun 2012 23:17:37 +0000, Steven D'Aprano wrote:

> On Mon, 18 Jun 2012 08:41:57 +1000, Chris Angelico wrote:
> 
>> On Mon, Jun 18, 2012 at 3:06 AM, Rafael Durán Castañeda
>> <rafadurancastaneda at gmail.com> wrote:
>>> The language Python includes a SystemRandom class that obtains
>>> cryptographic grade random bits from /dev/urandom on a Unix-like
>>> system, including Linux and Mac OS X, while on Windows it uses
>>> CryptGenRandom.
>> 
>> /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
> 
> 
>>> Do you think is secure enough for token generation? (40 chars long
>>> tokens are used for password reset links in a website, there isn't any
>>> special security concern for the web).
>> 
>> ... 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.
> 
> 
> --
> Steven

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]