On Thu, 13 Mar 2008 09:32, [EMAIL PROTECTED] said:
> I don't think the seed file approach works for a forking daemon like
> Exim because you cannot guaranteed an undisturbed read/modify/write
> cycle on the seed file. Locking is out of the question, too, because
It depends on how much entropy you want to have in the pool. Even with
all processes using the same random seed, libgcrypt will add extra
random to each process (e.g. 16 bytes from /dev/urandom). This turns it
into a PRNG which is not worse than using /dev/urandom directly.
The advantage reading a the seed file is that libgcrypt does not need to
initialize its own random pool. You may view this initialization as
assuring that the random pool is not plain zeroed out.
If you don't like that approach you cat limit the reuse of the seed file
by using a seed file name depending on the pid, like
asprintf ("/foo/bar/andom_seed.%d", ((int)getpid() % 5))
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
