Re: how i stopped worrying and loved the backdoor

[coderman <coderman () gmail com>]

> On Fri, Dec 24, 2010 at 5:08 PM, Dan Kaminsky <dan () doxpara com> wrote:
> > Don't we have hardware RNG in most motherboard chipsets nowadays?

On Fri, Dec 24, 2010 at 11:10 PM, BMF <badmotherfsckr () gmail com> wrote:
> Do we? By what mechanism do they operate? Thermal noise seems the
> easiest way to go

a plethora of options abound.

a torrent of raw output is preferable to a smaller stream of whitened,
"more random" bits. there are a million kitschy ways to collect
entropy like lava lamp cams and Bernoulli effects across your spinning
disks.

the key idea being that an entropy daemon (reduced priv. in userspace)
will validate the incoming raw stream to satisfaction, guarding
against physical errors (hw producing stream of 0 bits) or degredation
(abrupt / unacceptable level of bias sanity checks failing raw stream
- see FIPS long runs, monobit, other basic "it's not clearly broken"
checks. [0]

incidentally marsh ray, this is why no hw to kernel random feed is a
feature, not a bug, regarding your earlier post. as long as an entropy
daemon has a mechanism to feed into the kernel pool you are golden -
this is the proper way to incorporate a hw source into overall host /
application entropy needs. (can be as easy as writing to /dev/random
and handling writable state events on fd to replenish kernel pool for
all uses.)

and as always, you can never prove something is random or guarantee an
entropy density. at best you're making an educated guess and weeding
out what is clearly not random. (this fact makes for fun
complications)



> ... although I have always preferred the idea of
> sampling random radioactive decay simply for the purity of the
> immediate result.

so elegant. just harder to get on die  *grin*



> What is the quality of the entropy of the devices
> you speak of? How fast do they generate entropy?

my favorite is the XSTORE instruction in padlock engine. it is good
quality with published design and independently validated
implementation capable of 120Mbps+ on newer processors - more than
you'll ever need. n2rng on SPARC T2 also great.

there are many decent hw sources in various platforms from AMD, Intel,
SPARC, and hardware security modules / crypto accelerators from
numerous others. all depends on your application and kit...  also many
that suck. do your homework :)



> How could I tell if my machine had hw rng built in?

cat /proc/cpuinfo for flags,
lspci | lsusb for accelerator / bus devices,
and/or start host entropy service (rngd, mtrngd, cryptoki, etc.)

sadly, these physical sources are not nearly as plentiful as they
should be, and even if present rarely does the host operating system
and applications make use of it.



> ... I have heard of
> people pointing webcams at lava lamps and such to get random numbers.

there should be an award for creative entropy; this is one of the
saner sources people have built ;)



0. Sanity checks on hw sources to include, but not limited to:
- volume of at least 80 megabits under consideration and 1500 Byte to
4kB validation before mixing with host pool.
- FIPS 140-1 suite
- run length variance
- column, overall, block means
- random walk test
- spectral analysis w/ high, med, low, smoothing and correlation adjustment
- 8,16 bit Maurer tests
- 4,8,16 bit monkey tests
- Komologorov-Smirnov trend test
- anything else useful?

this still leaves the difficult task of determining the acceptable
limits and tunable parameters for your specific hardware sources,
entropy daemon settings, and profile of entropy consumption in
applications, network stacks, and kernel.

did i mention good entropy is hard?

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/