Bill Sommerfeld wrote:
> On Thu, 2007-10-18 at 22:56 -0700, Hai-May Chao wrote:
>> Bill Sommerfeld wrote:
>>> Currently we generate a much larger number of pseudo-random bytes per
>>> "key" before going back to the well for another key.
>>>
>> Thank you for pointing this out. We generate a much larger number of
>> bytes (using the caller's buffer) when the caller's request is bigger
>> than "rndmag_threshold".
>
> yes, but how often do you generate a new key? a key part of the tuning
> I did for urandom a few years back involved eliminating lock contention
> by making trips back to the global pool very infrequent. the impact on
> scalability on multiprocessors was dramatic; the throughput of 24
> threads on a 24-way starcat domain went from ~5x negative scalability to
> near-linear scalability.
>
I don't intent to change the frequency of rekey from global pool. The
current approach of using "rm_olimit" and "rm_oblocks" to determine
the frequency of rekey will be kept intact.
Basically, two new fields "rm_seed" and "rm_key" will be added to
rndmag_t and will be initialized from global pool. When rekeying,
the rm_seed (XSEED) will be extracted from global pool, apply
FIPS 186-2 Step 3b:
XVAL = (rm_key + rm_seed) mod 2^b
followed by step 3c: (where x_j is the 20 bytes random bytes for output)
x_j = G(t, XVAL) mod q.
followed by step 3d:
rm_key = (1 + rm_key + x_j) mod 2^b
That is, each iteration generates 20 random bytes until the caller's
request is met.
> Have you measured lock contention with lockstat while running at least
> one /dev/urandom consumer per cpu?
>
No, I'll include this in FIPS testing after design review and coding
are done.
Thanks,
Hai-May
