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 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
