[ / / / / / / / / / / / / / ] [ dir / drugs / gdp2083 / had / hikki / htg / leftpol / qpol / tijuana ][Options][ watchlist ]

/tech/ - Technology

You can now write text to your AI-generated image at https://aiproto.com It is currently free to use for Proto members.
Name
Email
Subject
Comment *
File
Select/drop/paste files here
* = required field[▶ Show post options & limits]
Confused? See the FAQ.
Expand all images

[–]

 No.837568>>837590 >>837771 [Watch Thread][Show All Posts]

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.

https://medium.com/vault12/how-to-get-true-randomness-from-your-apple-device-with-particle-physics-and-thermal-entropy-a9d47ca80c9b

https://itunes.apple.com/us/app/trueentropy/id1299321174

 No.837573

>new source of “true” thermal entropy from any Apple iOS device

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.


 No.837579

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


 No.837584

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


 No.837588>>837593 >>837598 >>837606 >>837616

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


 No.837590

>>837568 (OP)

Terry when are you going to start streaming again?


 No.837593>>837598

>>837588

Literally never


 No.837598>>837600

>>837588

>>837593

>what is the hardware generated AES keys for x86 hardware staying in a cache in the ME partition for future usage against high value targets


 No.837600>>837602

>>837598

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


 No.837602>>837605

>>837600

>what is minix

>what is assembly level instructions that are used to generate the key


 No.837605>>837609

>>837602

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


 No.837606

>>837588

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

Ask Debian's OpenSSL maintainer.


 No.837609

>>837605

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?


 No.837616

>>837588

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.


 No.837734>>837742 >>837750 >>837754 >>837988

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.


 No.837742

>>837734

>Even radioactive decay, or quantum whatever, could one day be found to have a pattern.

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.


 No.837750

>>837734

>Even radioactive decay, or quantum whatever, could one day be found to have a pattern.

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.

>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.

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.


 No.837753>>837765 >>837985

>How to get true randomness

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


 No.837754

>>837734

>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.

>he doesn't know how encryption works


 No.837765>>837958

>>837753

>he doesn't use entropy from a SP 800-90 approved CSPRNG

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


 No.837771

>>837568 (OP)

>iphone

>ios

very random secure trust me goy

>medium.com

>itunes.apple.com

ah ok, it's a spam.


 No.837958

>>837765

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


 No.837985

>>837753

>not using the new secrets module

Do you even lift?


 No.837988

>>837734

kys brian




[Return][Go to top][Catalog][Screencap][Nerve Center][Cancer][Update] ( Scroll to new posts) ( Auto) 5
23 replies | 3 images | Page ???
[Post a Reply]
[ / / / / / / / / / / / / / ] [ dir / drugs / gdp2083 / had / hikki / htg / leftpol / qpol / tijuana ][ watchlist ]