7 ms·

It's also a good idea to give safer things shorter names. So make random() a CSPRNG (and an alias for SecureRandom() for people who want to be explicit) while

by zrm 6y ago

It's also a good idea to give safer things shorter names. So make random() a CSPRNG (and an alias for SecureRandom() for people who want to be explicit) while InsecureFastRandom() is just what it says and has no other name. Then if you really need performance over unpredictability, it's there, but nobody is confused about what they're getting. And lazy people who don't like to type or pay close attention get the safe one.

cogman10 6y ago
That's be my preference. random() should be the most universally applicable random which includes making it as secure as possible. Non-universally applicable randoms should be named accordingly.
- njharman 6y ago
  Most simulations, games, everything that isn't generating cryptography does not need security in it's random. For most domains secure random is a niche, not universally applicable.
  - epanchin 6y ago
    And one would hope secure devs know which random to use, whereas gaming devs have no reason to know.
    - josephg 6y ago
      Look up “password generator” or similar terms on npm and take a look at how the packages you find generate random numbers. I did this ~5 years ago and it took until the second page of results before I found any packages that used a crypto-secure rng.
      - esrauch 6y ago
        Even that seems unlikely to be problematic for anything short of literally constant seeds AND a generator becoming extremely popular. The vast majority of people reuse low-entropy passwords, figuring out what password generator someone used would be a much higher bar than figuring out passwords, and just knowing the insecure generator wouldnt reduce the entropy by that much. Actually, a password generator on GitHub that generates the password that is literally just seconds-since-1970 would still be a good generator for almost all use cases.
        fanf2 6y ago
        This is extremely bad advice. It is shamefully unethical to encourage people to harm their security in this way.
        esrauch 6y ago
        Can you explain more? I genuinely don't see any plausible threat model that a user running an Math.random() based custom algorithm password generator would be susceptible to, but the same algorithm using SecureRandom one is not. Both cases are so drastically better than manually thinking up a password that it's not even close. I think if there's any gap it would be wrong roll your own password generator at all and you only use ones authored by security experts: just using SecureRandom instead of Random isn't going to somehow magically guarantee you didn't mess up another way and write a low-entropy password generator.
      - bigiain 6y ago
        Looking for crypto secure code by searching on npm? :facepalm: Seriously.
      - ThePadawan 6y ago
        I was trying to generate random string identifiers to make some element ids unique and took the most popular library, which was accidentally crypto levels of secure: https://blog.prat.ch/2020/11/10/randomstring-bundle-size https://blog.prat.ch/2020/11/10/randomstring-bundle-size
  - tedunangst 6y ago
    So a simple linear generator is fine for an online poker game?
    - btilly 6y ago
      The claim that most uses of random() are not in places where cryptographic security is needed is not in conflict with any list of examples where it is needed. Here are the last several times I saw random() used. Seeding a neural network for a Coursera course. Not only do you need to call random() a bunch of times, but the ability to set a seed and get deterministic results makes grading of the results massively easier. Creating simulation data used for integration tests on a piece of software. Picking a few random numbers that I used in an explanation of an answer. Of course the plural of anecdote is not data. However in my corner of the world it is very rare to need cryptographically secure anything. And when I do, I know better than to code it myself. But it is common to need a lot of cheap numbers in a hurry.
      - wolf550e 6y ago
        chacha8 (chacha20 but with fewer rounds) seeded with either a deterministic seed or from /dev/urandom (depending on what you need) is a perfectly fine PRNG, and should run at 4 GB/sec on a single core, which is plenty. Only 7 rounds of chacha are cryptographically broken, so chacha20 has excessive security margin. Using 8 rounds of that everywhere you use random today (and not a CSPRING) should be a no-brainer, I guess. On hardware with AESNI (like all x86 for the last 10 years), a reduced round AES-CTR should be very fast and also string enough for the cases when you don't need a CSPRING. Full AES-128 outputs 4.7GB/sec on my laptop, recent chips have better AES throughput.
    - Sohcahtoa82 6y ago
      Well of course an online poker game should be using a CSPRNG. The parent comment said "Most simulations, games ...". Most. Not all. I think it's pretty obvious that Poker would not be included a statement of "Most". The real litmus test is the question of "What happens if a malicious actor is able to predict the random numbers?"
  - SomeCallMeTim 6y ago
    Actually, in my experience using the default random implementation in games: * It's not fast enough. * It has patterns that can be seen if you are using it to, for instance, generate 2d noise. So for games you'd typically use, say, the Mersenne Twister [1], which is faster (amortized) and is distributed evenly across 623 dimensions. [2] It's not cryptographic, but it's far better for games. If you're not going to have a crypto default random, better to at least have a really good and really fast one. [1] https://en.wikipedia.org/wiki/Mersenne_twister https://en.wikipedia.org/wiki/Mersenne_twister [2] http://www.math.sci.hiroshima-u.ac.jp/m-mat/MT/ARTICLES/mt.pdf http://www.math.sci.hiroshima-u.ac.jp/m-mat/MT/ARTICLES/mt.p...
    - patrec 6y ago
      Mersenne Twister is the MD5 of random number generators: it's neither secure nor fast (and unlikely md5 not space-efficient, or simple to implement either). You can have something that has better randomness, runs several times faster, uses less space and has a much more compact and simple implementation. So given that Mersenne Twister sucks in pretty much every possible way other than having a catchy name, likely the sole source of its continued popularity, its probably not a good choice for replacing some "default" random number generator with something better.
      - MauranKilom 6y ago
        > You can have something that has better randomness, runs several times faster, uses less space and has a much more compact and simple implementation. Could you share at least one example of such a generator? Most of these aspects are trivial to improve on, but having "better randomness" on top is quite the bar.
        ChrisLomont 6y ago
        The PCG class of PRNGs are very good, and have a zillion tunable versions to suit every need. https://www.pcg-random.org/index.html https://www.pcg-random.org/index.html
        6y ago
