Timeline for Why is Math.random() not designed to be cryptographically secure?
Current License: CC BY-SA 3.0
23 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 24, 2018 at 2:07 | history | bounty ended | Conor Mancone | ||
| Mar 23, 2018 at 9:16 | comment | added | Voo | @Buge I was thinking of a shared source of randomness (say a hardware module). But you're right that that wouldn't work if you had two sequences. | |
| Mar 23, 2018 at 8:18 | comment | added | Buge | @Voo If " the bottom bit of the output is random, but independent of the seed" then it isn't a CSPRNG. A CSPRNG requires that if you have no knowledge of the seed, then the output of the CSPRNG is indistinguishable from true randomness. But this bad PRNG is fairly easily distinguishable from true randomness even with no knowledge of the seed. Simply check if the bottom bit follows the pattern. | |
| Mar 22, 2018 at 10:12 | comment | added | Voo | @Buge The reasoning Martin uses applies to CSPRNGs. Not particularly good ones mind you, but then most CSPRNGs used by mainstream languages are anything but amazing. | |
| Mar 21, 2018 at 11:08 | comment | added | Patrick Roberts | I was going to provide a very similar answer that played on the same themes mentioned here, basically the short, unsatisfying version of which is "the specification doesn't require it, so implementations don't need to make it cryptographically random" | |
| Mar 20, 2018 at 21:14 | history | edited | Eric Lippert | CC BY-SA 3.0 |
added 74 characters in body
|
| Mar 20, 2018 at 14:33 | comment | added | user121968 | An excellent, informative answer. The “opportunity cost” is probably the only real explanation needed, but everything else is a real treat | |
| Mar 18, 2018 at 10:59 | review | Suggested edits | |||
| Mar 18, 2018 at 12:02 | |||||
| Mar 18, 2018 at 4:28 | comment | added | Buge | @forest I should have limited my statement by saying "If it is not a CSPRNG (just a plain PRNG) then you should never use it for security unless you are a cryptography expert." Just as a crypto expert can create a new cipher using insecure primitives such as addition, xor, and multiplication, a crypto expert can also create a new CSPRNG using PRNGs. And just as a layperson should never create a new cipher using insecure primitives, a layperson should never use a PRNG for security. | |
| Mar 18, 2018 at 4:22 | comment | added | Buge | @MartinBonner I thought Eric's comment was talking about CSPRNGs, because this is security.stackexchange.com and both the question and Eric's answer were talking about CSPRNGs. | |
| Mar 17, 2018 at 0:31 | comment | added | forest | @Buge Actually, sometimes mixing multiple bad PRNGs together can actually give you a decent cipher, at least if done correctly. For example E0 (the cipher used by in all but the newest Bluetooth protocols) involves four LFSRs. Each individual LFSR is trivial to break, but E0 itself is a good bit stronger (but still not great). | |
| Mar 16, 2018 at 21:39 | comment | added | anon |
@EricLippert I think it's worth adding a concrete example to this answer of C#'s abusable Random. Something like this (pseudo)code: while (something) { int rand = new Random().nextInt(); doSomething(rand); } -- That fails because C#'s Random uses the current time with course resolution as the seed, so if doSomething is fast, you'll get the first number in the sequence with whatever that time's seed is, over and over again, rather than different ones. (I know you know this; I'm explaining for the people who didn't work on C# with Microsoft)
|
|
| Mar 16, 2018 at 11:40 | comment | added | usr | Yes! Why are all random APIs on all platforms so messed up? I guess teams go "let the intern do this". | |
| Mar 16, 2018 at 11:19 | comment | added | Martin Bonner supports Monica | @Buge: It is quite easy to imagine a (not very good) RNG which generates integers, and where the bottom bit of the output is random, but independent of the seed. If you add the output of two such instances (independently seeded), the result would always be even. (Eric's point had nothing to do with security - I don't know what made you think it had.) | |
| Mar 16, 2018 at 10:52 | comment | added | Buge | @EricLippert I don't understand your 2 streams with different keys added together example. If it is a CSPRNG, then I would think that should be ok. If it is not a CSPRNG (just a plan PRNG) then you should never use it for security, even if you just have a single instance. | |
| Mar 16, 2018 at 3:36 | vote | accept | forest | ||
| Mar 16, 2018 at 3:35 | comment | added | forest | I think this is the best answer here so far, especially as it's from such an authoritative source. I'll mark this answer as accepted for now unless a better answer comes along. | |
| Mar 16, 2018 at 3:32 | history | edited | forest | CC BY-SA 3.0 |
small improvements
|
| Mar 15, 2018 at 18:48 | comment | added | VisualMelon | Thanks for elaborating: I suppose I'm wary enough to not try using any source from multiple threads unless it is clearly documented for that purpose so I'd never notice. I'm not sure that the last point is a specific concern for any 'implementation' rather than the algorithm behind it: I don't think we can hold the API designers accountable for that! | |
| Mar 15, 2018 at 18:41 | comment | added | Eric Lippert | @VisualMelon: There are also more subtle scenarios. Suppose you have two instances of Random with different seeds. Seems fine, right? But suppose you then combine those two instances of Random in some way. Maybe you are using them to each produce a sequence of die rolls and add them together pairwise. Are the two sequences correlated with each other in some non-random way? It seems plausible. After all, they're running the same algorithm "in parallel", just with a different seed. | |
| Mar 15, 2018 at 18:36 | comment | added | Eric Lippert | @VisualMelon: Create a thousand instances in a tight loop is the classic. But there are also failure modes when you use one instance of Random on two threads at the same time. Random is not threadsafe and there is a scenario where a race can cause it to return zero forever! | |
| Mar 15, 2018 at 18:12 | comment | added | VisualMelon | (Bit off topic) Would you mind providing a reference for "the .NET Random class can trivially be misused in multiple ways to produce long sequences of the same number is awful"?: I've not heard of this before, or are you referring to the classic "create a thousand Random instances in a tight loop"? | |
| Mar 15, 2018 at 15:10 | history | answered | Eric Lippert | CC BY-SA 3.0 |