Timeline for Why is Math.random() not designed to be cryptographically secure?
Current License: CC BY-SA 4.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 23, 2023 at 21:18 | history | edited | Jared Smith | CC BY-SA 4.0 |
deleted 1 character in body
|
| Apr 2, 2018 at 11:24 | comment | added | forest | @BenVoigt Oh huh, I could have sworn that the Tj Max for desktop CPUs is much lower than that of laptops. I must have remembered incorrectly. | |
| Apr 2, 2018 at 4:33 | comment | added | Ben Voigt | @forest: It isn't that a desktop CPU can safely tolerate more temperature (it can't, although the limit is usually similar to a mobile CPU, say 90, 95, or 100C). It's that most desktop CPUs are installed with efficient cooling such that they can run full tilt running cryptographic operations and still stay relatively cool, perhaps 60C. You simply can't fit that cooling solution in a handheld device, among other reasons because it weighs more and is larger than the rest of the phone and only works with air vents and airflow, unacceptable for a water resistant handheld that may be in a bag. | |
| Mar 22, 2018 at 18:14 | comment | added | supercat | @JamesKPolk: If there's any possibility a CSPRNG's state has been exposed, it's necessary to reseed it with a source of entropy independent of any previous one, but if one has a good CSPRNG with e.g. 4096 bits of state seeded with e.g. 160 bits of "pure" entropy, and never gets exposed, are there any attacks that would be practical that would not be practical if it were seeded with 4096 bits of entropy? | |
| Mar 22, 2018 at 13:13 | comment | added | akostadinov | browser can happily use the random data produced by OS | |
| Mar 21, 2018 at 19:38 | comment | added | President James K. Polk | @CodesInChaos: The difference in generating bytes is probably small, but no one seems to have mentioned the harder part of a CSPRNG: collecting entropy. | |
| Mar 20, 2018 at 5:40 | comment | added | forest |
@CodesInChaos Given that Math.random() only returns individual floating point values and has to be called for each new value, it would be a rather terrible way to get randomness for Monte Carlo simulations, regardless of whether or not XorShift128+ or ChaCha is used. Also the LSB of XorShift128+ is an LFSR which is probably not very good for such simulations.
|
|
| Mar 19, 2018 at 16:13 | comment | added | CodesInChaos | @jb. My point is that crypto RNGs are fast enough for practically any use-case and thus should be the default. Monte Carlo simulations are one of the few cases where you might want to trade quality for performance. | |
| Mar 19, 2018 at 16:08 | comment | added | jb. | @CodesInChaos Technically you don't need cryptographically strong RNG for monte carlo. Any decent RNG will work (like Mersenne Twister). | |
| Mar 17, 2018 at 2:37 | comment | added | forest | Come to think about it, I'm pretty sure a desktop processor reaching 100°C would be very bad. Laptop processors can typically handle it (if just barely), but desktops? | |
| Mar 16, 2018 at 5:35 | comment | added | Derek Elkins left SE | @CodesInChaos People write Monte Carlo Simulations in JavaScript. | |
| Mar 16, 2018 at 3:49 | comment | added | forest | ChaCha8 can provide around 3 cycles per byte on even old processors, and under 1 cycle per byte with AVX512. XorShift128+ is under 1 cycle per byte on a high-end Haswell processor, so the difference is not large. I imagine the mere act of turning the random value into a proper floating point and returning it takes more cycles than generating the random value in the first place. | |
| Mar 15, 2018 at 14:21 | comment | added | Jared Smith | @CodesInChaos that may be true. I'd want to see analytics (especailly on e.g. a port of a CRPG) before making that call. But it's the implicit premise of "computers are fast now so it doesn't matter" that is an issue. | |
| Mar 15, 2018 at 13:51 | comment | added | CodesInChaos | I doubt you'd notice the performance/power consumption difference between crypto and non crypto RNG for typical code, even on mobile. You'd have to write a monte carlo simulation in javascript. We're talking about something like 30 CPU cycles for each number. | |
| Mar 15, 2018 at 12:16 | history | edited | Luc | CC BY-SA 3.0 |
No need to specify milli when you're going to use lots of zeroes.
|
| Mar 15, 2018 at 11:56 | history | answered | Jared Smith | CC BY-SA 3.0 |