Re: DRBG parallel requests

[Stephan Mueller <smueller@chronox.de>]

Am Donnerstag, 16. April 2015, 23:30:38 schrieb Herbert Xu:

Hi Herbert,

>On Thu, Apr 16, 2015 at 05:13:50PM +0200, Stephan Mueller wrote:
>> Surely, the shadow approach scales better than a global lock. But its
>> drawback is the (almost) identical state.
>
>The drawback is that your DRBG is no longer anything like that
>specified by the standard.  You've completely changed the
>cryptography by reusing the internal state.

Well, I used the same line of thought as found in other implementations of the 
DRBG (I do not want to name names though :-) ). As I thought another call to 
get_random_bytes is too expensive, the high-res timer came to mind.

But during my discussions with Rafael, I already did not like that solution.
>
>> Rafael: do you have any better idea here other than remove the shadow copy
>> approach and use a global lock?
>
>I don't think you can get around the global lock due to the sequential
>nature of the DRBG that is built into its design.
>
>> >The only users of RNG in the crypto API do so in process context
>> >so we can make it a rule that all users RNG must be in process
>> >context.
>> 
>> Herbert, which type of lock am I allowed to use? Is a spin lock sufficient
>> or shall I use a mutex. I am not fully sure whether the used shash or
>> cipher type can sleep.
>
>As I said we can make it a rule that any user of our RNG must be in
>process context (all existing users are) so you can use a mutex.
>
>Also, if we change the entropy source to a blocking one as discussed
>in the other thread then you'd definitely want to have a mutex intead
>of a spin lock.

Ok, a mutex will appear shortly.
>
>Cheers,


Ciao
Stephan