Re: libnss x86 DRNG
This is a reasonable use.. This can simply be implemented in the primitive where /dev/random is used. It would only need a HW check during initialization to enable using the DRNG or leave it as is in the event HW does not support it.. Michael Demeter Staff Software Engineer Open Source Technology Center - SSG Intel Corporation On Oct 3, 2012, at 4:30 AM, Wan-Teh Chang w...@google.com wrote: On Tue, Oct 2, 2012 at 9:02 PM, Robert Relyea rrel...@redhat.com wrote: But we can use it go seed the prng. There's a pretty easy way to get NSS to use HW generated values to get some initial entropy: If you create a PKCS #11 module that advertises a RNG (See the PKCS #11 spec), NSS will mix entropy from it's own internal PRNG as well as extract random values to mix into it's internal PRNG. Such a scheme would allow even old version of NSS to benefit from HW RNGs. As another step, there are a set of internal entropy collecting functions within NSS that are platform specific called: win_rand.c, unix_rand.c, and os2_rand.c. Mixing hardware generated bits into the RNG_SystemRNG() call would pick up new HW generated entropy whenever NSS decided it needs to reseed. Yes, we can use it as an entropy source. I think the latter method is better. I just verified that there is no DRBG validation certificate issued to Intel: http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgval.html So I think we can only use it as an entropy source. Wan-Teh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: libnss x86 DRNG
Thanks for the response.. See inline comments On Oct 1, 2012, at 5:22 PM, Ryan Sleevi ryan-mozdevtechcry...@sleevi.com wrote: Hi Michael, There is definite interest in being able to take advantage of hardware intrinsics - whether they be the DRNG or the AESNI instructions. For example, NSS just recently added support for AES-GCM, and taking better advantage of PCLMULQDQ is one of the items on the roadmap, since currently no support exists (there is support for AESENC/AESDEC and it will be used as the bulk AES function when support is detected at runtime) There are one of two places the the DRNG can go in. One would be to utilize it within NSPR (Netscape Portable Runtime), which NSS makes use of for a number of primitive types and cross-platform abstraction. This would make it available to any applications that depended on NSPR (which there are many). However, they may not need as strong a source of hardware entropy, but it's worth considering. Within NSPR, the core entry point is http://mxr.mozilla.org/security/source/nsprpub/pr/src/misc/prrng.c , which shuffles you off to the platform-specific RNG (eg: nsprpub/pr/src/md/windows/w32rng.c or nsprpub/pr/src/md/unix/uxrng.c ) This actually looks like it may be a very good starting point.. The actual DRNG primitives allow retrieving 16, 32 and 64 bit randoms.. so having the HW check for capability and implementing these primitives for the retrieving randoms would be a good starting point.. Continuation would then be to eliminate any unnecessary work being done to increase the randomness..Since the HW generated values can be used directly. This could help a small little bit in performance (but that is a secondary effect)… In the Unix implementation, you can see some inline intrinsics are already being used, albiet non-portably. Within NSS proper, the RNG is handled by freebl (the core primitives), which are then exposed as a software PKCS#11 token in softoken (aptly named, right?) The FreeBL implementation is declared at http://mxr.mozilla.org/security/source/security/nss/lib/freebl/secrng.h , and then implemented accordingly through sysrand.c, unix_rand.c, and win_rand.c in the same directory. I have been through this code section that is how I determined that if the new drngd is running libnss will get its values from the new HW DRNG in effect doing the right thing… If you would like to see the implementation details the changes have been included in openssl you can check the details on how it was implemented there..The specific implementation is in crypto/engine in version 1.0.1 and here also http://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide/ Michael -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: libnss x86 DRNG
On Tue, Oct 2, 2012 at 7:45 PM, Michael Demeter michael.deme...@intel.com wrote: Continuation would then be to eliminate any unnecessary work being done to increase the randomness..Since the HW generated values can be used directly. This could help a small little bit in performance (but that is a secondary effect)… The code in mozilla/security/nss/lib/freebl/drbg.c implements one of the deterministic random bit generators (DRBGs) specified in NIST SP 800-90 (the Hash_DRBG). It is necessary for FIPS 140-2 validation. For this reason NSS can't use hardware-generated values directly. Wan-Teh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: libnss x86 DRNG
On 10/02/2012 05:42 PM, Wan-Teh Chang wrote: On Tue, Oct 2, 2012 at 7:45 PM, Michael Demeter michael.deme...@intel.com wrote: Continuation would then be to eliminate any unnecessary work being done to increase the randomness..Since the HW generated values can be used directly. This could help a small little bit in performance (but that is a secondary effect)… The code in mozilla/security/nss/lib/freebl/drbg.c implements one of the deterministic random bit generators (DRBGs) specified in NIST SP 800-90 (the Hash_DRBG). It is necessary for FIPS 140-2 validation. For this reason NSS can't use hardware-generated values directly. Wan-Teh But we can use it go seed the prng. There's a pretty easy way to get NSS to use HW generated values to get some initial entropy: If you create a PKCS #11 module that advertises a RNG (See the PKCS #11 spec), NSS will mix entropy from it's own internal PRNG as well as extract random values to mix into it's internal PRNG. Such a scheme would allow even old version of NSS to benefit from HW RNGs. As another step, there are a set of internal entropy collecting functions within NSS that are platform specific called: win_rand.c, unix_rand.c, and os2_rand.c. Mixing hardware generated bits into the RNG_SystemRNG() call would pick up new HW generated entropy whenever NSS decided it needs to reseed. bob -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
libnss x86 DRNG
Hello, I work in the Open Source Technology group at Intel in the security group. I have been tasked with contacting the maintainer of libnss to start discussions about the possibility of Intel submitting patches to enable the new HW based digital random number generator. What I would like to do is to have a short (or long) discussion over how you would like to see this done…In the current implementation it will do the right thing if drngd(Fedora 18) is running since libnss still pulls from /dev/random. But it does a lot of unnecessary work afterwards since the HW based DRNG for /dev/random can be used directly. What I would like to do is to implement native DRNG functions to replace the current functions if the HW is available..So I would like some input as to how you would like to see this implemented or if there is any interest at all.. Thanks Michael Demeter Staff Software Engineer Open Source Technology Center - SSG Intel Corporation -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: libnss x86 DRNG
On Mon, October 1, 2012 3:08 pm, Michael Demeter wrote: Hello, I work in the Open Source Technology group at Intel in the security group. I have been tasked with contacting the maintainer of libnss to start discussions about the possibility of Intel submitting patches to enable the new HW based digital random number generator. What I would like to do is to have a short (or long) discussion over how you would like to see this done In the current implementation it will do the right thing if drngd(Fedora 18) is running since libnss still pulls from /dev/random. But it does a lot of unnecessary work afterwards since the HW based DRNG for /dev/random can be used directly. What I would like to do is to implement native DRNG functions to replace the current functions if the HW is available..So I would like some input as to how you would like to see this implemented or if there is any interest at all.. Thanks Michael Demeter Staff Software Engineer Open Source Technology Center - SSG Intel Corporation Hi Michael, There is definite interest in being able to take advantage of hardware intrinsics - whether they be the DRNG or the AESNI instructions. For example, NSS just recently added support for AES-GCM, and taking better advantage of PCLMULQDQ is one of the items on the roadmap, since currently no support exists (there is support for AESENC/AESDEC and it will be used as the bulk AES function when support is detected at runtime) There are one of two places the the DRNG can go in. One would be to utilize it within NSPR (Netscape Portable Runtime), which NSS makes use of for a number of primitive types and cross-platform abstraction. This would make it available to any applications that depended on NSPR (which there are many). However, they may not need as strong a source of hardware entropy, but it's worth considering. Within NSPR, the core entry point is http://mxr.mozilla.org/security/source/nsprpub/pr/src/misc/prrng.c , which shuffles you off to the platform-specific RNG (eg: nsprpub/pr/src/md/windows/w32rng.c or nsprpub/pr/src/md/unix/uxrng.c ) In the Unix implementation, you can see some inline intrinsics are already being used, albiet non-portably. Within NSS proper, the RNG is handled by freebl (the core primitives), which are then exposed as a software PKCS#11 token in softoken (aptly named, right?) The FreeBL implementation is declared at http://mxr.mozilla.org/security/source/security/nss/lib/freebl/secrng.h , and then implemented accordingly through sysrand.c, unix_rand.c, and win_rand.c in the same directory. Now, as for actual exposing/implementation, presumably an approach similar to the use of AES-NI would be appropriate. For that, look at freebl's intel-aes.h, as well as it's related use in rijndael.c http://mxr.mozilla.org/security/source/security/nss/lib/freebl/rijndael.c#969 - compile time check to disable - run time env check for a flag to disable - run-time input check to make sure it can be used - Function signature typedef that can match either the 'native' (Intel) implementation or the 'builtin' (NSS) implementation, and the function pointer is updated accordingly. Right now, I'm not aware of a good cross-platform assembler solution in use for NSS - eg: yasm to abstract for cross-platform object file generation. So for usage on both Windows and Posix/BSD, it may be necessary to write two implementations. Feel free to ask more questions if the above is vague. I'm sure Wan-Teh, Bob, or Brian will chime in if I misdirected, but I'm fairly confident that the above is the right approach for integrating hardware specific features (for now at least). If you or any of your coworkers feel especially motivated, support for PCLMULQDQ would be hip too ;) -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
