How to get true randomness from your Apple device with particle physics and thermal entropy

Cryptography and randomness are interlinked on a fundamental level. When we encrypt a secret we want that result to look like completely random gibberish. In fact, if an external observer manages to notice any non-random patterns in our encrypted secret, that would be something they can exploit in order to recover parts of our secret. If you imagine cryptography as a ‘factory’, then for it to work well it has to be constantly lubricated by a fair amount of random entropy, otherwise the complicated machinery will explode in a spectacular fashion.
While that makes modern cryptography strong, it is very hard to find sources of good randomness. In fact, mathematicians have proven that if somebody gives you a seemingly random string, you cannot by any means ever prove if it is truly random (i.e. unpredictably generated), or if it just appears random, e.g. an adversary who wants to steal your secrets just crafted that string to look random. Since you cannot verifiably test any external service for the quality of its “true randomness”, in order to create a secure system you have to procure your own. Scientists have understood for a long time that it is pointless trying to hide the details of cryptographic algorithms, and they are widely known to everybody, including hostile attackers. The only things attackers do not know is the entropy of your cryptosystem — each bit of good (i.e. truly unpredictable) entropy creates a bit of cryptographic strength that protects your secrets.
Because cryptography requires a lot of unpredictable randomness, scientists have found many sources of “true” entropy — natural processes that through the laws of physics or chemistry constantly produce highly unpredictable, random results. Unfortunately, all these sources are inconvenient to use, because they require special purpose hardware or even more cumbersome setups. Current state of the art cryptography allows taking small, unpredictable seeds of randomness from the physical world, and spinning them up into endless, unpredictable, random streams of data. Modern computers and phones are equipped with highly sophisticated systems that do just that, so in general you can always use your computer’s /dev/urandom device when you need an unlimited source of randomness. If you are reading this on your MacBook right now, you can type the following command into the Terminal app to get as many random strings as you need: cat /dev/urandom | head -c 32 | base64 (substitute 32 to get longer or shorter strings).
One of the applications for natural entropy sources is building secure cryptosystems hosted on “cloud” servers. In such cases, we no longer have physical computers under our full control. There are a few ways to feed entropy into virtual computers, yet they all bear the same weakness cryptographers hate most of all — it requires blind trust of an external party to do the “right thing”. This is not optimal. Even the most respected cloud providers are still run by human beings who are known to make mistakes from time to time. Cryptographers prefer to be protected not by well-meaning humans, but by fundamental mathematical laws. And even the best corporations can be penetrated by hackers and hostile governments. As a customer of cloud services, there are simply no tests you can do to verify that your virtual host is getting “good” randomness from your trusted provider, or “bad” randomness that is subverted by hackers — they would look exactly the same. In fact, it will be enough for hackers to just make a copy of real, “true” randomness generated by the host hardware: it still will be perfect randomness received by your system, yet at same time it will be fully predictable (since the hackers would see it before you do). One popular version of Linux even created new service to help “pollinate” virtual machines with external randomness when they boot up.
In this article, we are going to show you how to create a new source of “true” thermal entropy from any Apple iOS device that is verifiably under your own control that nobody else can intercept or spoof. Having an independent, extra source of “true” entropy is useful because entropy failures are very hard to detect — there is no “flashing red light” to alert us when our main source of entropy fails for any reason. When used with reasonable precautions multiple sources of natural, “true” entropy allows us to build stronger cryptosystems.

medium.com/vault12/how-to-get-true-randomness-from-your-apple-device-with-particle-physics-and-thermal-entropy-a9d47ca80c9b
itunes.apple.com/us/app/trueentropy/id1299321174

Other urls found in this thread:

beacon.nist.gov/rest/record/last
twitter.com/SFWRedditVideos

You can measures differences in thermals on a iphone externally to predict entropy espcially as the temperature is regulated to a set, low, and predictable range. Try again.

Just use a Neug from the FSF. Its free/libre hardware and software and its still maintained.

Why not just use the classic Opera-style "move your mouse/finger around the screen for 10 seconds" prompt?

How important is true randomness in practice? How often do PRNGs get exploited in practice when used for key generation?

Terry when are you going to start streaming again?

Literally never

...

how would it know what to cache? How big do you expect such a cache to possibly be?

...

What do either of those have to do with the subject matter at hand, neither would answer my questions.

Ask Debian's OpenSSL maintainer.

It would know what to cache because of the assembly level instructions that are called for AES keys specifically. The cache could be as big as the unknown space used for intel ME's minix system.
Were you born retarded or did huffing stupid gas make you this way?

Normal PRNGs are quiet broken. There have been online gambling websites which showed the exact output of the random number generator and people were able to get back the state so they can predict what the next numbers the server was going to generate.
That is why it is recommended you use a CSPRNG. The only issue which CSPRNG is when an attacker can guess what your starting state is.
There really isn't an advantage using "true" randomness has over feeding a small amount of your randomness into a CSPRNG. I would even say it is safer to use a CSPRNG for your random numbers because you are guaranteed that it is random rather than relying on your source for random to be truly random and not just some complicated pattern.

There is a more fundamental problem - first of all, randomness can't be proven (as you said). Even radioactive decay, or quantum whatever, could one day be found to have a pattern. Also, even if something was truly random, it could still randomly pick a number like 123456, making your message easily decryptable, or even 000000, making your encrypted message the same as the plaintext.

I am extremely skeptical about this. The probability of finding a predictable pattern in radio decay is so low that it's meaningless to think about it in human timeframes.

That's very unlikely, and even if it did happen, it would still depend on underlying factors that are impossible for outsiders to know. It would still be unpredictable in practice.
You could also spontaneously go crazy and send your private key to everyone. That's a lot more likely than generating a key like that. The probability is so small that it's not worth taking into account.

python -c "import random; open('/dev/random', 'wb').write(bytearray.fromhex('{:x}'.format(random.getrandbits(512))))"

...

curl beacon.nist.gov/rest/record/last >/dev/random

very random secure trust me goy
ah ok, it's a spam.

Where do you get the randomness to do https correctly though?

Do you even lift?

kys brian