Re: [TLS] Require deterministic ECDSA

[Michael StJohns <[e-mail]>]

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