I was one of the implementers of JScript and on the ECMA committee in the mid to late 1990s, so I can provide some historical perspective here.
First off: the design ...
There's a quote for you in this crypto.SE answer, by Bruce Schneier in Applied Cryptography (1996), pp. 157–8.
You can also find Bruce Schneier citing himself in his blog (2009), if you want an online citation.
Here is the full quote, in case of the links breaking:
One of the consequences of the second law of thermodynamics is that a
certain amount of ...
Because there actually is a cryptographically secure alternative to Math.random():
This allows the developer to use the right tool for the job. If you want to generate pretty pictures or loot drops for your game, use the fast Math.random(). When you need cryptographically secure random numbers, use the more ...
It depends entirely on what you mean by "safe".
If your only concern is an attacker guessing URLs, then 16 alphanumerics gives roughly 8,000,000,000,000,000,000,000,000 possible addresses, which is plenty to stop random guessing -- in order for an attacker to have a 50% chance of finding even one picture on a site with a thousand users in a year, they'd ...
Hardware vs software RNGs
The first thing you mention is a hardware noise source. High-precision measurement of some metastable phenomenon is enough to generate unpredictable data. This can be done with a reverse-biased zener diode, with ring oscillators, with an ADC, or even with a Geiger counter. It can even be done my measuring nanosecond-level delays in ...
Potentially illegal: cryptography was still under tight export control in 1995, so a good CSPRNG might not even have been legal to distribute in a browser.
Performance: historically, CSPRNGs (cryptographically secure pseudo-random number generators) are much slower than PRNGs, so why use a CSPRNG by default?
No security ...
It depends on what you mean by "readable". If you want to use only hexadecimal characters, you will need 32 of them to reach 128 bits of entropy; this line will work (using only commands from the coreutils package):
head -c16 /dev/urandom | md5sum
This variant produces passwords with only lowercase letters, from 'a' to 'p' (this is what you will want if ...
Human brains are poor RNG. People are bad at generating random values in the privacy of their heads. They just cannot think randomly; though they can convince themselves that they do.
Physical process, on the other hand, are rather good sources of entropy. Take your mouse movements. A few dozen times per second, the mouse measures how far it has moved since ...
Using a camera as random source is a good idea (not a new one, but still a good one). However, you should do it correctly: take the photo, then hash it with a cryptographic hash function, e.g. SHA-256. Then use the output as a seed for a cryptograhically secure PRNG to generate as many random bytes as you need.
Using the file size will yield only very few ...
(Caveat: I certainly don't claim that HAVEGE lives up to its claims. I have not checked their theory or implementation.)
To get randomness, HAVEGE and similar systems feed on "physical events", and in particular on the timing of physical events. Such events include occurrences of hardware interrupts (which, in turn, gathers data about key strokes, mouse ...
Both OpenJDK and Sun read from /dev/urandom, not /dev/random, at least on the machine where I tested (OpenJDK JRE 6b27 and Sun JRE 6.26 on Debian squeeze amd64). For some reason, they both open /dev/random as well but never read from it. So the blog articles you read either were mistaken or applied to a different version from mine (and, apparently, yours).
Indeed, Math.random() is not cryptographically secure.
Definition of Math.random()
Returns a Number value with positive sign, greater than or equal to 0 but less than 1, chosen randomly or pseudo randomly with ...
First, there is no such concept as a cryptographically secure password. The aim of a password is to be hard to guess for an attacker and how hard it should be to guess depends on how the password is used: if the account is locked after three failed attempts the password can be more weak compared to when an attacker can try an unlimited number of passwords or ...
Let's take a different crack from a monetary perspective instead of a physics perspective. Skylar Nagao at Peerio stated that:
In a 2014
research paper on password memorability, security researchers Joseph
Bonneau (Stanford) and Stuart Schechter (Microsoft) estimated the cost
of an attack based on the total annual payout to bitcoin miners in
Any program written in Java
to the command line invocation used to start the Java process. (Without this, Java uses /dev/random to seed its SecureRandom class, which can cause Java code to block unexpectedly.)
Alternatively, in the $JAVA_HOME/...
Maybe not the answer to your question, but if you would like to "hide" the location of your profile pictures on a website, you could just embed the image as data URIs.
You can base64 encode the image on your server and embed the string on your website, instead of exposing any image paths.
see http://css-tricks.com/data-uris/ and http://css-tricks.com/...
Since you already brought up dropbox, I think we can give at least one reason why doing this is a bad idea:
Dropbox disables old shared links after tax returns end up on Google
The flaw, which is reportedly also present on Box, impacts shared files that contain hyperlinks. "Dropbox users can share links to any file or folder in their Dropbox," the ...
So is the concatenated random number better than a single random number?
If the random generator really produces random data then it will not matter.
... it would be harder to predict the next number in case there was an issue with the random number generator.
If the issue is that the random generator is not that random at all then it might even be ...
Here is the cryptographer's point of view. The person you quote says: "you don't need a cryptographically secure PRNG", but what he actually claims is "when I use MT 19937 and do some mumbo-jumbo such as throwing away a large part of the output, it somehow becomes a cryptographically secure PRNG".
His comment about storing "(219337-1)*4 bytes for lookup" is ...
It's a hardware implementation that hasn't been tested formally, and it's proprietary. The potential worry is that Intel could have backdoored the implementation at the NSA's demand.
The current way of mixing the rdrand output into the Linux kernel PRNG is that it's xor'ed into the pool, which mathematically means that there's no possible way for a weak ...
Some fab suggestions in the other answers. I find that makepasswd is not available everywhere, and using tr is (slightly) tricky, so there's another option using OpenSSL:
openssl rand -base64 16
The number is the number of bytes of randomness - so 16 bytes for 128-bits of entropy.
"Random" means: "that which the attacker does not know".
The important point to understand is that attack costs are always on average. They don't make sense on a single data point. An attacker may always get lucky and find the right password on his first try. This is merely improbable.
If you generate passwords as sequences of purely random characters, ...
You can attack these using the Z3 theorem prover. I've implemented such an attack in Python in order to predict values in a lottery simulator.
As mentioned previously, XorShift128+ is used in most places now, so that is what we are attacking. You begin by implementing the normal algorithm so you can understand it.
def xs128p(state0, state1):
s1 = ...
It seems to me that your calculations are correct. Even though, please consider the following weaknesses:
An attacker can and will sign up for your service with multiple (a LOT of) accounts. From there, it is trivial to create a close-to-original word list. So assume the attacker knows the word list.
The attacker will also test your password length ...
I wrote an answer which describes in detail how getrandom() blocks waiting for initial entropy.
However, I think that he slightly oversells urandom by saying that "the only instant where /dev/urandom might imply a security issue due to low entropy is during the first moments of a fresh, automated OS install."
Your worries are well-founded. I have an ...
This is too long for a comment.
I believe there is a flawed premise in your question:
on modern (and even not so modern) computers, it would be trivial to output hundreds of megabytes per second using ChaCha8 or AES-CTR
You are thinking of a desktop browser on an AC connected machine or a laptop with a big honkin 10Ah battery.
We live in an ...
As root, just do this:
mknod /dev/random c 1 9
Now /dev/random will actually access the same underlying logic as /dev/urandom.
After this change, both /dev/random and /dev/urandom will draw from the non-blocking pool. The non-blocking pool will draw from the blocking pool, which the system will still fill.
Short answer: To prevent brute forcing the CSRF token.
Let's take a trivial example: let's say your token is a single digit, accepting values from 0 to 9.
Now sure, an attacker cannot read this value from the cookie or header, but she does not have to - she can just have the attack send 10 CSRF requests, one with each possible value. One of them will be ...
Reading bytes from a device can be troublesome (you have to account for syscall specificities, e.g. interrupted system calls) and can potentially be inefficient if reading many small chunks (a syscall has a non-negligible overhead). A custom software PRNG, seeded with bytes from /dev/urandom, gives more control over performance.
(Also, there might be a bit ...
First of all, to answer your question directly: This cannot be done. It is purposefully not allowed.
You can, in fact write to /dev/random and it will mix your input into the random pool, potentially improving the quality of the output. But it won't update the entropy_count and unlock /dev/random for reading, because that would be cheating. Otherwise you'd ...