I'm trying to understand the rational behind the arc4random() and arc4random_stir() functions in the OpenSSH source tree. On a system that has a good random number generator, say an in kernel /dev/random what extra functionality is this stuff providing ? Would it be acceptable to replace the calls to arc4random() with reading from /dev/random and drop the arc4random_stir() all together ? Note I'm not suggesting doing this to OpenSSH before anyone starts a debate on the portability of the code and ties this into the PRNGd/yada yada thread. This is purely an exercise in understanding why RC4 is used in getting random data. Thanks. -- Darren J Moffat
On Wed, 28 Mar 2001, Darren J Moffat wrote:> I'm trying to understand the rational behind the arc4random() and > arc4random_stir() functions in the OpenSSH source tree.We are following the OpenBSD tree with as few changes as possible - this is the approach used by them.> On a system that has a good random number generator, say an in > kernel /dev/random what extra functionality is this stuff providing ?It minimises reads from /dev/random which usually contains a finite amount of entropy. Most of the random numbers used in OpenSSH need don't need the "information theoretic" strength of /dev/random.> Would it be acceptable to replace the calls to arc4random() with > reading from /dev/random and drop the arc4random_stir() all together ?If you want to waste randomness, yes :) Many of the calls to arc4random are fairly high volume users, e.g. paddding which is done per-packet. These would deplete /dev/random pretty quickly. If you used /dev/urandom (the 'endless' interface), then you are back to doing something like arc4random only in the kernel. -d -- | Damien Miller <djm at mindrot.org> \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer
In message <3AC24650.6BE258C at Eng.Sun.COM>, Darren J Moffat writes:>Would it be acceptable to replace the calls to arc4random() with >reading from /dev/random and drop the arc4random_stir() all together ?arc4random() does not block. It is initalized with data from /dev/arandom. arc4randomstir() reintializes arc4random() with new random data from the kernel. If you replace all calls to arc4random() with a read from /dev/random, you might cause OpenSSH to block for a long time. Niels.
Maybe Matching Threads
- openssh portable and libressl portable cause recursion between arc4random and RAND_bytes
- klibc 1.5.21-1 and mksh
- SNAP 20010209 fails to compile sftp on Slackware
- Maybe problem in openbsd-compat/bsd-arc4random.c
- Regarding the optional OpenSSL integration for the portable version