I've been working on an experimental PRNG that combines ChaCha20 with a classical k-wise independent construction over a Galois field.

GF stands for Galois field, also called a finite field. In this case GF(2^64) has 2^64 elements that can be represented by 64-bit words; addition in the field is simply XOR. I'll just use GF below.

For 64-bit output position i, the construction is basically

R(i) = ChaCha20(K, i) XOR P(i)

where P is a random degree-511 polynomial over GF(2^64).

With the full 4096-byte GF coefficient seed sampled uniformly, any selection of up to 512 distinct 64-bit output positions is exactly jointly uniform.

There is a fairly sharp contrast with ChaCha20 alone: with a fixed/public stream ID, ChaCha20 has a 256-bit key space, so exact 5-wise independence of 64-bit output words is already information-theoretically impossible. Five 64-bit words have 2^320 possible joint values, while there are only 2^256 keyed ChaCha20 streams.

So the point isn't that the output is somehow "more random than ChaCha20". The idea is to add an exact finite distribution property that ChaCha20 cannot have, while retaining ChaCha20 as the computational pseudorandom component.

The GF part is deliberately algebraic. Beyond 512 output words there are linear relations, and with enough unmasked evaluations the polynomial can be reconstructed. The exact guarantee stops there; beyond that, the construction relies on the usual computational assumption about ChaCha20.

The implementation is C++17. I initially used Horner evaluation, which was far too slow, but the 512 evaluation points have enough structure to use a 9-stage additive FFT. The resulting generator also supports random access and parallel generation of different ranges of the same logical stream.

For example, on a Ryzen 9 5900X with GCC:

ChaCha20: 99.6 M uint64/s
ChaCha20GF512 single: 43.8 M uint64/s
ChaCha20GF512 4 threads: 140.9 M uint64/s

Source, implementation details, benchmarks and the exact claims are here:

https://github.com/tzipproth/ChaCha20GF512

I should also mention that I used AI tools quite extensively during development, for coding assistance, optimization, review and discussing the design. The construction and claims are laid out in the README so they can hopefully be checked independently rather than taken on trust.

I'd be very interested in criticism, especially if I've stated something too strongly, missed an assumption, or overlooked closely related prior work.

It seems that I've managed to find the high-quality non-cryptographic PRNG that is older than DES. It was designed by A. Grube in 1973 and belongs to the MRG (multiple recursive generators) family. It is based on the next recurrent formula:

x_i = 518175991 x_{i-1} + 510332243 x_{i-2} + 71324449 x_{i-3} mod (2^{31} - 1)

Its period is approximately 2**93, initializers should be between 1 and 2**31 - 2. I've checked the coefficients using galois Python package, they seem to be correct, i.e. give a full period. It passes SmallCrush, Crush and BigCrush batteries from TestU01. Testing in PractRand and SmokeRand is a little bit challenging (it is a 31-bit generator), but if I use the uint31 filter from SmokeRand (adds the high-quality pseudorandom lowest bit from other PRNG) - it passes PractRand at least up to 2 TiB.

References:

• https://github.com/alvoskov/SmokeRand/blob/main/generators/grube73_mrg3.c
• https://doi.org/10.1002/zamm.197305312116

Tangentially related to randomness, as this is more math-specific, but these five 60-sided dice can randomly and fairly pick who goes first out of five people. They are also permutation fair, meaning it's fair for four or less players and also fair for who goes second, third, etc.

TestU01-threads adds multithreading support into a classic TestU01 test suite, it is written in C++17. It can use unmodified precompiled binaries of Test01 but can efficiently parallelize its batteries. E.g. on Intel Core i5-11400H @ 2.70GHz with 16 GiB of RAM it takes less than 10 minutes to complete Crush and less than 1 hour to complete BigCrush. The idea was very simple:

1) All statistical tests from TestU01 are treated as thread safe. I've not made a full TestU01 code audit yet but such assumption looks realistic: these tests use local variables, data structures, not global ones.

2) SmallCrush, Crush, BigCrush and pseudoDIEHARD batteries were manually converted to multithreaded versions based on a custom dispatcher. Each thread obtains its own list of tests and its own PRNG copy. The dispatcher is entirely deterministic: the same seeds will give the same result.

TestU01-threads also can be compiled as a plugin for SmokeRand, I've used it a lot in such mode. In this case it can use SmokeRand PRNG plugins, seeders and filters: e.g. reverse order of bits, lower/higher/interleaved mode for 64-bit generators. Usage as plugin also allows to rerun a single test from Crush or BigCrush easily (without recompilation).