- bigiain 6y ago
  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?
bigiain 6y ago
Then we’ll end up with a csprng getting used in a tight loop iterating over every pixel in a raytracer... “Lazy people who don’t want to type” are not the sort of people I want writing the code I might use or interact with that requires cryptographically secure random numbers...
- zrm 6y ago
  > Then we’ll end up with a csprng getting used in a tight loop iterating over every pixel in a raytracer... Which will then be conspicuous enough for the developer to notice and fix it. > “Lazy people who don’t want to type” are not the sort of people I want writing the code I might use or interact with that requires cryptographically secure random numbers... Bad news though.

by zrm 6y ago

cogman10 6y ago

That's be my preference. random() should be the most universally applicable random which includes making it as secure as possible. Non-universally applicable randoms should be named accordingly.

njharman 6y ago
Most simulations, games, everything that isn't generating cryptography does not need security in it's random. For most domains secure random is a niche, not universally applicable.
- epanchin 6y ago
  And one would hope secure devs know which random to use, whereas gaming devs have no reason to know.
  - josephg 6y ago
    Look up “password generator” or similar terms on npm and take a look at how the packages you find generate random numbers. I did this ~5 years ago and it took until the second page of results before I found any packages that used a crypto-secure rng.
    - esrauch 6y ago
      Even that seems unlikely to be problematic for anything short of literally constant seeds AND a generator becoming extremely popular. The vast majority of people reuse low-entropy passwords, figuring out what password generator someone used would be a much higher bar than figuring out passwords, and just knowing the insecure generator wouldnt reduce the entropy by that much. Actually, a password generator on GitHub that generates the password that is literally just seconds-since-1970 would still be a good generator for almost all use cases.
      - fanf2 6y ago
        This is extremely bad advice. It is shamefully unethical to encourage people to harm their security in this way.
        esrauch 6y ago
        Can you explain more? I genuinely don't see any plausible threat model that a user running an Math.random() based custom algorithm password generator would be susceptible to, but the same algorithm using SecureRandom one is not. Both cases are so drastically better than manually thinking up a password that it's not even close. I think if there's any gap it would be wrong roll your own password generator at all and you only use ones authored by security experts: just using SecureRandom instead of Random isn't going to somehow magically guarantee you didn't mess up another way and write a low-entropy password generator.
    - bigiain 6y ago
      Looking for crypto secure code by searching on npm? :facepalm: Seriously.
    - ThePadawan 6y ago
      I was trying to generate random string identifiers to make some element ids unique and took the most popular library, which was accidentally crypto levels of secure: https://blog.prat.ch/2020/11/10/randomstring-bundle-size https://blog.prat.ch/2020/11/10/randomstring-bundle-size
