4 ms·

I completely disagree here. I’d bet a lot of money that the number of times random() is used in a non cryptographic context is many orders of magnitude higher

I completely disagree here. I’d bet a lot of money that the number of times random() is used in a non cryptographic context is many orders of magnitude higher than the use of random numbers in crypto code. That make non crypto use “the most universally applicable” case. I would also agree that “non universally applicable random” such as those used in crypto code should be named accordingly. Which they are. Secure_random() is the right choice for the vanishingly small number of developers writing crypto code. random() is the right name for pretty much everybody except those who need to know a lot of other crypto-specific other things as well. They can’t use random() the same way the cant use non-constant-time comparisons and algorithms that leak side channels via power monitoring or cache hitrates. Fixing random() and letting people who don’t know they should have been calling secure_random() write code in niches they don’t know enough to get everything else right, is without doubt going to end up with way more code that is not “as secure as possible” even if it happens to use secure random numbers.

cogman10 6y ago
Why put security second? The thing is, if you need random numbers fast, then profiling will tell you "Opps, used random() when I should have used fast_random()". That's an easy change to make that'd show up in profiling if performance were an issue. If random() never comes up in profiling, why care that you are getting the secure version? The danger of missing "secure_random()" is that it creates a security vulnerability (Potentially leading to loss of money, information, etc). The danger of going the "fast_random()" route is that your application will run slower potentially leading to a dev needing to spend time to swap in "fast_random()" for "random()". That, to me, doesn't seem like a major problem or risk. Programmers are notoriously bad at predicting when something will end up being a performance issue. So why preoptimize because we assume most people want/need speed?

cogman10 6y ago

Why put security second? The thing is, if you need random numbers fast, then profiling will tell you "Opps, used random() when I should have used fast_random()". That's an easy change to make that'd show up in profiling if performance were an issue. If random() never comes up in profiling, why care that you are getting the secure version? The danger of missing "secure_random()" is that it creates a security vulnerability (Potentially leading to loss of money, information, etc). The danger of going the "fast_random()" route is that your application will run slower potentially leading to a dev needing to spend time to swap in "fast_random()" for "random()". That, to me, doesn't seem like a major problem or risk. Programmers are notoriously bad at predicting when something will end up being a performance issue. So why preoptimize because we assume most people want/need speed?