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