- tedunangst 6y ago
  So a simple linear generator is fine for an online poker game?
  - btilly 6y ago
    The claim that most uses of random() are not in places where cryptographic security is needed is not in conflict with any list of examples where it is needed. Here are the last several times I saw random() used. Seeding a neural network for a Coursera course. Not only do you need to call random() a bunch of times, but the ability to set a seed and get deterministic results makes grading of the results massively easier. Creating simulation data used for integration tests on a piece of software. Picking a few random numbers that I used in an explanation of an answer. Of course the plural of anecdote is not data. However in my corner of the world it is very rare to need cryptographically secure anything. And when I do, I know better than to code it myself. But it is common to need a lot of cheap numbers in a hurry.
    - wolf550e 6y ago
      chacha8 (chacha20 but with fewer rounds) seeded with either a deterministic seed or from /dev/urandom (depending on what you need) is a perfectly fine PRNG, and should run at 4 GB/sec on a single core, which is plenty. Only 7 rounds of chacha are cryptographically broken, so chacha20 has excessive security margin. Using 8 rounds of that everywhere you use random today (and not a CSPRING) should be a no-brainer, I guess. On hardware with AESNI (like all x86 for the last 10 years), a reduced round AES-CTR should be very fast and also string enough for the cases when you don't need a CSPRING. Full AES-128 outputs 4.7GB/sec on my laptop, recent chips have better AES throughput.
  - Sohcahtoa82 6y ago
    Well of course an online poker game should be using a CSPRNG. The parent comment said "Most simulations, games ...". Most. Not all. I think it's pretty obvious that Poker would not be included a statement of "Most". The real litmus test is the question of "What happens if a malicious actor is able to predict the random numbers?"
- SomeCallMeTim 6y ago
  Actually, in my experience using the default random implementation in games: * It's not fast enough. * It has patterns that can be seen if you are using it to, for instance, generate 2d noise. So for games you'd typically use, say, the Mersenne Twister [1], which is faster (amortized) and is distributed evenly across 623 dimensions. [2] It's not cryptographic, but it's far better for games. If you're not going to have a crypto default random, better to at least have a really good and really fast one. [1] https://en.wikipedia.org/wiki/Mersenne_twister https://en.wikipedia.org/wiki/Mersenne_twister [2] http://www.math.sci.hiroshima-u.ac.jp/m-mat/MT/ARTICLES/mt.pdf http://www.math.sci.hiroshima-u.ac.jp/m-mat/MT/ARTICLES/mt.p...
  - patrec 6y ago
    Mersenne Twister is the MD5 of random number generators: it's neither secure nor fast (and unlikely md5 not space-efficient, or simple to implement either). You can have something that has better randomness, runs several times faster, uses less space and has a much more compact and simple implementation. So given that Mersenne Twister sucks in pretty much every possible way other than having a catchy name, likely the sole source of its continued popularity, its probably not a good choice for replacing some "default" random number generator with something better.
    - MauranKilom 6y ago
      > You can have something that has better randomness, runs several times faster, uses less space and has a much more compact and simple implementation. Could you share at least one example of such a generator? Most of these aspects are trivial to improve on, but having "better randomness" on top is quite the bar.
      - ChrisLomont 6y ago
        The PCG class of PRNGs are very good, and have a zillion tunable versions to suit every need. https://www.pcg-random.org/index.html https://www.pcg-random.org/index.html
      - 6y ago
bigiain 6y ago
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?

bigiain 6y ago

Then we’ll end up with a csprng getting used in a tight loop iterating over every pixel in a raytracer... “Lazy people who don’t want to type” are not the sort of people I want writing the code I might use or interact with that requires cryptographically secure random numbers...

zrm 6y ago
> Then we’ll end up with a csprng getting used in a tight loop iterating over every pixel in a raytracer... Which will then be conspicuous enough for the developer to notice and fix it. > “Lazy people who don’t want to type” are not the sort of people I want writing the code I might use or interact with that requires cryptographically secure random numbers... Bad news though.