
Pure Randomness Extracted from Two Poor Sources - mmastrac
http://cacm.acm.org/magazines/2017/1/211100-pure-randomness-extracted-from-two-poor-sources/fulltext
======
jlgaddis
> _Some researchers have even speculated, especially since the disclosures by
> Edward Snowden, that commercial hardware sources could be subtly manipulated
> to make the codes easier to break by the U.S. National Security Agency or
> others._

Speculated!? I think it's pretty well established by now that Dual_EC_DRBG was
intentionally weakened.

\---

Abstract, etc.: [http://eccc.hpi-web.de/report/2015/119/](http://eccc.hpi-
web.de/report/2015/119/)

Paper (PDF): [http://eccc.hpi-
web.de/report/2015/119/revision/2/download/](http://eccc.hpi-
web.de/report/2015/119/revision/2/download/)

Related article from 17 May 2016: "Academics Make Theoretical Breakthrough in
Random Number Generation": [https://threatpost.com/academics-make-theoretical-
breakthrou...](https://threatpost.com/academics-make-theoretical-breakthrough-
in-random-number-generation/118150/)

~~~
lisper
Dual_EC_DRBG was software, not hardware. A hardware compromise would be much
(much!) harder to detect.

~~~
nickpsecurity
Not necessarily. The hardware guy that got me started on all that was
detecting them all the time. Some were really hard but others were obvious
once the veil was pulled back. He said he stayed doing that sort of thing as
did many others. Constant cat and mouse game. Your statement is true for
software people where it will be anywhere from challenging to impossible for
them to detect the hardware subversion.

~~~
lisper
I'm using the word "compromise" to mean the _deliberate_ introduction of a
vulnerability. I have a hard time believing that your friend was detecting
those "all the time" because I have a hard time believing that there are a lot
of deliberate hardware compromises in the field, and an even harder time
believing that these are easily detectable.

I can believe that your friend finds non-deliberately-introduced hardware
_vulnerabilities_ all the time, but that is not the same thing.

~~~
nickpsecurity
Oh no. You're assuming the hardware field is about simply producing hardware
and that's it. He taught me that they (a) know R&D cost a lot, (b) assume
patent trolls will hit them constantly so they obfuscate the hell out of
everything anyway, and (c) therefore steal each others stuff in whatever way
they can while not advertising specifics on how it works to avoid patent
trolls. The result was all kinds of hardware companies were ripping off all
kinds of others with constant remixes on top of a cat and mouse game for
security that makes software security look lame (my impression). He said
competitors even sometimes cloned the best stuff down to the transistors where
even he had trouble telling the fakes of his company's parts.

The defense was to make it hard to copy. They did crazy tricks on the digital
level. He did stuff on analog level as well since his area was mixed-signal.
His favorite technique was splitting the function between digital and analog
since so few analog people existed to RE that stuff. He pointed out that
digital tools couldn't even see analog stuff. Top that off with obfuscation to
wild degrees. We stopped hearing from him after he changed employers, though.

Some of the things he predicted came true. An example was the A2 backdoor
which was the kind of analog subversion he told us happened regularly. Another
included a fab compromise which his trust model got me thinking about and
predicting in the abstract. That the guys statements started coming true too
often in various ways among hardware people and in CompSci papers means I'm
inclined to believe him that hardware is a scheming a business as he claimed
it to be.

~~~
lisper
OK... but none of that sounds like it would result in deliberately introducing
_security_ flaws of the sort under discussion here. Let's not forget the
context of this discussion:

"Some researchers have even speculated, especially since the disclosures by
Edward Snowden, that commercial _hardware_ sources could be subtly manipulated
to make the codes easier to break by the U.S. National Security Agency or
others." [Emphasis added]

Obviously such attacks are possible, but are they likely? I can see how the
cat-and-mouse game of IP protection would lead to all kinds of dirty tricks,
but what would be the profit in introducing a backdoor that could be leveraged
to break _crypto_ or an RNG?

~~~
Cyph0n
I remember reading that the Linux kernel does not use Intel's hardware RNG
alone for /dev/(u)random precisely because of concerns that Intel has
backdoored the RNG.

~~~
lisper
Yes, that's true, and that is a legitimate concern. I personally would not
trust Intel's RNG because it is implemented in a way that deliberately hides
some of the underlying implementation in a way that would make it impossible
to tell if it's backdoored. That is my original point: it is much harder to
tell if hardware has a back door than software.

~~~
Cyph0n
But does this not provide an example of an intentional backdoor in a hardware
RNG?

I'm actually going to be diving into the literature on hardware verification,
with a focus on how to design IP that can be objectively verified by a third-
party. If I find something good, I might even do my PhD on this topic.

~~~
lisper
> But does this not provide an example of an intentional backdoor in a
> hardware RNG?

I don't know. No one knows outside of Intel. That's the whole point.