https://github.com/alvoskov/TestU01-threads/

LFSR based PRNGs are very widespread and fast, we all known xorshift, xoroshiro, etc. But its period verification usually requires its translation to some mathematical notation, computation of characteristic polynomials etc. So I've made a tool (a new lfsr battery for SmokeRand) that allows to make this work without an explicit usage of all that "clever formula", the detailed description is given here.

https://github.com/alvoskov/SmokeRand/blob/main/docs/lfsr.md

The entire idea is fairly simple:

• Restore the transition matrix by a direct manipulation of the LFSR state, so C code becomes a mathematical formula itself. So it mustn't contain counters, pointers, file descriptors etc. And only PRNG with state size of 32, 48, 64, 96, 128, 160, 192, 256, 320, 512 or 1024 bits.
• Verify if the period is maximal using the transition matrix.
• Restore the charateristic polynomial using Krylov matrix and Gaussian elimination, transform it into a jump polynomial. I've used S.Vigna jump functions to check myself here.

It also can be used for LFSR parameters search, I've used it to obtain two new 16-bit versions of xoroshiro (just for fun). That program also reproduces classic Marsaglia shifts triples for xorshift32/64:

https://github.com/alvoskov/SmokeRand/blob/main/apps/find_xorshift_params.c

Drawn with diagrams.net, I used the following sources to put this together:

• https://github.com/torvalds/linux/blob/master/drivers/char/random.c
• https://www.zx2c4.com/projects/linux-rng-5.17-5.18/
• https://www.zx2c4.com/projects/linux-rng-5.17-5.18/inside-linux-kernel-rng-presentation-sept-13-2022.pdf

I believe this is an accurate view without getting too deep into the weeds. There are probably still some minor wrinkles that need ironing out, but this illustrates how RDSEED, SipHash, BLAKE2s, and ChaCha20 all fit together in random.c to generate cryptographically secure random numbers.

I wanted a "real" quantum random number generator, something where every bit is an actual physical quantum event.

First attempt was a 1970s Canon FD 55mm f1.2 with a thoriated rear element. It's pretty radioactive (the Geiger counter make scary noises). But radioactive decay gives you when an atom popped, which is timing-random, not the which-path coin flip I was after.

The build that actually worked is optical: attenuate a light source down to single photons, fire them at a 50:50 UV beam splitter, and read which way each photon went with two detectors. Through → bit 0. Bounce → bit 1.

The detectors are two Hamamatsu PMT modules a friend gave me, pulled out of a dead lab instrument. I tore it down, yanked the dichroic mirror, and dropped in a UV 50:50 splitter. For a fluorescent source I ended up using 3D-printer filament — it's faintly fluorescent at the right wavelength and doubles as a light-tight cover.

All the detection and conditioning runs on a Red Pitaya (FPGA + fast ADCs):

• Op-amp + transistor LED current sink, reed-relay LED gate, PMT gain via dividers, all driven by the Red Pitaya's slow DACs so I could sweep everything in software instead of hand-twiddling pots.
• VHDL threshold + edge detection on the 14-bit ADC, a coincidence veto (kills double-fires / cosmic rays), and a symmetric "global blank" after every event — that last one matters, because per-channel dead time secretly biases the stream.
• A timestamped debug FIFO that was a chunk of fabric to build but caught a bunch of detector-memory artifacts I'd otherwise have shipped.

The hard part genuinely wasn't generating random-looking bits, but it was proving they were real random bits from the optical system and not other noise sources. Most of the project ended up being diagnostics...

I've tested it with 1.6 billion QRNG bits with the NIST test package, and it passes.

