Mailing List Archive

Hello,

I'm trying to generate MPI random numbers on a Win32 (MinGW on a
Win2000) platform. (More precisely, I'm trying to add support for an
encrypted protocol in GAIM, an Instant Messenging application)

In GAIM, I'm using the gcry_mpi_randomize function, with a level of :
GCRY_VERY_STRONG_RANDOM to generate a session key

According to my tests, the first random number generation in GAIM is
very, very slow during the first invocation (sometime it can take up to
1~2 minutes !!) which is too long for the interactive use I need it for.

However, I should note that a test program, *outside GAIM*, is very fast
to generate the first random number.

I didn't have the time to fully understand the internals of rndw32.c,
but here is the debug info with a timer ( QueryPerformanceCounter )
comparing the test program invoking gcry_mpi_randomize function, then
GAIM invoking gcry_mpi_randomize function.

The timer is the delta, in performance counter increments, between the
current log call and the precedent log call.

/* Test program */
duration: 0 rndw32#gather_random: platform=2
duration: 222 rndw32#gather_random: req=3 len=300 lvl=2
duration: 33 rndw32#slow_gatherer_95: init toolkit
duration: 46709 rndw32#slow_gatherer_95: walk heap
duration: 79843 rndw32#slow_gatherer_95: walk processes
duration: 9746 rndw32#slow_gatherer_95: walk threads
duration: 22015 rndw32#slow_gatherer_95: walk modules
duration: 2932 rndw32#slow_gatherer_nt: init toolkit
duration: 315 rndw32#slow_gatherer_nt: check product options
duration: 31493 rndw32#slow_gatherer_nt: netapi32 loaded
duration: 5816 rndw32#slow_gatherer_nt: get netstats
duration: 386 NOTE: you should run 'diskperf -y' to enable the disk
statistics
duration: 280 rndw32#slow_gatherer_nt: get perf data
duration: 2388387 rndw32#slow_gatherer_nt: get perf data
duration: 846706 rndw32#slow_gatherer_nt: get perf data
duration: 816804 rndw32#slow_gatherer_nt: get perf data
duration: 1184713 rndw32#gather_random_fast: req=1
duration: 820 rndw32#gather_random_fast: perf data
(A total of 3 heaps were walked)
heap 1, 56 blocks
heap 2, 2 blocks
heap 3, 114 blocks


/* GAIM */
duration: 0 rndw32#gather_random: platform=2
duration: 4154 rndw32#gather_random: req=3len=300 lvl=2
duration: 1869 rndw32#slow_gatherer_95: init toolkit
duration: 8215 rndw32#slow_gatherer_95: walk heap
duration: 328406929 rndw32#slow_gatherer_95: walk processes
duration: 13863 rndw32#slow_gatherer_95: walk threads
duration: 27643 rndw32#slow_gatherer_95: walk modules
duration: 35375 rndw32#slow_gatherer_nt: init toolkit
duration: 2366 rndw32#slow_gatherer_nt: check product options
duration: 3367 rndw32#slow_gatherer_nt: netapi32 loaded
duration: 5028 rndw32#slow_gatherer_nt: get netstats
duration: 2724 NOTE: you should run 'diskperf -y' to enable the disk
statistics
duration: 1762 rndw32#slow_gatherer_nt: get perf data
duration: 1353009 rndw32#slow_gatherer_nt: get perf data
duration: 872048 rndw32#slow_gatherer_nt: get perf data
duration: 838450 rndw32#slow_gatherer_nt: get perf data
duration: 1038618 rndw32#gather_random_fast: req=1
duration: 2711 rndw32#gather_random_fast: perf data
(A total of 10 heaps were walked)
heap 1, 678 blocks
heap 2, 2 blocks
heap 3, 16099 blocks
heap 4, 7 blocks
heap 5, 7 blocks
heap 6, 46 blocks
heap 7, 8 blocks
heap 8, 8 blocks
heap 9, 3 blocks
heap 10, 9 blocks

GAIM is a GTK 2.0 application, compiled with MinGW. As you can see from
the numbers, in GAIM quite all the numbers are a little higher (which
can be normal although I don't know why), but the striking difference is
the number before the 'walk processes' log call.

Considering the timer I added, this in fact means that the time spent
between the log line 'walk heap' and 'walk processes' is very important.
Considering the file 'rndw32.c', this means that the 'walk heap' loop is
very, very long indeed. I added a count of the number of heap / heap
blocks walked (nbr of calls to pHeap32ListNext / pHeap32Next) to compare.

When I define out the whole 'walk heap' block, the generation is very
fast, so the problem is really there.

Perharps we should consider limiting the loop to a given maximum number
of heaps / heap blocks walked in order to reduce the time spent there ?
Or limiting the number of calls to the inner 'add' function to a given
number of iterations ? (for my application, I limited this to 200 calls
max to the Add function inside the heap loop, and this is very fast
(total of ~2 second for generating the first key).)

As I don't really know the impact on the quality of the entropy pool, I
prefer asking advices on this subject.


Best regards,

Ludovic LANGE