I am relatively new to the GPG key system and I have been been learning about the system through experimentation. I now know that while generating a random seed for the key generation, the random number is taken from either the kernel entropy (/dev/random) or pseudo-random number generator (/dev/urandom). The pseudo random generator generates a seed of with randomness of 1 in 2^160 as given here while /dev/random is blocking.

I was thinking whether it would possible for me to generate a random number myself beforehand and then feed it to my key-generator program? Specifically, I can take a certain amount of files (images,text, webpages etc.) from each PC in my lab and then scramble/interleave them. I can encrypt the files separately using different passwords, interleave them and decrypt them using some other password and so on. Are these methods good or do they have some flaw which is not obvious?

2 Answers 2


The files that you would be using (if used as is) would not be random, 'cause text files and web pages have a not-even distribution: letters will appear much more than anything else.

To avoid that, you said you would encrypt, decrypt, mix, etc, your files. So, you'd have a lot of work to generate some values that will be random. Well, why not use some pseudo random number generator to generate them? Blum Blum Shub is good to generate such numbers and also has a funny name.

Some others are listed in the wikipedia...

And it's better to use a already tested algorithm then try to recreate your numbers with something that you can't garantee that will end up having a random distribution. Let's say, what if all your files are similar, or somehow biased to some values? or you choose a encryption algorithm that, somehow, produces a biased result?


No, your proposal is probably not a good idea.

It is unlikely that your procedure will end up being more secure than /dev/urandom, and very likely that at least some of the time, your procedure will be significantly less secure than /dev/urandom. At least some of the time, the files may be predictable. Moreover, your proposal involves human effort, so it is more of a pain for the user. And, if you require the user to do some extra stuff, then many users may try to do the least possible, further reducing the security provided. In general, humans tend to be a poor source of randomness. For example, when you ask humans to generate passwords, often the resulting passwords are breakable by dictionary search.

What is the problem that you are trying to solve? You don't say why you find GPG's current behavior unsatisfactory. Did you have a bad experience with it?

  • No, I have no problems with the behaviour. I was not trying to put forward a new strategy or anything. I just wanted to know the quirks of random number generation. I already know about that Dilbert comics you gave so I have a pretty good idea about the lack of pitfalls of using human in general. My question was in relation to the method I used. I was thinking that since kernel also generates random number from my activity and I am doing too, what if I somehow "store" that randomness so that I don't have to wait while the kernel collects more entropy when I need it.
    – user9117
    Apr 14, 2012 at 5:10
  • @JayeshBadwaik, if you want to learn generally about how to collect entropy for a PRNG (rather than propose a specific scheme), you might want to ask a separate question about that. Your thought about having the kernel collect information about activity to seed its PRNG is a good one, and the kernel already does that, where it is safe to do so. The kernel already does collect some information about your activity and feeds that into the entropy pool for /dev/random. Also: If you use /dev/urandom, you'll never need to wait for the kernel to collect more entropy.
    – D.W.
    Apr 14, 2012 at 18:08

You must log in to answer this question.