That would be just over thirteen and a half cups of water, which may or may not be a lot depending on heat, humidity, activity level, and most of all, are you thirsty?
> The study, published in the scientific journal Addiction, concludes that there is more than simply a link or statistical association between alcohol and cancer that could be explained by something else.
This isn't published to any of the major health journals, rather it's been published in the journal Addiction which probably doesn't have the most balanced view on the role of alcohol in society.
The source http://imgur.com/DrEinPB states the problem using "256" not "2^8". I'm not sure if the tweeter is trying to be clever, but he isn't saving any characters by using the exponential notation.
If you're trying to save characters in a tweet, you don't have any savings in using exponential over decimal for base two until 2^14.
From the description on the page: In this interactive visualization, you can ride along with the Juno spacecraft in real-time at any time during the entire mission. For example, watch the arrival at Jupiter on the 4th of July, 2016, or see Juno use Earth’s gravity as a slingshot to pick up speed, or just learn about the science of Jupiter and about the spacecraft itself. You can even turn on and off the magnetic field, aurorae, and the radiation belt, all in 3D! All of this and more is waiting to be explored.
If you enjoy this kind of music, you'll like Shostakovitch. His 11th Symphony has this same style of music, and I've always felt like I was watching Aliens while listening to it. The two minutes in the following clip have the same build-up, rhythm, and style as the Bishop's Countdown: https://www.youtube.com/watch?v=uVL3vtZ-z6g&feature=youtu.be...
"Gnu Atheists is a pun on the label New Atheists that quickly took on a life of its own. As a pun, it is equivalent in meaning to New Atheists, and the two can be substituted for each other anywhere they occur."
I prefer to trust the NSA on these matters. They end up saying much of what the author has written, but they make it clear why you want to use one vs the other.
Unix-like Platforms (e.g. Linux, Android, and Mac OS X):
Application developers should use the fread function to read random bytes from /dev/random for cryptographic RNG services.
Because /dev/random is a blocking device, /dev/random may cause unacceptable delays, in which case application developers may prefer to implement a DRBG using /dev/random as a conditioned seed.
Application developers should use the “Random Number Generators: Introduction for Operating System Developers” guidance in developing this solution. If /dev/random
still produces unacceptable delays, developers should use /dev/urandom which is a non-blocking device, but only with a number of additional assurances:
- The entropy pool used by /dev/urandom must be
saved between reboots.
- The Linux operating system must have estimated that the entropy pool contained the appropriate security strength entropy at some point before calling /dev/urandom. The current pool estimate can be read from /proc/sys/kernel/random/entropy_avail.
At most 2^80 bytes may be read from /dev/urandom before the developer must ensure that new entropy was added to the pool.
Maybe I'm just tired & not able to detect sarcasm right now, but isn't 2^80 bytes more bytes than are currently stored in the world? That's on the order of 10^24, which is something like 1 million exabytes, which is a million squared terabytes, right?
The amount of digitally stored information in the world as of May 2009 [1] is in the order of 2^71. There's no way a single process in a Linux distro will live long enough to read 2^80 bytes for the foreseeable future.
There's safe and there's FUD. Nobody will read 2^80 bytes from urandom. You'll literally run out of time before that. It would take around 1,782,051,134 years to do on my system.
So if they write that there's a vulnerability after reading 2^80 bytes - that's great! We're secure. If they write that you must ensure to do something after 2^80 bytes - that's complete bullshit.
There are physical limits to our reality and it's very unlikely those limits can be broken (eg, speed of light). Given those limits, 2^80 is large enough that the limit cannot be surpassed without fully breaking reality (eg, timetravel).
If you can break reality, all bets are off though and trying to defend against attacks that break reality in the future are impossible.
The difference is that weaknesses were found in 3DES and MD5. Increasing computing power was not the main factor. "Only" being able to produce 2^80 random bytes is a known and expected limitation. Sure, the CSPRNG could in theory be found to have a weakness, but that has nothing to do with the 2^80 bytes and the same could be said for virtually any cryptographic algorithm.
I am not arguing that there are; that was the parent comment. However, while the 3DES weaknesses don't yield practical attacks now, they still reduce the effective key length. My point was not that 3DES is different in that it is exploitable, but that it is different from the 2^80 limit in that the CSPRNG in that the later is not a result of a mistake in the algorithm's design but instead an expected feature. Just like the fact that any fixed-size key symmetric cipher is "limited" by that key size.
Now, if someone found a lower limit based on exploiting some weakness in the random number generation, the analogy with 3DES and MD5 would make more sense.
My point is that even if today some sizes and lengths seem only of theoretical concern, tomorrow there might be a vulnerability, a new approach to the problem, or even natural technological evolution that might turn it into a practical attack (even when it seems impossible today)
Just as a random counter-example, Openssl does use that method. But it actually seeds from urandom, rather than random... And fails when forking/threading by default. :(
