DRBG parallel requests

DRBG parallel requests

[Herbert Xu]

Hi Stephan:

Currently you can have two users of DRBG issuing requests in
parallel and end up using the same internal state.  The only
difference between them is the cycle counter that you inject
into the DRBG.

I can't see how this is safe as the cycle counter contains minimal
entropy.  The whole DRBG scheme depends on the fact that states
are not reused so surely this is a very bad thing?

I think we should just stick with locking the entire generation
function.

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.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: DRBG parallel requests

[Stephan Mueller]

Am Donnerstag, 16. April 2015, 22:44:55 schrieb Herbert Xu:

Hi Herbert, Rafael,

>Hi Stephan:
>
>Currently you can have two users of DRBG issuing requests in
>parallel and end up using the same internal state.  The only
>difference between them is the cycle counter that you inject
>into the DRBG.
>
>I can't see how this is safe as the cycle counter contains minimal
>entropy.  The whole DRBG scheme depends on the fact that states
>are not reused so surely this is a very bad thing?
>
>I think we should just stick with locking the entire generation
>function.

Ok, I can certainly add such a lock. That would simply the code significantly 
as the entire business with the shadow copy goes away.

However, before I aired the DRBG, Rafael reviewed the DRBG. Initially I had 
such a "global" lock during the operation of the DRBG. Rafael's strongest 
comment was to remove the lock in favor of the shadow approach considering 
that this approach scales much better.

Surely, the shadow approach scales better than a global lock. But its drawback 
is the (almost) identical state.

Rafael: do you have any better idea here other than remove the shadow copy 
approach and use a global lock?
>
>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.
>
>Cheers,


Ciao
Stephan

Re: DRBG parallel requests

[Herbert Xu]

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.

> 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.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: DRBG parallel requests

[Stephan Mueller]

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