Thayne Harbaugh <[EMAIL PROTECTED]> writes:
> Thanks. I'm more than happy to help out as well.
It would be great if you could look into the lsh/ssh2d problem; I
don't have sshd2 around.
> Minor note:
> At least on Linux, /dev/urandom and /dev/random are different.
> /dev/urandom just
> uses a simple random number generator. /dev/random uses disk, network,
> terminal
> and other events to generate cryptographicly secure random numbers.
I believe you're wrong. The kernel driver collects randomness into a
pool from various sources, estimates the contained entropy, and
generates output from the pool (decreasing the entropy counter as
appropriate). /dev/random blocks when the driver thinks it's out of
entropy, while /dev/urandom continues to generate data, so that it
degrades into a decent pseudorandom generator when real entropy runs
low. That's the only differency.
I don't want lsh (and even less lshd) to block because of entropy
shortage, which is why I'm using /dev/urandom. It might make sense to
use /dev/random when generating long-term keys, though. But I think
/dev/urandom should be good enough.
> What really bugs me is seeing all the failures of vmstat and netstat
> printed to the
> screen when an illegal option is tried. It seems that all the blind
> try/fail of executing
> vmstat, ps, netstat could be skipped if /dev/random (or whatever is
> appropriate
> for the OS) was just used.
That's a bug; that output should really not appear except in debugging
mode. The fix is to change a couple of werror() calls in unix_random.c
to debug() or perhaps trace(). Also the stderr of the programs should
be redirected to /dev/null (except in debugging mode).
> If there was a "--with-devrandom" configure option (or something
> similar) then you could substitue a possibly buggy unix_random.c
> with something from the OS that has been tested even more than lsh
> (yes, the obvious tradeoff - lsh:unix_random.c gets tested less).
Should the option just disable the use of sources besides /dev/urandom
(the effect will be to read a few (40) bytes from /dev/urandom at
startup, and use that as seed for an rc4-based generator), or do you
want to get the old behaviour back, which meant that lsh read a few
bytes from /dev/urandom everytime it needed more random data, e.g.
padding? The latter is a little unfriendly to other programs that
depend on /dev/random.
BTW, the rc4-generator should probably be replaced by something else
(e.g. a SHA1-based generator), according to advice from coderpunks.
> PS. One other bug that has been around for quite some time. The
> lsh.info page doesn't have an entry so that install-info can make a
> directory entry. I don't have a huge background with generating info
> files. If you want, however, I'm more than happy to come up with
> what needs to be done to fix the problem.
Please do. I think that that has been reported before, but I haven't
got around to fix it. If you find other non-urgent bugs, you can also
mail me a patch for the TODO-file, so it doesn't get completely lost.
/Niels
