6 ms·

Saving some weight by leaving the airbag out of your car doesn't mean that it going faster is a good thing.

foxfluff 5y ago
So did PCG or xoroshiro leave the airbag out of MCGs or what? Or are you one of those who pretend that there was never any legitimate use case for any non-cryptographic PRNG?
- matthewdgreen 5y ago
  There are perfectly legitimate use case (in a tiny niche area) for non-cryptographic RNGs - however, three points: 1. Non-cryptographic RNGs, should they be incorporated in security-critical applications are dangerous. If you insist on manufacturing poisonous chemicals that look appetizing and say “Kool-Aid” on them, kids are going to drink them. And this is your damned fault. 2. Non-cryptographic RNGs should not be evaluated and improved so as to (appear to provide) security properties. Non-invertability is a security property. Anyone who needs this property probably wants something that has been properly evaluated by experts to provide it. This construction has not been, and it is appropriate to assume that against a sufficiently-motivated adversary it will not provide it. Assuming otherwise is stupid and dangerous. 3. People who can use a non-cryptographic RNG but can’t afford the compute of a full cryptographic RNG are a very small subset of all users with very specific computing limitations. If you must target them with something, you should justify your computing speedup. My proposal is that this type of non-cryptographic RNG should have a name that is not easily confused with safe cryptographic PRNGs. Perhaps “statistical sequence generator”. Moreover, people designing these systems should not be playing with security properties. Do one thing or the other, but not both things badly. The set of people who need fast statistical (but insecure) sequence generators is small. They know who they are and what they need. Stop littering the school yard with poisonous chemicals that say “Kool Aid” in an effort to reach a few hundred laboratory chemists who are perfectly capable of calling you and ordering exactly the ingredients they know they need.
  - foxfluff 5y ago
    I agree on all three points. I might even agree on the proposed name; not that I care too much. All I'm saying is that I'm happy the state of art of fast (but insecure) generators is improving and people have better options than cranky old LCGs or Mersenne Twister (ugh!). I don't know why they brought up non-invertibility. But, at a glance, I see a new RNG that might be at least twice as fast as a comparable variant of PCG while offering similar or better statistical performance. That's exactly the kind of development I like to see.
    - maqp 5y ago
      It's great that insecure fast RNGs are improving, but it's extremely important to be responsible about how they should be promoted. 1. Insecurity needs to be in the name: Make it Insecure<Your RNG Name Here>. This is extremely important. Since the intended use-context is going to be non-security critical, anyway, it's actually good that it states it's insecure. That way you know you're not accidentally using RNG where security properties might cause any bottle-necks. At the same time the misuse resistance of the RNG increases significantly. 2. Make sure this is not default, but something that needs to be imported separately from non-security context, such as module about statistics, simulation etc.
  - deleted 5y ago
    [deleted]
  - adgjlsfhk1 5y ago
    point 1 is just false. some examples where it's perfectly acceptable to use a bad rng in a safety critical system factoring/prime checking algorithms any type of stimulation (eg for drug dosing/particle stimulation) sorting algorithms most graph based algorithms. in short, many real works problems are best solved by random algorithms, but the randomness can be of fairly low quality without causing problems.
    - nmadden 5y ago
      He said security-critical not safety-critical. Security-critical implies an adversarial setting.
jcelerier 5y ago
There's no such thing as "a good thing". There are only goals, security is just a goal among other that not everyone have.
- noiddicle 5y ago
  The problem that we have is that a minority of people realize that not all random implementations are actually fit for purpose for cryptographic security. See CWE-338 for an enumerated list of these things in the wild. I found 300+ examples of CVEs with little effort. Should developers who are writing code that involves cryptography know better? Sure - but they don't. They cut and paste from stackoverflow with horrific results.
  - jcelerier 5y ago
    > Should developers who are writing code that involves cryptography know better? but cryptography is just one small use case of RNGs. Grepping through my home for e.g. random_engine, less than 1% seems to be related to crypto use cases, the bulk are being taken by noise generation for various artistic use cases, games, compilers, schedulers, and tests. Stuff like shuffling a playlist, making particles move in random directions, randomness in paint brushes, etc. If I want to generate a white noise texture for a video game do you think I care more about cryptographically-secureness or the operation not taking 10 seconds for a 4k texture ?