In fact, it's possible that even _inside_ Intel no one knows because a
backdoor could have been surreptitiously inserted by a rogue engineer working
for, say, the Chinese government, who has since left the company! I have no
idea whether Intel's internal design review processes are thorough enough to
prevent this. For someone who knew what they were doing and who was in a
position to influence the design to insert a back door without being noticed
would not be particularly hard.

> I might even do my PhD on this topic.

Good luck! Keep us posted.

~~~
Cyph0n
Ah yes, the insider threat is probably the toughest issue to deal with. At
this point, I guess we can only hope that the RNG isn't backdoored.

Thank you. I'll be sure to post something to HN once I've made some progress.
That will take time though.

------
tedunangst
So the paper is called "Explicit two-source extractors and resilient
functions". Not sure why the article goes out of its way to avoid actually
telling you this, or why there's quotes from about seven people who aren't the
authors. I _think_ it's the same as the top link in further reading.

The ACM cite for the STOC conference, which isn't linked, would be:
[http://dl.acm.org/citation.cfm?doid=2897518.2897528](http://dl.acm.org/citation.cfm?doid=2897518.2897528)

------
hannob
The introduction is a very nice example of how a lot of academic cryptography
works and what disconnect there is often between applied and academic
cryptography.

They quote Bruce Schneier, basically saying that nobody needs this and we
already have plenty of ways to generate secure random numbers. This is
countered with some handwavy arguments why you'd need them anyway that aren't
really explained.

The truth is: We don't need any theoretical work to generate better random
numbers, because we know how to do it. All security problems about random
numbers come from the fact that people aren't using the secure random number
sources we have.

~~~
more_original
A good understanding of randomness has much further implications than just
generating random numbers for cryptography. This work is not indended as a
practical method for generating random numbers, I think.

Randomness is very important for algorithms. It is currently unknown if being
able to make random choices adds expressive power to efficient algorithms (the
P=BPP question). Being able to generate good random numbers from a weak source
can lead to more efficient determinsitic implementations of randomized
algorithms, for example.

~~~
hannob
Seeing it like this is totally fine. I.e. this is basic research to better
understand the nature of random numbers.

It just happens that all so often I see vague justifications of the form
"Random numbers are important for crypto _THEREFORE_ we need fancy random
number thing X" \- however the logical link between the two is not explained
in detail (X may be quantum RNGs - or papers like the above). I won't blame
anyone for doing basic research. I just don't like it if people advertise
their basic research with practical implications that simply aren't justified.

------
nullc
I'm amused by the paper's abstract stating that "explicit construction" when I
can extract nothing so concrete from the paper (though a monotone boolean
function on N bits resistance to any coalition of size N^(1-t) for any
positive t sounds interesting to me-- achieving one for N^0.5 is well known
and simple).

I think I need a non-randomness extractor. :)

------
rini17
It's sad to see such immense effort to "extract" and "preserve" entropy, when
anyone interested could have all the quality random numbers they need from
simple and well auditable electric circuit. Somehow this is not in anyone's
interest, just let's all use PRNG.

~~~
nine_k
Isn't junction noise temperature-dependent? Aren't most hardware noise
generators, like lava lamp, physically large?

~~~
rini17
Where did you get such impression that it must be either? There are many many
possibilities, not just junction noise or lava lamps. Example:
[http://www.loper-os.org/?p=1427](http://www.loper-os.org/?p=1427)

~~~
DanBC
I think Cardano uses avalanche noise.

[http://trilema.com/2013/snsa-first-product-the-
cardano/](http://trilema.com/2013/snsa-first-product-the-cardano/)

> E) Entropy generator. This is an avalanche noise array, with some sanity
> checking in place.

Have I misunderstood?

------
amelius
> The practical implications may be modest for now, though. Security
> specialist Bruce Schneier, for one, does not see any urgent need for better
> random numbers. Schneier helped create the widely used Fortuna pseudorandom-
> number generator, and says there are already many adequate sources. "In my
> world no one's worried about this," he said. "These systems already work" to
> provide secure communications when attention is paid to all of the other
> implementation details. "We have lots of problems; this isn't one of them."

Is this true? It seems to me that /dev/random could use some serious speedup.

~~~
nullc
/dev/random could be much faster if it was using state of the art techniques.

Presumably it is difficult to change because of concern about bugdoors and
whatnot-- an anyone who really needs it to be fast will implement those
techniques in userspace and just use /dev/random to seed them.

------
halma
Does it relate in any way to Von Neumann's trick[1] to create a fair coin from
a biased one?

In short: if you don't trust the fairness from possibly biased coin flips,
then don't look at individual outcomes in a sequence of (H)eads or (T)ails,
but only at H,T or T,H combinations.

[1]
[https://en.wikipedia.org/wiki/Fair_coin](https://en.wikipedia.org/wiki/Fair_coin)

