I recommend siphash24 [1] for its excellent statistical properties and good performance. It's a light weight, almost cryptographically secure, seeded hash, very popular in hashtable implementations.
Need a PRNG? Use a CSPRNG
41–50 of 105 posts
Re: Need a PRNG? Use a CSPRNG
#42> You can try running this code yourself and see if you get the same answers. This experiment is repeatable.
OpenSUSE:
483 0.305
484 0.293
485 0.283
486 0.275
487 0.3
488 0.302
489 0.304
490 0.274
491 0.274
492 0
493 0.285
494 0
495 0.271
496 0
497 0.289
498 0
499 0.294
500 0
501 0.306
502 0
503 0.31
504 0
505 0.275
506 0
507 0.285
508 0
509 0.289
510 0
511 0.282
512 0
513 0.301
514 0
515 0.266
516 0
517 0.289
518 0
519 0.291
520 0
521 0.309
522 0
523 0.325
524 0
525 0.358
526 0
527 1
528 0
529 0
530 0
531 0
532 0
533 0
534 0
I don't see this with mt19937, but I did see these funny nuggets with unseeded `rand()` on Windows:
255 0.3
256 0
257 0.289
258 0.306
...
511 0.262
512 0
513 0.275Re: Need a PRNG? Use a CSPRNG
#43I'm surprised I'm not seeing mention of the reduced round ChaCha8 version of ChaCha, that's what I'd recommend for Monte Carlo use. It's available in Rust at https://docs.rs/rand_chacha/0.3.1/rand_chacha/struct.ChaCha8... . I recommend seeding it from a high quality random source, but it could be fixed in your source code, generated with `openssl rand -base64 32` or similar.
Re: Need a PRNG? Use a CSPRNG
#44An alternative to the post is to take any PRNG's output and calculate the SHA3 hash of it, then use the hash as the random number. If SHA3 is not available, use AES. In either case, all statistical weaknesses and side-channel attacks will be eliminated. The platform is far more likely to have support for either of those in the system libraries, than a bespoke CSPRNG, which would need to be packaged with your app/game…
The sponge design of SHA-3 makes it a CSPRNG basically. You can keep draining it after you fed the data in.
Re: Need a PRNG? Use a CSPRNG
#45An alternative to the post is to take any PRNG's output and calculate the SHA3 hash of it, then use the hash as the random number. If SHA3 is not available, use AES. In either case, all statistical weaknesses and side-channel attacks will be eliminated. The platform is far more likely to have support for either of those in the system libraries, than a bespoke CSPRNG, which would need to be packaged with your app/game…
That might be convenient so you don’t have to go fishing for 3rd party libraries - which is especially a problem in C/C++. But I expect the result will be much slower than using an optimized csrng like chacha.
Well, ChaCha is actually a hash function. Specifically it was a candidate for SHA3 but was beaten by Keccak in the final spec. Additionally, aes-ctr-128 has the same performance as ChaCha (1.5 GB/s).
All I was trying to illustrate was that in general, pairing a PRNG with a block cipher or hash function is sufficient to create a CSPRNG, and any developers worried about their PRNGs can couple rand() with a readily available cipher/hash in the system libraries. After all the blog is explicit about not requiring a cryptographically secure RNG for most applications.
Re: Need a PRNG? Use a CSPRNG
#46An alternative to the post is to take any PRNG's output and calculate the SHA3 hash of it, then use the hash as the random number. If SHA3 is not available, use AES. In either case, all statistical weaknesses and side-channel attacks will be eliminated. The platform is far more likely to have support for either of those in the system libraries, than a bespoke CSPRNG, which would need to be packaged with your app/game…
The sponge design of SHA-3 makes it a CSPRNG basically. You can keep draining it after you fed the data in.
That's a great poin, even better.
Re: Need a PRNG? Use a CSPRNG
#47This whole discussion seems to be summed up as “premature optimization is the root of all evil, and using anything but a csprng is a premature performance optimization”
There doesn’t seem to be any good non-performance reasons to use a regular prng that I can think of.
Re: Need a PRNG? Use a CSPRNG
#48There are lots of cases where a PRNG is more appropriate than a CSPRNG. Wiping disks is one of them, as the CSPRNG becomes the bottleneck with large arrays. Testing i/o or network throughput is another; you don’t want your algorithm tainting the results. I like the thrust of the article but if you’re going to be particular, you should also be correct. CSPRNGs are not suitable replacements in 100% of cases. Engineerin…
If a predictable PRNG is sufficient for wiping disks, why do we care that the data is random at all? How about writing 0, 1, 2, ..., 255, 0, 1, 2, ... to consecutive bytes? Or -- generate 1 kb of good quality random data, and write the same 1 Kb repeatedly? It's not clear to me what we're trying to achieve in this scenario.
Re: Need a PRNG? Use a CSPRNG
#49Earlier quoted context omitted.
The state of the art in super-fast PRNGs is about 0.3 cycles per byte at the moment. I believe this is done with SIMD versions of the xoroshiro algorithms right now. 0.3 cycles per byte compared to "a few" cycles per byte is an order of magnitude difference in throughput. Here's the comparison from the maintainers of Julia: https://prng.di.unimi.it/#shootout Still, most crypto libraries are designed with extreme perf…
I haven't paid close attention recently but that doesn't seem that far off of performance available via (hardware accelerated) AES? Looking at https://eprint.iacr.org/2018/392.pdf , it seems like: - Intel CPUs can use AESNI to do AES at 0.64 cpb - AMD Zen cores have two AESNI cores and can achieve 0.31 cpb - Vectorized AES instructions (supposed to ship in Ice Lake five years ago, but maybe a casualty of Intel's AVX5…
Yeah, chacha was an odd choice because AES is a lot faster on CPUs with acceleration. Just doing a few AES rounds would be a pretty fast, good PRNG.
Re: Need a PRNG? Use a CSPRNG
#50But if you need a PRNG in a big hurry, an LFSR is probably fine.
https://en.m.wikipedia.org/wiki/Linear-feedback_shift_regist...
I use one on my NES projects that can compute a new 8bit PRNG value in something like 65 cycles