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
