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
