On Tue, May 17, 2016 at 11:29 AM, Jaromil <jaro...@dyne.org> wrote: > how about a lavalamp :^)
lavalamp is nice. its slow moving blobs generate some dozen or hundred bits per second, i don't know how much, but not too much. it is then gets recorded by a camera that easily generates many kilobytes of entropy per second as noise. an obvious optimization to this scheme is to remove the lavalamp, and point the camera to any surface that is not black and not white. you lose only a tiny fraction of the entropy. to my knowledge, this was the method used by lavarand. smarter people don't go through this loop, but rather don't buy a lavalamp in the first place. so why the problem is not solved then? because random is too important to trust the recording software and device drivers with it. you want to audit the prng and the entropy collection. good luck auditing all the software involved in recording video. also, a considerable fraction of computers don't have cameras. finally, if the camera fails, you are left with no entropy or very limited entropy, and you probably won't even know about it. that is the major benefit of onboard or even onchip sources: you can rely on their existence, and there is a simple and straightforward way for the kernel to access them. _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
