On Mon, Sep 11, 2006 at 05:28:25PM -0500, Robert J. Hansen wrote: > Josef Wolf wrote:
> > Don't most unices have /dev/random nowadays? I never planned to run > > this thing on a windows box :) > GnuPG has been ported to many platforms. BeOS, OpenVMS, Win32, and many > more that have no /dev/random. I know. And this is good. But I am asking as a gnupg user, not as a developer. That's why I asked on the gnupg-users list instead of the developer list ;-) While gnupg runs on many platforms, I know that my application will run only on unix-like systems. At least in the next couple of years. I don't think I need to bother about systems I never used and probably will never use. (I've never seen BeOS, I played a little bit with VMS at high school about 20 years ago, I use Win only at work, because that's company-policy) > > Hmm, the only drawback I see is a slowdown. The application will > > just hang and wait for more entropy to arrive. > > As Daniel Keys Moran wrote in _The Last Dancer_, the mark of a > half-assed software design is its inability to fail gracefully. Most > software today would be lucky to be even half of that. > > GnuPG may fail well in that situation. But will _all_ your applications > fail well in that situation? Especially ones which can't afford to > block for minutes until the /dev/random pool replenishes? Well, that's why I asked how many random data gnupg consumes when encrypting. AFAIK, having random_seed be accessible to unauthorized people is not acceptable. Thus I have no choice, I just _have_ to use the --no-random-seed-file option. Unfortunately, the man page don't explain where the random data comes from when this option is used and what are the consequences to randomness quality. This is why I asked how gnupg will behave with this option. I still have no idea > Being a good software citizen means being sparing in your use of limited > systemwide resources. Thus, apps should avoid using /dev/random unless > there's a clear and critical need. For one, I still don't know whether --no-random-seed-file will cause /dev/random to be used at all. Further, it would be good to know how many data will be consumed. > >> 3. /dev/random is, as I understand it, an ad-hoc design. Many > >> people who need crypto software need vetted, certified designs > >> (even if the software itself isn't certified). E.g., some people > >> may require ANSI X9.17 RNG. With a software RNG, it's fairly easy > >> to just drop in whatever RNG you need. > > > > Ough... I always thought /dev/random has the highest possible > > quality. How can a RNG be more random than real entropy? > > Again, you're missing the point. > > If /dev/random is set up to be access for a radioisotope RNG on one > system, you have absolutely no guarantee it'll be a radioisotope RNG on > all systems. You have absolutely no guarantee it'll be a radioisotope > RNG even on all UNIX systems. Depending on how often you upgrade your > hardware, you may not even be able to guarantee it's a radioisotope RNG > on _your_ system. I never had a radioisotope RNG and I will probably never have such a beast. On an average system /dev/random collects entropy from keystrokes, mouse events, network traffic and such things. > GnuPG has no control over how each UNIX handles /dev/random. If GnuPG > has no control over that, then GnuPG isn't going to rely on that. On my system gnupg relies on /dev/random when keys are generated. > GnuPG _can_ rely on its own internal pseudorandom number generator. And > thus, it gets a random seed from some believed-good source (varies from > platform to platform), and successive calls to the PRNG just use that > instead. So it relies on /dev/random when generating keys but can't rely on it when actually encrypting? Doesn't sound very consequent to me. > You need to recognize that GnuPG is not a Linux-only platform, and > considerable work has gone into it to make it work on as many platforms > as possible. I have no doubts about this. But I still don't have any clue what consequences --no-random-seed-file has. Will encryption process block? Will the random data be of bad quality? _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
