Re: DRBG seeding
On Fri, Apr 17, 2015 at 03:19:17AM +0200, Stephan Mueller wrote: > > 1. during initialization of a DRBG instance, seed from get_random_bytes to > have a DRBG state that is seeded and usable. I think we either need to use real entropy and block, or mark the DRBG unusable until such a time that it has been seeded with real entropy. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DRBG seeding
Am Donnerstag, 16. April 2015, 19:11:18 schrieb Andreas Steffen: Hi Andreas, > Hi Stephan, > > in my opinion you definitively have to seed the DRBG with true > entropy from /dev/random. This is what we are currently doing > in userland with the strongSwan DRBG needed for the post-quantum > NTRU-based key exchange algorithm. The NIST SP800-90A spec defines > a parameter which estimates the entropy contained in the seed, > but I think it is extremely difficult to derive an estimate > if /dev/urandom is used. > > Our plans within the strongSwan project is to make the Linux > kernel DRBG available via the af-alg interface. I am working on that. My current idea is the following: 1. during initialization of a DRBG instance, seed from get_random_bytes to have a DRBG state that is seeded and usable. 2. at the same time, initiate an async request to the yet to be developed (or rather forward-ported and accepted) in-kernel /dev/random interface 3. when the async request returns, re-seed the DRBG with that data I am playing with the idea that steps 2 and 3 are repeated 2 or 3 times where the first invocation only requests a few bytes from the in-kernel /dev/random -- this again should seed the DRBG with entropy as it becomes available. But thank you for your support. It is surely helpful to show also to Ted Tso that an update to /dev/random is of interest to various users. Ciao Stephan > > Best regards > > Andreas > > On 16.04.2015 17:32, Stephan Mueller wrote: > > Am Donnerstag, 16. April 2015, 23:26:18 schrieb Herbert Xu: > > > > Hi Herbert, > > > >> On Thu, Apr 16, 2015 at 05:07:20PM +0200, Stephan Mueller wrote: > >>> I do not see a specific requirement in SP800-90A about the quality of > >>> the > >>> noise source. > >> > >> Well it explicitly says that you cannot use a DRBG. In the worst > >> case get_random_bytes is completely deterministic. > >> > >>> That said, I already developed an in-kernel version of /dev/random. I > >>> sent > >>> the patch to LKML some half year ago. If I understood Ted Tso right, > >>> there > >>> is no general objection against adding that in-kernel interface. See [1] > >>> for the thread. > >>> > >>> Furthermore, I already started working on updating the DRBG to use that > >>> in- > >>> kernel /dev/random interface. > >>> > >>> Shall I pursue that work in earnest now? > >>> > >>> [1] https://lkml.org/lkml/2014/5/11/276 > >> > >> Yes I think we should do this. > > > > Ok, I will work on that after I added the global lock to the DRBG. > > > >> Thanks, > > > > Ciao > > Stephan > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-crypto" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DRBG seeding
Hi Stephan, in my opinion you definitively have to seed the DRBG with true entropy from /dev/random. This is what we are currently doing in userland with the strongSwan DRBG needed for the post-quantum NTRU-based key exchange algorithm. The NIST SP800-90A spec defines a parameter which estimates the entropy contained in the seed, but I think it is extremely difficult to derive an estimate if /dev/urandom is used. Our plans within the strongSwan project is to make the Linux kernel DRBG available via the af-alg interface. Best regards Andreas On 16.04.2015 17:32, Stephan Mueller wrote: Am Donnerstag, 16. April 2015, 23:26:18 schrieb Herbert Xu: Hi Herbert, On Thu, Apr 16, 2015 at 05:07:20PM +0200, Stephan Mueller wrote: I do not see a specific requirement in SP800-90A about the quality of the noise source. Well it explicitly says that you cannot use a DRBG. In the worst case get_random_bytes is completely deterministic. That said, I already developed an in-kernel version of /dev/random. I sent the patch to LKML some half year ago. If I understood Ted Tso right, there is no general objection against adding that in-kernel interface. See [1] for the thread. Furthermore, I already started working on updating the DRBG to use that in- kernel /dev/random interface. Shall I pursue that work in earnest now? [1] https://lkml.org/lkml/2014/5/11/276 Yes I think we should do this. Ok, I will work on that after I added the global lock to the DRBG. Thanks, Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- == Andreas Steffen andreas.stef...@strongswan.org strongSwan - the Open Source VPN Solution! www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===[ITA-HSR]== smime.p7s Description: S/MIME Cryptographic Signature
Re: DRBG parallel requests
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DRBG seeding
Am Donnerstag, 16. April 2015, 23:26:18 schrieb Herbert Xu: Hi Herbert, >On Thu, Apr 16, 2015 at 05:07:20PM +0200, Stephan Mueller wrote: >> I do not see a specific requirement in SP800-90A about the quality of the >> noise source. > >Well it explicitly says that you cannot use a DRBG. In the worst >case get_random_bytes is completely deterministic. > >> That said, I already developed an in-kernel version of /dev/random. I sent >> the patch to LKML some half year ago. If I understood Ted Tso right, there >> is no general objection against adding that in-kernel interface. See [1] >> for the thread. >> >> Furthermore, I already started working on updating the DRBG to use that in- >> kernel /dev/random interface. >> >> Shall I pursue that work in earnest now? >> >> [1] https://lkml.org/lkml/2014/5/11/276 > >Yes I think we should do this. Ok, I will work on that after I added the global lock to the DRBG. > >Thanks, Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DRBG parallel requests
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 Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DRBG seeding
On Thu, Apr 16, 2015 at 05:07:20PM +0200, Stephan Mueller wrote: > > I do not see a specific requirement in SP800-90A about the quality of the > noise source. Well it explicitly says that you cannot use a DRBG. In the worst case get_random_bytes is completely deterministic. > That said, I already developed an in-kernel version of /dev/random. I sent > the > patch to LKML some half year ago. If I understood Ted Tso right, there is no > general objection against adding that in-kernel interface. See [1] for the > thread. > > Furthermore, I already started working on updating the DRBG to use that in- > kernel /dev/random interface. > > Shall I pursue that work in earnest now? > > [1] https://lkml.org/lkml/2014/5/11/276 Yes I think we should do this. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DRBG parallel requests
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 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DRBG seeding
Am Donnerstag, 16. April 2015, 22:36:17 schrieb Herbert Xu: Hi Herbert, >Hi Stephan: > >Currently DRBG is seeded with entropy from get_random_bytes. >However, get_random_bytes is basically the kernel version of >/dev/urandom. So there is no guarantee that you're actually >getting the amount of entropy required. > >Are you sure this is compliant with the DRBG specification? I do not see a specific requirement in SP800-90A about the quality of the noise source. But SP800-90B specifies tests and assessments about the quality. When applying that specification, I applied some initial assessments: /dev/urandom complies with SP800-90B when disregarding the very early boot stage (i.e. when assuming that the input_pool received sufficient entropy). The only shaky time is the boot time until the nonblocking_pool/input_pool has been sufficiently seeded. That said, I already developed an in-kernel version of /dev/random. I sent the patch to LKML some half year ago. If I understood Ted Tso right, there is no general objection against adding that in-kernel interface. See [1] for the thread. Furthermore, I already started working on updating the DRBG to use that in- kernel /dev/random interface. Shall I pursue that work in earnest now? [1] https://lkml.org/lkml/2014/5/11/276 Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DRBG parallel requests
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 Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DRBG seeding
Hi Stephan: Currently DRBG is seeded with entropy from get_random_bytes. However, get_random_bytes is basically the kernel version of /dev/urandom. So there is no guarantee that you're actually getting the amount of entropy required. Are you sure this is compliant with the DRBG specification? Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
