3 ms·

While that is true, it would actually be worse bullshit to claim that the “random number generator” generates cryptographically random-enough source material th

by EGreg 3y ago

While that is true, it would actually be worse bullshit to claim that the “random number generator” generates cryptographically random-enough source material that your password can’t be cracked. So maybe ChatGPT is onto something. On the other hand, it could be the cryptographic industry’s bullshit that some computer somewhere using a random number generator at an indeterminate time can be cracked and we should all be hoping for true sources of entropy. tptacek?

inbfour 3y ago
> it would actually be worse bullshit to claim that the “random number generator” generates cryptographically random-enough source material that your password can’t be cracked. We are in agreement. I would argue the threat model of cracking a psuedorandom string of 16 characters would probably want to start with a copy of the rng implementation used, but still the question remains what is the least “bullshit” way to respond? You seem to want critical guidance, a la “INTERCAL as your choice of language may make your code vulnerable”, but INTERCAL was the ask. That’s what the author wanted, and the author left out any explanation for the generator’s intended use, or cryptographic requirements. Rather than appear to be advocating for using this INTERCAL “password generator” for any real world use, my point was that I think the solution the author produced should be a capability of these models. For sake of clarity, it is my opinion that if you want cryptographic security you should use libsodium, but if you want to watch these models flounder use an adhoc rng implemented in INTERCAL.
omnicognate 3y ago
What prevents it from being cryptographically secure? The type/quality of the random numbers will depend on what the INTERCAL implementation uses to choose whether a line will execute according to the probability selected with "%". I don't see how that couldn't trivially be done with a cryptographically secure rng. To know whether it is or not you'd have to look at the compiler implementation.

by EGreg 3y ago

inbfour 3y ago

> it would actually be worse bullshit to claim that the “random number generator” generates cryptographically random-enough source material that your password can’t be cracked. We are in agreement. I would argue the threat model of cracking a psuedorandom string of 16 characters would probably want to start with a copy of the rng implementation used, but still the question remains what is the least “bullshit” way to respond? You seem to want critical guidance, a la “INTERCAL as your choice of language may make your code vulnerable”, but INTERCAL was the ask. That’s what the author wanted, and the author left out any explanation for the generator’s intended use, or cryptographic requirements. Rather than appear to be advocating for using this INTERCAL “password generator” for any real world use, my point was that I think the solution the author produced should be a capability of these models. For sake of clarity, it is my opinion that if you want cryptographic security you should use libsodium, but if you want to watch these models flounder use an adhoc rng implemented in INTERCAL.

omnicognate 3y ago

What prevents it from being cryptographically secure? The type/quality of the random numbers will depend on what the INTERCAL implementation uses to choose whether a line will execute according to the probability selected with "%". I don't see how that couldn't trivially be done with a cryptographically secure rng. To know whether it is or not you'd have to look at the compiler implementation.