4 ms·

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-cryp

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 are perfectly legitimate use case (in a tiny niche area) for non-cryptographic RNGs - however, three points: no, crypto IS the niche area. The vast majority of random code in existence has absolutely nothing to do with crypto. It's cryptographic use-cases which should be marked specifically.

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 are perfectly legitimate use case (in a tiny niche area) for non-cryptographic RNGs - however, three points: no, crypto IS the niche area. The vast majority of random code in existence has absolutely nothing to do with crypto. It's cryptographic use-cases which should be marked specifically.