> Time and time again, ignorant and lazy human beings are the enablers of security breaches. You can blame humans all you want, but if systems aren't designed with such human factors in mind, they simply won't work in the real world.
This same statement, however, underlies my argument in the other direction: that ignorant and lazy human beings build systems that don't have entropy pools that fill fast enough at boot to make /dev/urandom secure for the things they are running there. If the software were using /dev/random instead, it defends against the systems integrator making this mistake by blocking until the system has enough entropy.
Now, it also will potentially block later as well, which sucks: however, this is going to happen to a subset of users building systems under heavy load. Rather than letting the user run rampant, profiling the code, finding /dev/random to be the bottleneck, and replacing it with a file of hardcoded "random numbers", how about giving the user a setting "if you are reasonably confident you are not using this during boot before the entropy pool is ready for /dev/urandom, turn on this non-default setting and the software will never block"?
Under the assumption, however, that this somehow has to be a black/white "choose one, only one, no options, no workarounds" issue, defending against the ill-informed system integrators seems like a much more reasonable position than defending against the downright-idiotic system integrators. The downright-idiotic system integrators probably also left a bunch of other holes in their systems: let's help out the ill-informed ones a little, and use defaults that are more difficult to break.
> > Look: that just isn't always possible. I say this not from theory, but from the trenches of information security.
> I'd have to say that you're confusing "not possible" with "hasn't been done yet."
The argument in that paragraph involved an Android device. If my Android device doesn't sufficient entropy when I go to run the software I downloaded from the Android Market at the moment that software attempts to generate an encryption key I need, it is "not possible" for any of 1) me (most devices have locked bootloaders), 2) the developer of the app, 3) the developer of any cryptography libraries the developer used, to fix the problem.
> The security field needs to start using some of the same pragmatic strategies the NTSB uses to prevent plane crashes. We can't just stand around wishing programmers know more about crypto and security. We need to put measures in place that actually work.
I agree: how about someone makes it so that Linux itself has the FreeBSD behavior of blocking /dev/urandom until the entropy pool has reached the critical mass required to make its randomness generation secure? ;P Alternatively, how about someone gets it into all the common init daemons to read enough data from /dev/random at boot to guarantee work around this kernel limitation? It sounds like everyone is just asking for mistakes by encouraging people to write software that uses /dev/urandom to run on systems that have a known-limitation in the usage of /dev/urandom.
It sounds like everyone is just asking for mistakes by encouraging people...
I realize that I'm preaching to the choir by writing this, but it's for 3rd party readers: What if the airline industry just encouraged people to try and do the right thing, then stood around shaking their heads when it turned out lots of pilots, mechanics, and companies didn't? Well, there would be a lot more accidents.
That's where we are as an industry and a society, with regards to security.
Are the accelorometers, touch screen input events and other data being fed into the random pool from system boot (or from when the system enables them in the case of sensors). What about SoC features (hardware RNGs) that use ambient temperature noise and other factors?
This same statement, however, underlies my argument in the other direction: that ignorant and lazy human beings build systems that don't have entropy pools that fill fast enough at boot to make /dev/urandom secure for the things they are running there. If the software were using /dev/random instead, it defends against the systems integrator making this mistake by blocking until the system has enough entropy.
Now, it also will potentially block later as well, which sucks: however, this is going to happen to a subset of users building systems under heavy load. Rather than letting the user run rampant, profiling the code, finding /dev/random to be the bottleneck, and replacing it with a file of hardcoded "random numbers", how about giving the user a setting "if you are reasonably confident you are not using this during boot before the entropy pool is ready for /dev/urandom, turn on this non-default setting and the software will never block"?
Under the assumption, however, that this somehow has to be a black/white "choose one, only one, no options, no workarounds" issue, defending against the ill-informed system integrators seems like a much more reasonable position than defending against the downright-idiotic system integrators. The downright-idiotic system integrators probably also left a bunch of other holes in their systems: let's help out the ill-informed ones a little, and use defaults that are more difficult to break.
> > Look: that just isn't always possible. I say this not from theory, but from the trenches of information security.
> I'd have to say that you're confusing "not possible" with "hasn't been done yet."
The argument in that paragraph involved an Android device. If my Android device doesn't sufficient entropy when I go to run the software I downloaded from the Android Market at the moment that software attempts to generate an encryption key I need, it is "not possible" for any of 1) me (most devices have locked bootloaders), 2) the developer of the app, 3) the developer of any cryptography libraries the developer used, to fix the problem.
> The security field needs to start using some of the same pragmatic strategies the NTSB uses to prevent plane crashes. We can't just stand around wishing programmers know more about crypto and security. We need to put measures in place that actually work.
I agree: how about someone makes it so that Linux itself has the FreeBSD behavior of blocking /dev/urandom until the entropy pool has reached the critical mass required to make its randomness generation secure? ;P Alternatively, how about someone gets it into all the common init daemons to read enough data from /dev/random at boot to guarantee work around this kernel limitation? It sounds like everyone is just asking for mistakes by encouraging people to write software that uses /dev/urandom to run on systems that have a known-limitation in the usage of /dev/urandom.