> 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

[ reply ]