/dev/random instead of /dev/urandom

[barnabycolby]

Shouldn't s2n use /dev/random instead of /dev/urandom for the drbg entropy source? /dev/urandom does not guarantee quality, if there is not enough entropy available in it's pool then it will still return values, /dev/random however will block until there is enough entropy.

This change would require some code within s2n_get_urandom_data to handle the possible blocking when reading from /dev/random, and some thought would need to be given as to what to do if it does block.

[SalusaSecondus]

With the recent changes (118cfef) to support prediction resistance backed by RDRAND, do you still feel that this is an important change to S2N?

[barnabycolby]

Yes, because the RDRAND instruction is not available on all systems, neither is the prediction resistance. On these systems, if /dev/urandom returned a low quality random number, then the security of s2n would be significantly weakened.

[baldwinmatt]

closing won't fix.

[barnabycolby]

Any more details as to why you won't fix this?

[alexw91]

I believe the issue is that everyone feels confident in trusting /dev/urandom. Have you read http://www.2uo.de/myths-about-urandom/ ? If you have read it, do you have any concerns that aren't presented in that article? Or do you believe any of the arguments presented in that article are incorrect?

[barnabycolby]

I have read it, and it's still undisputed that a theoretical attack exists. It seems that the benefit of urandom not blocking significantly outweighs the impracticality of the attack though. I'm going to go and research this in my own time.