What are the pitfalls while generating a random number from a random data set?

Question

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?

Answer 1

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?

Answer 2

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?