Re^5: Your random numbers are not that random (UtS,L)

[Anonymous Monk]

I ran on the assumption that it is the random number generator failing only for the hash seeding code -- hence downplaying the problem. I have no idea which RNG the actual rand() function uses, but password/session key generation can be made reasonably secure even with a nonfunctional RNG.

To the OP: What sort of results do you get if you run perl -le 'print rand() for 1..10' on the faulty boards? If you run it twice, will the same sequence repeat? What about on the working boards?

[cavac]

but password/session key generation can be made reasonably secure even with a nonfunctional RNG

Really? How? That is a pretty big assumption.

How do you protect against predictably generated keys? Say, if the device does not have a hardware clock (and this one doesn't) and the program is started as part of the startup scripts, you end up with a very predictable set of constraints (process id, system time, memory layout, ...).

While it may take a lot of raw processing power to compute the tables, you may only have to do it once. So, access to a bunch of high performance computers with good GPU's and a week or two of waiting may be all that's needed. Say, a few computers optimized for bitcoin mining. Or an attacker could just rent a botnet for a say or two.

Even if it's only "session keys" that expire after a few minutes. The encrypted data can be stored and decrypted later. With any luck, the session contains a few passwords or other sensitive information that are valid much longer.

You see, there is no "reasonable" security. It either works, or it doesn't.

[BrowserUk]

You see, there is no "reasonable" security. It either works, or it doesn't.

The 6-pin rim lock and 2 deadbolts on my front door can be defeated by a Challenger 2, but given the likely risks, they form "reasonable security".

Overstatement of risk is as damaging as understatement.

[cavac]

You are right, of course.

Problem is, in cryptography there are probably only a handful of people worldwide for each algorithm that can actually tell you which parts of the system you can leave out and while only degrading the encryption product from "secure" to "still reasonable secure". Even a single, small error can lead to "not secure at all".

So, what i meant is, a non-specialist should assume that he/she can only turn the "secure" switch on and off but has probably not the knowledge to tweak it into a point somewhere inbetween.

As Dan Kaminsky said about the Debian SSL desaster (the non-randomness introduced to fix a memory access bug that wasn't one): "You know, it's not a private key if there's only 1 out of 65.000 of them". Youtube Video at 21:00. There is more on Dan's Blog.

[Anonymous Monk]

A very predictable set of constraints and a few KB of salt.