Payoff demo is a Quantum Magic 8-Ball: hit a button, it pulls fresh quantum bits and gives you one answer (and, if you're an Everettian, every other answer somewhere in the multiverse).

Full build log with schematics, scope shots, and the FPGA stuff: https://dnhkng.github.io/posts/building-the-beam-universe-splitter/ or
https://news.ycombinator.com/item?id=48689891 if you want to spread the story?

Happy to answer questions on the analog front end or the FPGA fabric — the analog side is honestly my weakest area, so I'd welcome the critique.

I have hardware support for long integer operations. You can approximate it as BigInt(n) in JavaScript. I seek PRNG which can take advantage of this hardware support.

Proposed workflow - do some math using BigInt and then split result into byte array. User will pull randomness from that array. Obviously you can keep generator internal state in BigInts.

Probably combination of several LCG generators with post processing will do the job. This type of generator (combined LCG) is used in proprietary biology simulation software and gives same results in monte Carlo as slow Mersenne twister.

While MT produces better randomness during testsuites in real world monte carlo deployment that doesn't translates to more accurate results.

RP2040 family 32-bit microcontrollers have programmable state machines that are fast (150x10^6 ops/s) but have only 4 registers and 32 words of program space with limited instructions. There is no ADD or XOR, only bit-complement (~x), bit-reverse (::x), decrement (x--) and some bit shifting. I have an application for a PRNG that would operate on a state machine, and despite what AI says, LFSR seems impossible. I tinkered with some designs which could work, and came up with this transition function that works better than LFSR and doesn't need XOR. It's in C preprocessor for readability and ability to be optimized by the compiler. The subtraction of a small number (1-4) can be done by repeated decrements.

#define PIO_LET(osr) { \
  uint32_t x = rev32(osr); \
  uint32_t isr = 0; \
  for(int i=0; i<16; i++) { \
    x -= (osr & 3) + 1; \
    osr = osr >> 2; \
    isr = (isr << 2) | (x & 3); \
  } \
  osr = ~isr; \
}

I was surprised to see that this is bijective, by testing all 2^32 inputs, but I can't see how to write the reverse function. In CBC mode it passes PractRand up to 64MB. Can anyone with some discrete math skills tell me why my creation works? Would it be bijective at larger bit lengths that can't be verified by brute force?

Nowadays we already have a lot of good generators, but most of them are hard to learn by heart. It seems that I've designed one that is very easy to memorize:

u_n = 29386*(x_{n-3} + x_{n-2}) + c_{n-1}
x_n = u_n mod 2^32
c_n = u_n >> 32

It is a modification of MWC (multiply with carry) generator that uses two lags instead of one. It strongly resembles some experimental generators by G. Marsaglia from 1990s. The multiplier is intentionally chosen to be small: it is easier to memorize, also it simplifies its implementation inside MS Excel/LibreOffice Calc cells or for retro platforms where double was used instead of uint64_t. If you set carry to 1 then the initial x values can be arbitrary.

RWC32u48 returns 32-bit unsigned integers (x_n). The u48 suffix means "only 48 bits in intermediate results".

Of course, it is still LCG, and the points fail at planes but empirical quality is good: it passes BigCrush, PractRand 0.94 at least up to 32 TiB and SmokeRand full battery. Its period is around 2¹⁰⁹.

https://github.com/alvoskov/SmokeRand/blob/main/generators/rwc32u48.c

We already know a lot of good and modern PRNGs, but it is not clear where the first high-quality generators (that pass tests such as TestU01 and PractRand) really appeared. My candidates are:

1) DES-CBC and Magma-CBC. These 64-bit block ciphers are fairly slow but perform well in statistical tests. However, CTR mode will fail the birthday battery in SmokeRand.

2) RANLUX (1993): the LCG with 576-bit state, prime modulus and a special form of its multiplier. Fairly slow, often comparable to DES or even 3DES.

3) ISAAC by Bob Jenkins (1996), both 32-bit and 64-bit versions. Fast.

4) 32-bit Mother-of-All from DIEHARD CD-ROM (1995-1996): MWC with four multipliers. It performs well in TestU01, PractRand and SmokeRand.

5) KISS96, also from DIEHARD CD-ROM. It seems that the original implementation contains an error in the MWC component, but even with that typo it passes TestU01 and 32 TiB in PractRand. The fixed version passes at least 16 TiB in PractRand. KISS96 is also fast.

Is my list correct? The next PRNGs don't match: RC4 (fails PractRand), additive/subtractive lagged Fibonacci (even variants with huge lags fail some SmokeRand and gjrand tests).

From the abstract:

In this paper, we use tools from computational finance to provide an estimate of the amount of entropy in the closing price of a stock. We estimate that for each of the 30 stocks in the Dow Jones industrial average, the entropy is between 6 and 9 bits per trading day. We then propose a straight-forward protocol for regularly publishing verifiable 128-bit random seeds with entropy harvested over time from stock prices. These “beacons” can be used as challenges directly, or as a seed to a deterministic pseudorandom generator for creating larger challenges.

Always neat to see PRNGs in the wild doing cool things. Here is XORoshiro-256** generating ~180MB/s of random data to securely wipe four HDDs at a time.

I was messing with dieharder, and I was wondering if they were any better options

Hi, I am bored and want to try making my own hardware based RNG or PRNG. I will make RNG server with raspberry pi pico 2w, but I have no experience with HRNG. I only heard of capacitors based, but still I'd like

