On 1/24/2016 5:12 AM, Yoav Nir wrote:
The HSM has enough entropy to generate (once) a 256-bit (or 384-bit or 521-bit) key. When working as part of a TLS server using regular ECDSA it would need to generate a random k for each full handshake, and many such servers routinely handle tens of thousands of such handshakes per second. So it’s hundreds of kilobytes per second, for an HSM that has no network input, no I/O of any kind other than the signature requests, this may be a problem. I’ve seen people claim this in the past.
This *really* isn't how most HSMs work. They mostly have TRNGs (True Random Number Generators) aka Hardware RNGs based on noisy diodes or ring oscillators or some such (e.g. no stupid linux like entropy source from keyboard motion or network interrupts). This gets fed into a PRBG construct - something like the ones in SP800-90A. Which does the entropy expansion/extraction to get you pretty much any number of bits you want of good quality randomness in plenty of time to do handshakes.
There's actually a cool set of USB devices that provide *very* good TRNG. Take a look at http://ubld.it/products/truerng-hardware-random-number-generator/ or http://ubld.it/ and the drivers (or internal logic) feed what they get from the TRNG into a good PRBG. I've been playing with using them as an augmentation of how I generate keys.
If you're stuck on commodity hardware (e.g. intel motherboard) and worried about randomness, there's also this: https://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide. Later versions of the intel platform have a TRNG embedded in them as well as an SP800-90A PRBG.
One of the things about FIPS and RNGs is that there is a pretty good set of requirements AND tests that can be used to establish just how good of an RNG source you have (and provide pretty good error detection and fail logics).
Later, Mike _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
