"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 <[email protected]> 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. > > _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/bind-users
