> SSH is likely getting it's entropy from /dev/random. The kernel will > decide whether there is enough entropy in the /dev/random entropy pool, > and block reads until the pool fills. > > This pool, in turn, is going to have pleanty of entropy generated by > timing jitter in disk I/O interrupts. > > To experiment with this, run the command: > > cat /dev/random | od -cx You can also see how much 'pure entropy' is available without depeleting it by checking /proc: $ cat /proc/sys/kernel/random/entropy_avail 215 > Disclaimer: there is dispute in the crypto community about the hashing > done in /dev/urandom (note the 'u') which never blocks. /dev/urandom > just recycles the entropy pool with a PRNG, and people have variable > faith in the quality of PRNG's. Incidentally, many Linux distros will dump a chunk from /dev/urandom on reboot and write that chunk back on bootup, s.t. even /dev/urandom has something available from the get-go, based on the previous state. (The previous state hopefully had user interaction, etc.) Now this depends on us trusting the previous PRNG too, I'm not commenting on that.) The server on which I'm writing this has no keyboard for random input. In the time it took me to write this email (via SSH), it's gathered about 500 bytes of entropy, as seen through the aforemeantioned /proc entry. I just modified the bootup init.d scripts on a UML kernel I have. The very first thing rc does is cat entropy_avail to the screen, before any of the S?? scripts are run. It reported 23 bytes available, so even the execution of init => rc is sufficient to get some randomness in there. Not the best in the world, but it's a start. Even without user interaction, you're likely to get some entropy from the kernel. -- Brian Hatch "I see. So, you feel like Systems and you've been symbolically Security Engineer cast... in a bad light." http://www.ifokr.org/bri/ "Well put." Every message PGP signed
Attachment:
pgp00379.pgp
Description: PGP signature
