

Purifying spoiled randomness with spoiled randomness - schrototo
https://mittheory.wordpress.com/2015/08/15/purifying-spoiled-randomness-with-spoiled-randomness/

======
gizmo686
I haven't read either of the papers yet, but can anyone comment on what makes
it difficult to output multiple bits. Naively, couldn't you gather weak random
data from the two sources, get a single bit, then gather more weak data, and
run the extractor again to get a second bit?

~~~
henrytcs
Hi gizmo686. Yes, what you propose is correct. But this requires that every
time you iterate this process, you're required to find additional sources of
weak data that is _completely independent_ of the sources of weak data you
used in the previous iterations. In that case, you're describing an extractor
that requires multiple independent sources.

What the challenge was (and it looks like there was some progress a couple
weeks ago), was that you'd like to produce multiple bits using only two
independent sources, and no more than that!

------
fenomas
Can someone in the know post a conceptual description of roughly what's going
on here?

The last time I read up on randomness, I was given to believe that it's not
really an observable quantity - that is, a sequence of numbers is random only
to the extent that nobody's found a pattern in them yet, and as such, the most
rigorous way we have of testing strong RNGs is to run them through a battery
of test for the sorts of patterns that are known to show up in weak RNGs. But
that sounds far-removed from the situation the article describes, where this
or that generator can be proven to be perfect or imperfect.

Is this the gap between theoretical analysis and real-world implementations,
or am I misunderstanding something more fundamental?

~~~
ThrustVectoring
You're on the right track with randomness. "Random number" is a bad word - it
implies that randomness is a property of the number, rather than the more
complete picture of "you can expect that people will be unable to predict the
number, given a certain set of background information."

~~~
bbrazil
To expand on that a little, the main property you're looking for is that if I
give you the N random numbers that have already been generated you can't
predict what the next one will be with certainty beyond random chance.

[https://en.wikipedia.org/wiki/Cryptographically_secure_pseud...](https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator#Requirements)
has more detail.

------
PaulAJ
I thought that entropy solved this problem: your "weakly" random numbers from
the thermometer might have, say, 1.3 bits of entropy for every reading. So you
assemble 100 readings and that gives you 130 bits of randomness, which you
extract by putting your 100 readings through a cryptographic hash algorithm
that outputs 130 bits.

Presumably I'm missing something. Can someone tell me what it is?

~~~
versteegen
Whether a hash function is cryptographic or not is irrelevant: either way,
it's computable, therefore you can reverse it and get information about the
original data you hashed. Because that data was only weakly random, it's not
independent of future data from the same sources, so you can compute what
future results of the hashing algorithm are likely to be.

Obviously this is impractical in the real world, but in TCS randomness is
defined as algorithmic randomness, which completely ignores the question of
running time. Randomness is a mathematical concept, something can't suddenly
become non-random because you gained a faster computer. For more information
see:
[https://en.wikipedia.org/wiki/Kolmogorov_complexity#Kolmogor...](https://en.wikipedia.org/wiki/Kolmogorov_complexity#Kolmogorov_randomness)

~~~
versteegen
To correct that: there are many different definitions of randomness, and
they're not actually using a form of algorithmic randomness in this paper
(there are many definitions of _that_ too), which I guess isn't so relevant
for randomness extraction.

------
ademarre
How far away are we from using this practically? e.g. /dev/random

