[Help-gnutls] Why delay generating second and other keys?

[Fran]

On Mér, 2005-10-26 at 23:15 +0200, Nikos Mavrogiannopoulos wrote:
> If you generate the keys in one process then the libgcrypt random generator 
> will optimize things a bit, since less reads from /dev/random will be 
> required.
...If this can help anyone:
I find alternatives but seems do not work very well for me:
        Via*, AMD, Intel (i81x) and other processor have RNG .
                *Last Via processor have cryto device supported by
                linux.
        Using noise of devices that use DAC converter audio sound card,
        video card.
        Open the wallet and buy a hardware RNG :)
        Other that I do not known.

The problem is that the device used is different that /dev/ramdom, and
libcrypt seems to use /dev/ramdom (very bad thing).
In some cases char device is in /dev/hw_random, /dev/?   depend of
kernel version and hardware.

I think that RNG char device should be set as user wants. For example,
for me at this moment should be a good choice set GLOBAL RNG
to /dev/hw_random (intel i810) that work more that /dev/random.

This can be solved in BRUTE MODE making this:
        rm /dev/ramdom
        ln -s /dev/hw_random /dev/random
        Set permissions  read user, group and others. I do not know
        security problems making this. With default only root can read
        from /dev/hw_random.

> > Another question:
> > Libcrypt use exit() in functions.
> This looks like a bug in libgcrypt.
> I will forward this to the libgcrypt list.

OK, But seems to be bad module design (not bug) on libcrypt that hits in GNUTLS functions.