Slow zone signing with ECDSA

[Paul Kosinski]

"The tinfoil hat brigade in some distributions has resisted using them,
fearing some conspiracy to provide not-so-random numbers."

I think the NSA *did*, in fact, compromise the "Dual Elliptic Curve
Deterministic Random Bit Generator" and paid RSA to make it the default
in one of their products -- https://en.wikipedia.org/wiki/Dual_EC_DRBG.


On Wed, 19 Apr 2017 22:09:28 -0400
Timothe Litt <litt at acm.org> wrote:

> 
> On 19-Apr-17 21:43, Mark Andrews wrote:
> > ...
> > DSA requires random values as part of the signing process.  Really
> > all CPU's should have real random number sources built into them
> > and new genuine random values should only be a instruction code
> > away.
> >
> > Mark
> Most recent ones do.  See RDRAND for Intel (and AMD).  Even Raspberry
> Pi.
> 
> The tinfoil hat brigade in some distributions has resisted using them,
> fearing some conspiracy to provide not-so-random numbers.  (Despite
> the fact that /dev/random hashes/whitens the inputs to the entropy
> pool.) You may need to take a positive action to enable use of the
> hardware source.  Google RDRAND for plenty of entertainment.
> 
> There are also fairly inexpensive (~usd 50) USB devices that provide
> reasonable entropy quality at decent speeds.  (But much lower than
> RDRAND.)  They're good for the old hardware that you recycle for
> single-purpose servers.
> 
> Systems that have low activity/low entropy can benefit from
> entropybroker (https://www.vanheusden.com/entropybroker/).  Use it to
> distribute entropy from those who have to those who don't.  It's
> really handy for VMs, and for that isolated system that you use for
> your root keys.
> 
> For most uses, use /dev/urandom - which doesn't block.  /dev/random
> will block if the entropy pool is depleted.  (However, if you have a
> hardware source, very, very rarely.)  /dev/random is recommended for
> long lived keys - which usually includes KSKs, and may include ZSKs.
> I don't believe named makes a distinction...you get to pick one for
> everything.
> 
> Timothe Litt
> ACM Distinguished Engineer
> --------------------------
> This communication may not represent the ACM or my employer's views,
> if any, on the matters discussed. 
> 
>