Mailing List Archive

> I don't understand why a message digest function need to call
> "_gcry_fast_random_poll()" !? I noticed a FIXME:

This is to make sure that the random pool is filled with entropy on a
pseudo-regular basis. Note that this function call is a no-op, in case
the random pool has not been used before.

Thanks,
Moritz

On Fri 07 Jul 2006 18:50, Moritz Schulte wrote:
> > I don't understand why a message digest function need to call
> > "_gcry_fast_random_poll()" !? I noticed a FIXME:
>
> This is to make sure that the random pool is filled with entropy on a
> pseudo-regular basis. Note that this function call is a no-op, in
> case the random pool has not been used before.

Hmmm, this has the side effect of adding a non deterministic delay
to other unrelated to randomness functions (because of the lock).
(and might even become a bottleneck when many hashes are done in
parallel).

Maybe it might be more clear for this function (or a wrapper of it) to
become part of the randomness api?


regards,
Nikos

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Sat, 8 Jul 2006 14:54, Nikos Mavrogiannopoulos said:

> Hmmm, this has the side effect of adding a non deterministic delay
> to other unrelated to randomness functions (because of the lock).

You can't have a deterministic behaviour in a muli-threaded process.
If it would be deterministic a lock wouldn't be needed.

> Maybe it might be more clear for this function (or a wrapper of it) to
> become part of the randomness api?

It is intentional because too may crypto library users didn't care
about entropy polling leading to a very weak results.

BTW, other libraries do the same.



Shalom-Salam,

Werner


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

> On Fri 07 Jul 2006 18:50, Moritz Schulte wrote:
>> > I don't understand why a message digest function need to call
"_gcry_fast_random_poll()" !? I noticed a FIXME:
>>
>> This is to make sure that the random pool is filled with entropy on a
pseudo-regular basis. Note that this function call is a no-op, in case
the random pool has not been used before.
>
> Hmmm, this has the side effect of adding a non deterministic delay to
other unrelated to randomness functions (because of the lock). (and might
even become a bottleneck when many hashes are done in parallel).

Yep, exactly! And you didn't anwer to my question: which hash algorithm
may use random? Hash functions are determinitic, isn't it?

Victor Stinner






_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Mon, 10 Jul 2006 14:38, haypo@inl.fr said:

> Yep, exactly! And you didn't anwer to my question: which hash algorithm
> may use random? Hash functions are determinitic, isn't it?

It is not that the hash algorithm are using random but hashing is a
very common operation and often used right before other operations
require random. Thus doing a fast random collect there is a Good
Thing.

If you can provide profile data showing that it is really a problem
for your application we can add a control call to explicitly disable
these automatic polls.


Shalom-Salam,

Werner


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

> On Mon, 10 Jul 2006 14:38, haypo@inl.fr said:
>
>> Yep, exactly! And you didn't anwer to my question: which hash algorithm
may use random? Hash functions are determinitic, isn't it?
>
> It is not that the hash algorithm are using random but hashing is a very
common operation and often used right before other operations require
random. Thus doing a fast random collect there is a Good Thing.

I read _gcry_fast_random_poll() source code an finally understood :-p

This function calls do_fast_random_poll() which feed random pool with
current time, getrusage(), etc.

So : ok, it's a very good idea :-)

> If you can provide profile data showing that it is really a problem for
your application we can add a control call to explicitly disable these
automatic polls.

It was more a question than a performance problem.

Haypo




_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel