[oulipo2]

I remember in the cracking days, where we were trying to crack ElGamal encryption or other, we noticed when some code had been written in eg Delphi (which used a weak RNG based on datetime), then when you tried to guess when the code was compiled and the key were generated, you could get a rough timerange, and if you bruteforced through that timerange as a seed to the RNG, and tried to generate the random ElGamal key from that, you would widely reduce the range of possibilities (eg bruteforce 10M ints, instead of billions or more)

[noir_lord]

An online casino got hit a similar way a long time ago, iirc someone realised the seed for a known prng was the system clock, so you could brute force every shuffle either side of the approx time stamp and compare the results to some known cards (I.e. the ones you’d been dealt) once you had a match you knew what everyone else had.

Always thought that was elegant (the attach not using the time as the seed).

[hipratham]

Can you not just add salt to seed and make it true random? seems like under engineered solution to me.

[lazide]

Difficulty - they used the date as the salt.

[hinkley]

I stopped airplane maintenance software from shipping with a particularly egregious form of this for SSL session key generation. It’s hard to get a good random seed on a real time operating system. I tell you hwut.

[tracker1]

Depending on access to sensor data, it's possible to use a mix of various sensors as well as the time for seed generation. Though baseline static from RF is better assuming that is possible as well.

Of course, it's always possible for something to do something stupid, like weak rng.