> nodes using CentOS 5. One of our users just ran onto a problem with > /dev/random blocking due to the lack of entropy.
/dev/random should be reserved for generating non-ephemeral keys. > Do others have this problem? What do you do? I've only ever heard of it on servers that do a lot of ssl transactions, and were configured to use /dev/random for transient keys or nonces. > Do you modify network drivers to introduce entropy? > Are there other suggested methods of adding entropy to /dev/random? good questions. I haven't been following the state of kernel entropy gathering - I guess I assumed that they'd worked out a basic set of reasonable sources and had a (eg) /proc interface for enabling others that would be site-specific (such as eth). > Are there ways to introduce entropy from the random number generator > on some Intel systems? Did Intel remove this from more recent chips? appears so: http://software.intel.com/en-us/forums/showthread.php?t=66236 > How reliable is /dev/urandom without initial entropy? We boot from my understanding is urandom is a crypto hash of the entropy pool: if the entropy pool never changes or is perfectly guessable, urandom is only as good as the hash. since the crypto hash is not broken in general, I'd consider it plenty good. > stateless disk images and don't carry any entropy over from previous > boots. boot scripts normally save and restore entropy, so why can't they do so to/from some server of yours? or even just have a boot script that stirs in some unique per-node data? (say low-order rdtsc salted with the node's MAC.) this is a good question - not a burning issue I think, but something to not forget about. we're starting to use NFS-root login nodes, for instance, which could conceivably run into entropy issues. _______________________________________________ Beowulf mailing list, [email protected] sponsored by Penguin Computing To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