any tips you have.

I was experimenting with the AES-NI instructions yesterday and came up with an extremely simple and fast PRNG that passes PractRand up to >2TB (after which I stopped the test):

vpaddq  xmm1, xmm1, xmm0
vaesdec xmm3, xmm1, xmm2
vaesdec xmm3, xmm3, xmm2

# xmm1: state/weyl sequence incremented by xmm0
# xmm2: seed
# xmm3: output

or in C:

#include <immintrin.h>
#include <stdint.h>
#include <stddef.h>

void
aesdec2(__m128i *out, size_t n, uint64_t seed[2])
{
    __m128i weyl, inc, mix;
    inc = _mm_set_epi64x(0xb5ad4eceda1ce2a9, 0x278c5a4d8419fe6b);
    weyl = mix = _mm_set_epi64x(seed[0], seed[1]);
    while (n--) {
        *out++ = _mm_aesdec_si128(_mm_aesdec_si128(weyl, mix), mix);
        weyl = _mm_add_epi64(weyl, inc);
    }
}

It's not that surprising that the AES primitives make for a good scramble, but this only uses it on top of two Weyl sequences and not to advance the state.

This makes this very fast, as only the latency of the addition is important to get to the next state.

It's also arbitrarily parallelizable since you can easily pre-compute different offsets of the Weyl sequences. Because the second argument of aesdec is a constant, it's also compatible with the slightly different AES instructions in ARM, SVE and RVV (otherwise you would need to pass zero and need an extra instruction).

I'm not sure if the seeding above is enough. It would probably be better to include the Weyl sequence increments in the seed.

PS: I totally missed that PractRand 0.96 was released last month.

Hi everyone,

I built a browser based demo and testing application for a pseudorandom number generator I have been working on, called RGE256. The main purpose of the app is to make it easy to generate data, inspect structure, and run basic statistical checks without needing a local toolchain.

Demo: https://rrg314.github.io/rge-256-app

 Repository: https://github.com/RRG314/rge-256-app 

Repository: https://github.com/RRG314/rge256 

Paper: https://zenodo.org/records/17713219 Author: Steven Reid (ORCID: 0009-0003-9132-3410)

About the generator

RGE256 is a 256-bit ARX style PRNG using add, rotate, and xor operations on eight 32-bit state words. The version used in the demo is the “safe” variant, which includes a 64-bit counter mixed into the state. This guarantees a minimum period of 2⁶⁴ and avoids seed collapse or short cycles.

The generator is deterministic and intended for simulation, Monte Carlo work, testing, and educational use. It is not designed to be cryptographically secure, and the app explicitly warns against using it for security, gambling, or financial applications.

About the app

The app is a single-file HTML application with no external dependencies. It runs entirely in the browser and can be installed as a progressive web app for offline use.

The app allows you to:

• Configure the generator (seed, number of rounds, domain separation, rotation parameters) • Generate large sequences of integers or floats • View distributions using histograms, scatter plots, and bit-level visualizations • Run basic statistical tests such as entropy, chi-square, serial correlation, runs, and gap tests • Perform simple Monte Carlo demonstrations like pi estimation, random walks, and distribution sampling • Export results and metadata to TXT, CSV, JSON, or a PDF report for reproducibility

The goal is not to replace established test suites, but to provide a transparent, interactive way to inspect generator behavior and catch obvious structural issues.

Validation

The core generator has been tested using external tools:

• Dieharder: 112 passes, 2 weak, 0 failures • SmokeRand: 42 out of 42 tests passed, quality score 4.0

I understand the limitations of these tests and I am not claiming they prove cryptographic quality. They are meant as baseline validation.

What I’m looking for feedback on

1. Whether the generator design and counter integration look reasonable for a non-crypto PRNG and any suggestions to push it towards a cryptographic prng
2. Whether the statistical tests and visualizations in the app are implemented and interpreted correctly
3. What additional tests or diagnostics would be useful to include in a browser-based tool like this

This was the first PRNG I completed and develop end-to-end, and the demo exists mainly so others can try it easily and point out issues or improvements. Any technical feedback is appreciated.

we report that MT19937 fails in a natural test based on the distribution of run-lengths on which we found an identical value in the output 32-bit integers. The number of observations of the run-length 623 is some 40 times larger than the expectation

Just found that link during the reading of the previous post about MT19937. The site contains some valuable empirical testing results but also very strange claims about pseudorandom number generators. Such as consideration of a custom PRNG as a TRNG, recalibration of BigCrush with non-cryptographic generators etc.