So did PCG or xoroshiro leave the airbag out of MCGs or what? Or are you one of those who pretend that there was never any legitimate use case for any non-cryptographic PRNG?

matthewdgreen 5y ago
There are perfectly legitimate use case (in a tiny niche area) for non-cryptographic RNGs - however, three points: 1. Non-cryptographic RNGs, should they be incorporated in security-critical applications are dangerous. If you insist on manufacturing poisonous chemicals that look appetizing and say “Kool-Aid” on them, kids are going to drink them. And this is your damned fault. 2. Non-cryptographic RNGs should not be evaluated and improved so as to (appear to provide) security properties. Non-invertability is a security property. Anyone who needs this property probably wants something that has been properly evaluated by experts to provide it. This construction has not been, and it is appropriate to assume that against a sufficiently-motivated adversary it will not provide it. Assuming otherwise is stupid and dangerous. 3. People who can use a non-cryptographic RNG but can’t afford the compute of a full cryptographic RNG are a very small subset of all users with very specific computing limitations. If you must target them with something, you should justify your computing speedup. My proposal is that this type of non-cryptographic RNG should have a name that is not easily confused with safe cryptographic PRNGs. Perhaps “statistical sequence generator”. Moreover, people designing these systems should not be playing with security properties. Do one thing or the other, but not both things badly. The set of people who need fast statistical (but insecure) sequence generators is small. They know who they are and what they need. Stop littering the school yard with poisonous chemicals that say “Kool Aid” in an effort to reach a few hundred laboratory chemists who are perfectly capable of calling you and ordering exactly the ingredients they know they need.
- foxfluff 5y ago
  I agree on all three points. I might even agree on the proposed name; not that I care too much. All I'm saying is that I'm happy the state of art of fast (but insecure) generators is improving and people have better options than cranky old LCGs or Mersenne Twister (ugh!). I don't know why they brought up non-invertibility. But, at a glance, I see a new RNG that might be at least twice as fast as a comparable variant of PCG while offering similar or better statistical performance. That's exactly the kind of development I like to see.
  - maqp 5y ago
    It's great that insecure fast RNGs are improving, but it's extremely important to be responsible about how they should be promoted. 1. Insecurity needs to be in the name: Make it Insecure<Your RNG Name Here>. This is extremely important. Since the intended use-context is going to be non-security critical, anyway, it's actually good that it states it's insecure. That way you know you're not accidentally using RNG where security properties might cause any bottle-necks. At the same time the misuse resistance of the RNG increases significantly. 2. Make sure this is not default, but something that needs to be imported separately from non-security context, such as module about statistics, simulation etc.
- deleted 5y ago
  [deleted]
- adgjlsfhk1 5y ago
  point 1 is just false. some examples where it's perfectly acceptable to use a bad rng in a safety critical system factoring/prime checking algorithms any type of stimulation (eg for drug dosing/particle stimulation) sorting algorithms most graph based algorithms. in short, many real works problems are best solved by random algorithms, but the randomness can be of fairly low quality without causing problems.
  - nmadden 5y ago
    He said security-critical not safety-critical. Security-critical implies an adversarial setting.

jcelerier 5y ago

There's no such thing as "a good thing". There are only goals, security is just a goal among other that not everyone have.

noiddicle 5y ago
The problem that we have is that a minority of people realize that not all random implementations are actually fit for purpose for cryptographic security. See CWE-338 for an enumerated list of these things in the wild. I found 300+ examples of CVEs with little effort. Should developers who are writing code that involves cryptography know better? Sure - but they don't. They cut and paste from stackoverflow with horrific results.
- jcelerier 5y ago
  > Should developers who are writing code that involves cryptography know better? but cryptography is just one small use case of RNGs. Grepping through my home for e.g. random_engine, less than 1% seems to be related to crypto use cases, the bulk are being taken by noise generation for various artistic use cases, games, compilers, schedulers, and tests. Stuff like shuffling a playlist, making particles move in random directions, randomness in paint brushes, etc. If I want to generate a white noise texture for a video game do you think I care more about cryptographically-secureness or the operation not taking 10 seconds for a 4k texture ?