11–20 of 54 posts
Xorshift128+ is not a cryptographic rng though, so at least this isn't a cryptographic attack... Should programming languages use cryptographic rngs like a ChaCha20 based one in their standard libraries to stop accidental use of non cryptographic rngs for cryptographic purposes? But that comes at the cost of speed
Xorshift128+ is not a cryptographic rng though, so at least this isn't a cryptographic attack... Should programming languages use cryptographic rngs like a ChaCha20 based one in their standard libraries to stop accidental use of non cryptographic rngs for cryptographic purposes? But that comes at the cost of speed
For example: Math.RandomNotCrypto()
When someone uses that in production for cryptographic purposes (and, yes someone is going to do that), they have to wear a dunce cap to the office for a month.
Xorshift128+ is not a cryptographic rng though, so at least this isn't a cryptographic attack... Should programming languages use cryptographic rngs like a ChaCha20 based one in their standard libraries to stop accidental use of non cryptographic rngs for cryptographic purposes? But that comes at the cost of speed
They settled on 8 rounds of ChaCha with 300 bytes of internal state to amortize the latency. The end result is something only 1.5-2x slower than (their particular flavor of) PCG [1]. It was deemed good enough to become the default.
Xorshift128+ is not a cryptographic rng though, so at least this isn't a cryptographic attack... Should programming languages use cryptographic rngs like a ChaCha20 based one in their standard libraries to stop accidental use of non cryptographic rngs for cryptographic purposes? But that comes at the cost of speed
Xorshift128+ is not a cryptographic rng though, so at least this isn't a cryptographic attack... Should programming languages use cryptographic rngs like a ChaCha20 based one in their standard libraries to stop accidental use of non cryptographic rngs for cryptographic purposes? But that comes at the cost of speed
I think some naming conventions could go a long way. If you want to import `fast_unsafe_random`, you might think twice.
The challenge is things that don't _obviously_ need cryptographically secure generators. For example, do you need a secure generator for the seed of a hash table, or a sorting algorithm? (For those that do use a seed). Some will argue that yes, this is important. Until a few years ago, the hash tables used static hash algorithms without any randomization, but "hash flooding" changed that. I think that nowadays, still many hash table implementations don't use secure generators.
Then, there's secure and insecure hash functions. Secure hash functions like SHA-256 are (compared to non-secure functions) specially slow for short keys. There are "somewhat" secure hash function algorithms like SipHash that can be used for this purpose.
Earlier quoted context omitted.
I think some naming conventions could go a long way. If you want to import `fast_unsafe_random`, you might think twice.
I agree, why would you slow down things for everybody if it's only a problem for cryptographic purposes. Xorshift128+ etc are around 10 to 30 times faster than ChaCha20. The challenge is things that don't _obviously_ need cryptographically secure generators. For example, do you need a secure generator for the seed of a hash table, or a sorting algorithm? (For those that do use a seed). Some will argue that yes, this…
It'll never happen in Go though! They're over a decade committed to this library shape.
I have recently replaced Lua's random for this implemetation https://nullonerror.org/2025/08/02/replacing-lua-s-math-rand...
Whenever we deployed new nginx configs, those servers would roll out and restart, getting _similar_ time() results in the seed. But the individual nginx workers? Their seeds were nearly identical. Not every call to the PRNG was meant for UUIDs, but enough were that disaster was inevitable.
The solution is to use a library that leverages libuuid (via ffi or otherwise). A "native lua" implementation is always going to miss the entropy sources available in your server and generate clashes if it's seeded with time(). (eg https://github.com/Kong/lua-uuid, https://github.com/bungle/lua-resty-uuid)
I have recently replaced Lua's random for this implemetation https://nullonerror.org/2025/08/02/replacing-lua-s-math-rand...
A word of caution. A few years ago we had a production impact event where customers were getting identical cookies (and so started seeing each others sessions). When I took a look at the code, what I found was that they were doing something very like your code - using a time() based seed and an PRNG. Whenever we deployed new nginx configs, those servers would roll out and restart, getting _similar_ time() results in…
I have recently replaced Lua's random for this implemetation https://nullonerror.org/2025/08/02/replacing-lua-s-math-rand...
A word of caution. A few years ago we had a production impact event where customers were getting identical cookies (and so started seeing each others sessions). When I took a look at the code, what I found was that they were doing something very like your code - using a time() based seed and an PRNG. Whenever we deployed new nginx configs, those servers would roll out and restart, getting _similar_ time() results in…
Just FYI I only use this on a hidden n' seek game engine, so it is fine.
Earlier quoted context omitted.
I agree, why would you slow down things for everybody if it's only a problem for cryptographic purposes. Xorshift128+ etc are around 10 to 30 times faster than ChaCha20. The challenge is things that don't _obviously_ need cryptographically secure generators. For example, do you need a secure generator for the seed of a hash table, or a sorting algorithm? (For those that do use a seed). Some will argue that yes, this…
I think people overthink this, and we should just have a library standard full-strength CSPRNG, and then people with fussy fast-randomness needs (Monte Carlo or whatever) can just pull in libraries. "Don't need secure random and can't use it " is a very niche problem space. It'll never happen in Go though! They're over a decade committed to this library shape.