[vserver] Bought an entropykey - very happy

Eugen Leitl eugen at leitl.org
Thu Mar 25 08:27:36 EDT 2010

From: coderman <coderman at gmail.com>
Date: Wed, 24 Mar 2010 10:50:33 -0700
To: Morlock Elloi <morlockelloi at yahoo.com>
Cc: cypherpunks at al-qaeda.net
Subject: Re: [vserver] Bought an entropykey - very happy

On Wed, Mar 24, 2010 at 8:43 AM, Morlock Elloi <morlockelloi at yahoo.com>
> While avalanche noise (hoping it doesn't start to tunnel - that current must
be actively controlled as each junction is different) is a good source of
randomness (up to megabits / sec / junction), "encrypting" it just means
masking possible low entropy. I'd prefer to see raw conditoned stream than
"encrypted" one (even web content looks high-entropy to Diehard when

i have loved the padlock engines on via cores since they hit the
market in C5XL form with a single hw generator available via XSTORE.
unlike many designs this free wheeling resource can provide a torrent
of entropy sufficient to sate even the most gregarious consumption.

as mentioned above, you need a fast user space entropy daemon sanity
checking the raw, (probably) biased stream coming from hardware but it
is still good practice to digest this entropy to obscure any potential
generator state/bias heading into the host entropy pool.

that is to say, of the two common modes for utilizing hw entropy:
a. conservatively sample from a whitened, string filtered entropy
source for a low rate of high quality output (see xstore config words)
b. ramp un-whitened, un-filtered source(s) to maximum rate and AES/SHA
mix for high throughput, high quality output while irreversibly
masking generator bias/state present in the raw source stream.

the latter is more effective in practice and capable of generation
rates > 20Mbps with full FIPS sanity checks. the former tops out
around 1Mbps or less with more transient latency spikes on read (when
successive attempts to read fail to pass whiten+strfilter). note that
padlock engine supports SHA and AES on die as well making these easy
and fast to apply to generator output.

if you are still concerned a more conservative configuration would
estimate entropy density while feeding from raw input stream and add
encrypted/digested product to the host entropy pool with the specified
entropy density estimate adjusted downward to your requirements. (most
OS'es support this)


Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

More information about the cryptography mailing list