Or the seeds for these PRNGs must be 64-bit? I couldn’t find anything in the original paper that says this.
I’m fairly certain that the original authors recommended using another generator – like split-mix-64 – to extrapolate low-entropy seeds to the required state width. Using high-resolution time as a seed is common practice throughout software development and I think they were envisioning split-mix-64 to be adequate to get decent seed entropy from a linearly increasing timestamp. I’m certain it would be adequate to widen 32-bit seeds to the required width.
If my memory is correct, the reasoning was that split-mix-64 – although not as robust a PRNG as the XO*SHIRO family – is trivial to compute and reaches a reasonable level of entropy without needing many iterations.
It looks like[1] the state width is 256-bits, anyway – not 64 bits.
I’ve lost my references and don’t have time to go digging through archives right at the moment but I pulled up my Rust library that implements my PRNGs (which is a port of a C++ re-implementation that exploited learnings from implementing a C# library to replace Microsoft’s original, slow .NET PRNG, which was based on the research paper’s reference implementation, and ran in production for years and years…) ↩︎
If the paper says nothing then they probably just didn’t think about it. You can extend a 32-bit seed to 64 bits in various ways, and some may yield better results than others. If the paper mentions any seed extension strategies for wider numbers, then maybe you can adapt them to 32->64.
If not, why not try something like !X, X, where ! is bitwise or and X is your 32-bit seed.
