Over the holidays, I intend to finally rid portable OpenSSH of the builtin entropy collection code. Here's what I intend to do: When init_rng is called, we'll check OpenSSL's RAND_status(). If this indicates that their PRNG is already seeded, we'll do nothing. This effectively detects platforms which have /dev/urandom (or similar) configured into OpenSSL. If OpenSSL isn't seeded, we will fork+suid(user)+exec a subprocess "ssh-rand-helper" which will return 64 bytes of randomness to stdout. This will be used to seed OpenSSL's PRNG. 512 bits should be enough for anyone :) ssh-rand-helper may be a program which fetches randomness from PRNGd, it could be a Yarrow implementation or it could be an adaptation of the current entropy code to run in a one-shot mode. I'll certainly implement a PRNGd ssh-rand-helper, if time permits I'll do one of the others. This takes all the responsability out of OpenSSH for collecting random numbers and allows sites to implement whatever fallbacks they require using wrappers around ssh-rand-helper (which could be shell scripts). Comments? -d -- | By convention there is color, \\ Damien Miller <djm at mindrot.org> | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE)
Just so long as we can pull together decent documentation for all the options they have after the code removal. I know I'll be looking at doing PRNGd/OpenSSL mix soon then on my aging Solaris and NeXT boxes. BTW Damien, I assume this is your Christmas present to yourself. So enjoy. I won't stir. =) - Ben On Fri, 21 Dec 2001, Damien Miller wrote:> Over the holidays, I intend to finally rid portable OpenSSH of the > builtin entropy collection code. Here's what I intend to do: > > When init_rng is called, we'll check OpenSSL's RAND_status(). If this > indicates that their PRNG is already seeded, we'll do nothing. This > effectively detects platforms which have /dev/urandom (or similar) > configured into OpenSSL. > > If OpenSSL isn't seeded, we will fork+suid(user)+exec a subprocess > "ssh-rand-helper" which will return 64 bytes of randomness to stdout. > This will be used to seed OpenSSL's PRNG. 512 bits should be enough > for anyone :) > > ssh-rand-helper may be a program which fetches randomness from PRNGd, > it could be a Yarrow implementation or it could be an adaptation of the > current entropy code to run in a one-shot mode. I'll certainly implement > a PRNGd ssh-rand-helper, if time permits I'll do one of the others. > > This takes all the responsability out of OpenSSH for collecting random > numbers and allows sites to implement whatever fallbacks they require > using wrappers around ssh-rand-helper (which could be shell scripts). > > Comments? > > -d > > -- > | By convention there is color, \\ Damien Miller <djm at mindrot.org> > | By convention sweetness, By convention bitterness, \\ www.mindrot.org > | But in reality there are atoms and space - Democritus (c. 400 BCE) > >
Circa 2001-Dec-21 12:10:18 +1100 dixit Damien Miller: : Over the holidays, I intend to finally rid portable OpenSSH of the : builtin entropy collection code. Here's what I intend to do: [...] : If OpenSSL isn't seeded, we will fork+suid(user)+exec a subprocess : "ssh-rand-helper" which will return 64 bytes of randomness to stdout. : This will be used to seed OpenSSL's PRNG. 512 bits should be enough : for anyone :) Obviously, we'd only suid(user) for sshd, not for e.g. ssh, ssh-agent, or ssh-keygen. : ssh-rand-helper may be a program which fetches randomness from PRNGd, : it could be a Yarrow implementation or it could be an adaptation of the : current entropy code to run in a one-shot mode. I'll certainly implement : a PRNGd ssh-rand-helper, if time permits I'll do one of the others. : : This takes all the responsability out of OpenSSH for collecting random : numbers and allows sites to implement whatever fallbacks they require : using wrappers around ssh-rand-helper (which could be shell scripts). : : Comments? I wonder if we might not want to go so far as to specify an interface for this sort of thing (sort of like djb's checkpassword interface <http://cr.yp.to/checkpwd.html>). For example: ssh-rand-helper prints 64 octets of crytpo-quality randomness to stdout, closes stdout, and exits 0. If ssh-rand-helper could not obtain 64 octets of entropy, it closes stdout and exits 1. Then we could ask e.g. Yarrow to ship an ssh-rand-helper program that fits the interface, and it would no longer be our responsibility to maintain the helper for Yarrow. Sort of like we do with (ahem) ssh-askpass.... -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 262 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011220/f40c9b6e/attachment.bin
Damien--
The end question is, "Will ssh continue to work with no external
dependencies or not?"
If an upgrade comes out that suddenly breaks OpenSSH on all sorts of
platforms, well, people won't upgrade. Hell, they're lazy enough to
still
use some ancient kernel devoid of kernelspace entropy generation; I think
they can scrounge together the laziness to never, ever upgrade their build
of OpenSSH again :-)
I very much do like the idea of being able to plug in external entropy
generators. I think this is critical and important and many different kinds
of good. However, it's pretty critical that, failing the existence of one
of these external generator applications, ssh be able to take care of
itself -- possibly through a default last-ditch entropy source of "ssh -o
OutputEntropy yes".
We've had security issues before, and we may very well again. If we
make it difficult to upgrade a build of OpenSSH, knowing that will prevent
the software from being upgraded in the field, we're dooming a portion of
our audience to insecurity.
I have trouble accepting that.
--Dan
On Fri, 21 Dec 2001, Dan Kaminsky wrote:> Damien-- > > The end question is, "Will ssh continue to work with no external > dependencies or not?"That depends on two things: 1. Whether I write or adapt a ssh-rand-helper which pulls entropy directly from the system (like we do now). or failing that: 2. Whether someone else does. -d -- | By convention there is color, \\ Damien Miller <djm at mindrot.org> | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE)
I like the idea of doing this, and also doing something like mod_ssl for apache does? There is a subsection in httpd.conf that says what to use for entropy, and there can be many different types specified. Perhaps the final output could be a more configureable openssh with virtual hosts and the whole bit? This would allow different types of ciphers, and such to be used, but on a per virt host basis? Is that something that could be potentially bad? Just curious. On Thu, 2001-12-20 at 19:10, Damien Miller wrote:> Over the holidays, I intend to finally rid portable OpenSSH of the > builtin entropy collection code. Here's what I intend to do: > > When init_rng is called, we'll check OpenSSL's RAND_status(). If this > indicates that their PRNG is already seeded, we'll do nothing. This > effectively detects platforms which have /dev/urandom (or similar) > configured into OpenSSL. > > If OpenSSL isn't seeded, we will fork+suid(user)+exec a subprocess > "ssh-rand-helper" which will return 64 bytes of randomness to stdout. > This will be used to seed OpenSSL's PRNG. 512 bits should be enough > for anyone :) > > ssh-rand-helper may be a program which fetches randomness from PRNGd, > it could be a Yarrow implementation or it could be an adaptation of the > current entropy code to run in a one-shot mode. I'll certainly implement > > a PRNGd ssh-rand-helper, if time permits I'll do one of the others. > > This takes all the responsability out of OpenSSH for collecting random > numbers and allows sites to implement whatever fallbacks they require > using wrappers around ssh-rand-helper (which could be shell scripts). > > Comments? > > -d > > -- > | By convention there is color, \\ Damien Miller <djm at mindrot.org> > | By convention sweetness, By convention bitterness, \\ www.mindrot.org > | But in reality there are atoms and space - Democritus (c. 400 BCE)-- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin at coremetrics.com "Have regard for your name, since it will remain for you longer than a great store of gold." Ecclesiastes, Aprocrypha -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011221/5e1df4c3/attachment.bin
On Fri, 21 Dec 2001, Damien Miller wrote:> Over the holidays, I intend to finally rid portable OpenSSH of the > builtin entropy collection code. Here's what I intend to do:Have done :) I have just committed a patch which splits out the entropy gathering into a seperate process "ssh-rand-helper". As a result, there are nearly 1k fewer lines of hairy code in ssh and sshd :) There is an example ssh-rand-helper which, suspiciously enough, looks exactly like the old in-process entropy gatherer. At the moment it is not very pretty (though no worse than the old code), but it is time to stop for this evening. Hopefully someone else will step up to the plate and write or port a proper Yarrow PRNG. ssh-rand-helper is invoked by a hardcoded path (in libexecdir) and must produce a fixed (48 byte) quantity of entropy to stdout on execution. This is subject to change. It would be greatly appreciated if people cast a critical eye over the new entropy.c to make sure I haven't missed anything. The new code should "just work" after a "make install", so please try it out (after reading it thoroughly!) -d -- | By convention there is color, \\ Damien Miller <djm at mindrot.org> | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE)