# Is it safe to seed a random number generator from system time?

It seemed to me that the Bouncy Castle SecureRandom class for C#/.NET only uses DateTime.Now.Ticks as its seed by default.

I was wrong, but wouldn't that be unsafe to do?

-
I see lots of questions about Bouncy Castle, here and on other SE sites. Is it really that bad? Should I start warning people whenever I see someone using it? –  otus Jul 18 at 19:42
Could you point me to the source, where they do that? Maybe add it to the question? Edit: Actually, I think I get it... –  otus Jul 18 at 20:04
I am sorry - I just stepped through code for the nineteenth time, and I just discovered I was wrong. YES, it's bad to use time as seed to prng, NO that's not all bouncy castle does. In fact, BC SecureRandom has a static instance called Master, which is seeded from Ticks and ThreadedSeedGenerator. The "SetSeed" method is confusing because it only adds seed material from Ticks; does not reduce the strength of the already present seed. –  Edward Ned Harvey Jul 18 at 20:25
Yes, that matches what I read in the Java version. –  otus Jul 18 at 20:29
Uggh. This is off-topic now for the question about system time, but it turns out, ThreadedSeedGenerator returns poor quality random - In all my tests, 50% compressible output was pretty typical and I've seen the output compress as much as 10:1. Which means a lot of patterns. And it fails the NIST sts tests. So in fact, regardless of the Ticks question, bouncy castle securerandom is unsafe to use. You might consider tinhatrandom.org as an alternative. –  Edward Ned Harvey Aug 4 at 14:43

## 2 Answers

Yes, it is unsafe to seed a PRNG with only with the system time. No, that's not all Bouncy Castle's SecureRandom does.

The SecureRandom default constructor calls SetSeed(GetSeed(8)); which calls Master.GenerateSeed(length); which calls SetSeed(DateTime.Now.Ticks); which is misleading because SetSeed only adds seed material to an already existing prng (the static instance called Master). If you look at the static declaration for private static SecureRandom Master you'll see that it actually seeds itself from a combination of Ticks and ThreadedSeedGenerator.

Why the system time is not enough

Using just the system time would be unsafe. The whole point of a crypto random generator is to be unguessable by an adversary, and by using the system time as a seed to the random number generator, you make it easy for an adversary to guess your seed and hence your random output.

DateTime.Now.Ticks has precision of 10 million ticks per second. Suppose an attacker knows what time you generated a key, +/- 1 second. They only need to make 20 million guesses ($2^{20}$ or so) in order to guess your random seed. This is likely crackable in a matter of seconds with a modern laptop.

Suppose an attacker has absolutely no idea what time you generated some key. They only know it was after – let's say – the year 2000. Since it's 2014 now, the entire space of 14 years occupies 51-52 bits. log2(10000000*60*60*24*365*14) ~= 51.97… This means the absolute highest level of entropy that you're likely to have in anything generated from system time is around 51 bits, which is small enough to be easily crackable, and realistically, you'll never even come close to that.

-

All Bouncy Castle's random generator classes seem to derive from java.security.SecureRandom, where seed doesn't mean "initialize state to this". It means "stir in any entropy from this".

That means what they do is not insecure, but shouldn't actually help either, since java.security.SecureRandom is already seeded with entropy from the system (e.g. /dev/urandom).

I'm assuming the same is true for the C# version, though I don't use C# so I'm not sure.

-