9 ms·
Ok, we know that Math.random() is bad, and they recommend using window.crypto.getRandomValues(). But the docs for getRandomValues() raise concerns too: - getRa
by Tempest1981 5y ago
Ok, we know that Math.random() is bad, and they recommend using window.crypto.getRandomValues(). But the docs for getRandomValues() raise concerns too:
- getRandomValues() is not guaranteed to be running in a secure context.
- There is no minimum degree of entropy mandated by the Web Cryptography specification
- User agents are instead urged to provide the best entropy they can when generating random numbers, using a well-defined, efficient pseudorandom number generator built into the user agent itself, but seeded with values taken from an external source of pseudorandom numbers, such as a platform-specific random number function, the Unix /dev/urandom device, or other source of random or pseudorandom data.
From https://developer.mozilla.org/en-US/docs/Web/API/Crypto/getRandomValues https://developer.mozilla.org/en-US/docs/Web/API/Crypto/getR...
Is there a better solution?
- Scaevolus 5y agoBeing able to call getRandomValues from HTTP endpoints doesn't specifically break a password extension unless it was somehow serving over HTTP and had its Javascript modified. It doesn't mandate entropy requirements, probably because that's a somewhat contentious measure that not all OSes provide information about (see also: the long and tedious arguments about merging /dev/random and /dev/urandom). As long as the browsers use the underlying OS primitives, it will be fine. Browsers do a thousand things essential for security that are far harder than providing cryptographically random numbers, and I highly doubt they'll screw it up.
- deleted 5y ago[deleted]
- dchest 5y agoThere is no better solution for the client-side web. getRandomValues() generates cryptographically secure random bytes in all current popular browsers.
- omegalulw 5y agoSide question: what are cryptographically secure random bytes? I assume that with random bytes all we care about is that they are random. And since it's impossible to tell if any finite sized output is random or not, I suppose we simply show randomness with statistical significance tests. But how, precisely?
- marshray 5y agoPassing statistical tests is the lowest, most basic, requirement for cryptographic RNGs. Beyond that, you need to prove that no other party (i.e., the 'attacker') can predict the output any better than random chance, even if they've seen all the output leading up to it. Beyond even that, many CSRNGs attempt to recover from 'state compromise': even if a snapshot of all the contents of the secret state get leaked somehow the system will soon return to producing secure output.
- speedgoose 5y agoIf you don't fully trust getRandomValues, you can collect entropy in JavaScript and then hash everything you got using something like Blake2b. Touch/mouse inputs time and positions can give a few bits of entropy for example.
- dchest 5y agoI can't imagine a situation when you don't trust getRandomValues, but trust touch/mouse inputs. If your getRandomValues is untrusted, why would you trust the whole JS runtime that implements it? If you think there's a Debian-like bug with the system PRNG, then you can't even trust the TLS connection that downloaded your JS code.
- speedgoose 5y agoI think it's possible that TLS is functional, but getRandomValues is hacked/broken. A popular browser extension sold or given away to a hacker could inject everywhere the following code for example: window.crypto.getRandomValues = (arrayBufferView) => arrayBufferView.fill(4); For sure using more entropy from JS will not do much in case of a targeted attack that did compromise the downloaded code or the runtime, but the scenario of a larger scale attack on WebCrypto is what I was thinking about.
- dchest 5y agoIf an extension can modify getRandomValues, then all your other code is also untrusted, you can't work around it by using other methods to generate randomness.
- speedgoose 5y agoI know. But the likelyhoood of a targeted attack on my code is much lower.
- CJefferson 5y agoThis is one of those areas where security in depth is a good idea. Gather all the sources of random sources you can and hash them together -- add in any information based on user input (key presses / mouse movements), and personally I'd provide each users with a securely generated random 1K string (which could be sent once at install) to provide more random data.
- htrp 5y agoI like cloudflares solution for entropy. A webcam pointed at a wall of lavalamps in their HQ https://www.cloudflare.com/learning/ssl/lava-lamp-encryption/ https://www.cloudflare.com/learning/ssl/lava-lamp-encryption...
- Tempest1981 5y agoCool, but why are they on public display? Sufficiently hard to hack as-is?
- wlonkly 5y agoYou said it yourself: "Cool"
- dchest 5y agogetRandomValues() already takes input from keyboard and mouse interrupts (via the OS PRNG) and lots of other sources, no need to create own bug-ridden implementations of the same thing.
- CJefferson 5y agoThat's true for good implementarions, but is it true for all implementations? I don't know, but I'd be worried about it.