[HN Gopher] Should random() be banned?
___________________________________________________________________
Should random() be banned?
Author : pabloest
Score : 44 points
Date : 2021-02-11 17:03 UTC (5 hours ago)
(HTM) web link (r2c.dev)
(TXT) w3m dump (r2c.dev)
| nemo1618 wrote:
| The root problem here is the notion that you need to choose
| between "strong and slow" randomness vs. "weak and fast"
| randomness. If every language's random() was strong _and_ fast,
| most developers would never have to think about it.
|
| "Strong" randomness is often too slow because every time you ask
| for new entropy, you make a syscall. The solution is to use 32
| bytes of strong randomness to seed a userspace CSPRNG. You can
| generate _gigabytes of secure entropy per second_ in userspace.
| If you need deterministic entropy, just use the same seed.
|
| This isn't a one-size-fits-all solution, of course. If you only
| need to generate a few keys now and then, it's marginally safer
| to make a separate syscall for each of them. If you're targeting
| some tiny SoC, then sure, use xorshift instead. But what we care
| about is the common case, and right now the common case is a
| developer choosing the weak, deterministic RNG because it's
| faster and has a more convenient API and the secure RNG says "for
| cryptographic purposes" and well this usecase doesn't _seem_ like
| cryptography, it 's just a simple load balancer...
|
| That decision should never need to be made.
| sobriquet9 wrote:
| The problem is not random() itself, it's constructs like random()
| % n. Even if you replace random() with a CSPRNG, misuse won't go
| away.
| harpiaharpyja wrote:
| TL;DR: The answer is no, and here's how you can find a
| quantitative basis for that decision.
| not2b wrote:
| There are many uses of random() that do not require cryptographic
| security: simulation, simulated annealing, sound synthesis,
| digital signal processing and the like. It would be a nuisance if
| developers of those kinds of software have to fight warnings
| because developers of completely different applications can't get
| it right.
| not2b wrote:
| Further, such users usually want to be able to repeat a test
| case: start from the same seed, get the same sequence. They
| don't want true randomness, they want a repeatable sequence
| with good statistical properties.
| f430 wrote:
| Is it possible to have something like random.org but without
| paying for it?
|
| say you want to build a lottery application, who can you rely on
| to make receive a very good random number generator at low cost?
|
| Should the government provide this for free to developers? Seems
| like its in everybody's interest to have a ~true random()
| function.
|
| Pokerstars uses lasers, someone else uses lava lamps, radio
| waves, what else?
|
| Also on a side note: how much do you think we have truly
| discovered the nature of "randomness"? Nassim Taleb says its not
| random if you run into somebody you know in the supermarket while
| thinking of them. Some physicists have likened it similar to
| newtonian others a more parallelian view. Why is it that some
| natural order emerges out of "randomness" out of a 52 card deck?
| How is it that a randomly swinging spot light in a dark room is
| able to "find" a plant that is also "randomly" placed in the
| room? Or the randomness of people's birth date and time emerging
| in lottery tickets? Or even more controversial, the fact that RNG
| is able to be seemingly influenced by the collective
| consciousness?
| zinkem wrote:
| I most commonly use random() for generating names (e.g. docker's
| container names) and generating test inputs. I don't care about
| cryptographic safety in either case.
| bob1029 wrote:
| It's all about the discipline of the team in the end... You can
| ban things all day, but it just takes 2 developers deciding they
| don't give a shit to code, review & merge that use-fast-random-
| for-session-token PR. There is more than 1 way to get something
| that is "random", so basic string matching for methods you don't
| like is certainly not a guarantee.
|
| In our organization the policy is very simple. We have static
| method available throughout called
| CryptographyService.GenerateCsprngBytes(count = 64). All
| developers are aware that any security-sensitive requirements
| around entropy must use this method. It wraps the OS-level
| offering, and encourages a minimum reasonable level of entropy
| with a default count.
|
| I don't see any reason to make it more complicated than this.
| Communication with your team is more important than writing
| check-in rules to prevent bad things from happening.
|
| As for other uses of Math.Random, et. al., we don't have any
| official policy. Because we have clearly communicated the
| awareness that security-sensitive applications should always use
| the secure method, we don't need to add a bunch of additional
| bandaids on top. Enrich the team before the process.
| pdpi wrote:
| > Communication with your team is more important than writing
| check-in rules to prevent bad things from happening.
|
| There's some subtlety here. This is sort of a security vs
| safety issue.
|
| Some people are just reckless, and that's a human problem that
| is best dealt with through a stern talking to (or, ultimately,
| termination) rather than technical measures. You'd require an
| oppressive amount of check-in rules in place to be even
| remotely effective at stopping this behaviour, and those would
| just make life miserable for everybody else.
|
| Some people are new to the team and/or just plain
| inexperienced, and it takes time for them to absorb all the
| standard practices so they can innocently cause trouble. Even
| veterans will make mistakes. Low friction guard rails can help
| keep those people from getting into too much trouble without
| being too onerous.
| kasperni wrote:
| If any, I would say it should be other way around. There are very
| few use cases outside of cryptography. So flag it if people uses
| a cryptographically secure PRNG directly. In almost all cases
| they would be better off finding a library that does what they
| need.
| zabzonk wrote:
| To answer this, we would need to know what you mean by random().
| You haven't provided any language, library or other context.
| zappsepp wrote:
| Differences would be marginal. Computers are inherently bad at
| randomness.
| draw_down wrote:
| We did essentially that at my employer. I think the rationale is
| good, biasing toward a secure random function makes sense because
| the downside (as I understand it) is performance, but defaulting
| to insecure random has worse downsides. And if there ends up
| being a hot path where secure random is too inefficient, you can
| change it in that case. (This is in a context where a secure
| random function is readily at hand, when that's not the case, it
| could be trickier.)
| ThePadawan wrote:
| I'm not big on bans.
|
| What I am big on is forcing developers to make deliberate
| choices. That's why I like React's policy of naming functionality
| "dangerouslySetInnerHTML" or
| "__SECRET_DOM_DO_NOT_USE_OR_YOU_WILL_BE_FIRED".
|
| If you add usages for these in a PR I'm reviewing without
| justification, it's not getting merged.
|
| So why not make cryptographically unsafe random unsafeRandom() or
| shittyRandom() or iCopyPastedThisFromStackOverflowRandom()?
| suzzer99 wrote:
| I have required parameter to push our app to production called:
| YES_I_HAVE_ALREADY_MERGED_THE_LIB_REPOS_AND_WAITED_FOR_THEM_TO_
| COMPLETE_BEFORE_MERGING_THE_APP_REPOS
|
| Gets the point across and will still work when I'm long gone.
| [deleted]
| zrm wrote:
| It's also a good idea to give safer things shorter names.
|
| So make random() a CSPRNG (and an alias for SecureRandom() for
| people who want to be explicit) while InsecureFastRandom() is
| just what it says and has no other name. Then if you really
| need performance over unpredictability, it's there, but nobody
| is confused about what they're getting. And lazy people who
| don't like to type or pay close attention get the safe one.
| cogman10 wrote:
| That's be my preference.
|
| random() should be the most universally applicable random
| which includes making it as secure as possible. Non-
| universally applicable randoms should be named accordingly.
| njharman wrote:
| Most simulations, games, everything that isn't generating
| cryptography does not need security in it's random.
|
| For most domains secure random is a niche, not universally
| applicable.
| tedunangst wrote:
| So a simple linear generator is fine for an online poker
| game?
| btilly wrote:
| The claim that most uses of random() are not in places
| where cryptographic security is needed is not in conflict
| with any list of examples where it is needed.
|
| Here are the last several times I saw random() used.
|
| Seeding a neural network for a Coursera course. Not only
| do you need to call random() a bunch of times, but the
| ability to set a seed and get deterministic results makes
| grading of the results massively easier.
|
| Creating simulation data used for integration tests on a
| piece of software.
|
| Picking a few random numbers that I used in an
| explanation of an answer.
|
| Of course the plural of anecdote is not data. However in
| my corner of the world it is very rare to need
| cryptographically secure anything. And when I do, I know
| better than to code it myself. But it is common to need a
| lot of cheap numbers in a hurry.
| Sohcahtoa82 wrote:
| Well of course an online poker game should be using a
| CSPRNG.
|
| The parent comment said " _Most_ simulations, games ...
| ". Most. Not all. I think it's pretty obvious that Poker
| would not be included a statement of "Most".
|
| The real litmus test is the question of "What happens if
| a malicious actor is able to predict the random numbers?"
| tedunangst wrote:
| The claim was that everything that isn't generating
| cryptography does not need security.
| epanchin wrote:
| And one would hope secure devs know which random to use,
| whereas gaming devs have no reason to know.
| josephg wrote:
| Look up "password generator" or similar terms on npm and
| take a look at how the packages you find generate random
| numbers. I did this ~5 years ago and it took until the
| second page of results before I found any packages that
| used a crypto-secure rng.
| esrauch wrote:
| Even that seems unlikely to be problematic for anything
| short of literally constant seeds AND a generator
| becoming extremely popular.
|
| The vast majority of people reuse low-entropy passwords,
| figuring out what password generator someone used would
| be a much higher bar than figuring out passwords, and
| just knowing the insecure generator wouldnt reduce the
| entropy by that much.
|
| Actually, a password generator on GitHub that generates
| the password that is literally just seconds-since-1970
| would still be a good generator for almost all use cases.
| SomeCallMeTim wrote:
| Actually, in my experience using the default random
| implementation in games:
|
| * It's not fast enough. * It has patterns that can be
| seen if you are using it to, for instance, generate 2d
| noise.
|
| So for games you'd typically use, say, the Mersenne
| Twister [1], which is faster (amortized) and is
| distributed evenly across 623 dimensions. [2]
|
| It's not cryptographic, but it's far better for games. If
| you're not going to have a crypto default random, better
| to at least have a really good and really fast one.
|
| [1] https://en.wikipedia.org/wiki/Mersenne_twister
|
| [2] http://www.math.sci.hiroshima-u.ac.jp/m-mat/MT/ARTICL
| ES/mt.p...
| Spivak wrote:
| So you're not big on bans but if you use
| dangerouslySetInnerHTML then it's definitely not getting
| merged? Is that not a ban? Do you just not like when tooling
| enforces it?
| [deleted]
| dariusj18 wrote:
| They said "without justification"
| ThePadawan wrote:
| No, as I said, it would raise a red flag. That flag can be
| lowered by justification, e. g. if you add types or
| constraints to only allow safe-enough parameters etc.
| [deleted]
| shadowgovt wrote:
| I agree, with the caveat that use of random for cryptography is
| actually a domain specific use case.
|
| It's probably okay to leave the function as it is and just
| drill into people that if you're doing cryptography, you either
| need to know exactly what you're doing all the way down to the
| hardware or you need to leave it a task for somebody else more
| specialized than you. I, for one, never assume random() is
| cryptographically secure, but it might be because I grew up
| programming during the era where random was computed off of
| clock cycles since CPU startup because there wasn't much other
| cheap entropy to lay a hand on ("battery-backed onboard date
| clock?! Oh, look who has AKERS money!").
| sp332 wrote:
| The "ban" can be evaded by telling semgrep to ignore it for one
| line. https://semgrep.dev/docs/ignoring-findings/ This doesn't
| really scale though - if someone bans it with a different tool,
| you'd have to tell each tool to ignore this line.
| iratewizard wrote:
| Beginner friendliness is something to remember, too. There are
| half a dozen words you could use to describe pseudoRandom().
| Random() is easy for a first year or non-professional to
| remember.
| dariusj18 wrote:
| Most of the time the people who write and name the functions
| don't know it's not secure or safe. So you would still need to
| ban random when the new name is implemented.
| Macha wrote:
| This assumes writing crypto code is the most common use case
| for random numbers.
|
| How often do you write crypto code?
|
| vs
|
| How often do people use random numbers + threshold for A/B
| tests? How often do game developers use random numbers for
| gameplay variety? How often is random used for animation
| variety? Do these use cases need the overhead of a cryptography
| RNG?
|
| A former employer had the same issue as in the article - the
| security team implemented an automated vulnerability scanner in
| our github enterprise instance, and it spammed comments and
| marked a review as requiring changes if it edited any merge
| request which touched a file which used java.util.Random. It
| lasted a day before the security team was made turn it off as
| on our team (and many others), literally 0 uses of random
| numbers were those requiring a secure random.
| jcelerier wrote:
| > It lasted a day before the security team was made turn it
| off as on our team (and many others), literally 0 uses of
| random numbers were those requiring a secure random.
|
| can concur, currently approaching 400k SLOC of C++ in the
| repo. A few dozens different places crop up where random is
| needed (with a quick and dirty grepping). Literally 0% is for
| secure stuff. Most of it has to be as fast as possible (and
| very low quality, as it just needs to be random / noisy
| enough to look random for human perception)
| FalconSensei wrote:
| Also: if someone is working on crypto and doesn't know that
| random() isn't true random, should they be working on that?
| 1MoreThing wrote:
| The creation of a trueRandom function certainly seems to
| solve this problem more than taking away a useful tool for
| cases where pseudo-random is good enough.
| ddlsmurf wrote:
| Indeed this is a stupid debate. Knives help us in the kitchen
| but also sometimes stab people - should we ban knives ?
| nicoburns wrote:
| React's dangerouslySetInnerHTML is indeed a good way of
| handling this kind of thing. Rust's `unsafe` is another example
| of the same approach.
| mannerheim wrote:
| accursedUnutterablePerformIO
|
| https://hackage.haskell.org/package/bytestring-0.11.0.0/docs...
| cpeterso wrote:
| Firefox has a secret setting used in test automation called "tu
| rn_off_all_security_so_that_viruses_can_take_over_this_computer
| ".
|
| https://searchfox.org/mozilla-central/rev/3ff133d19f87da2ba0...
| makomk wrote:
| Yeah, and if I remember correctly one neat technique for
| exploiting security vulnerabilities in Firefox was to use
| them in order to set turn_off_all_security_so_that_viruses_ca
| n_take_over_this_computer to true, with obvious results.
| wnevets wrote:
| hmm I wonder what would happen if I enable this setting...
| throwaway744678 wrote:
| *** wnevets quit (Connection reset by peer)
| drewcoo wrote:
| Flag it, sure, but don't ban it, bro!
|
| It is extremely useful for testing. It keeps this code simple and
| simpler tests are less buggy. Randomize a bunch of choices in
| input ranges and run a test. Need to re-run that exact scenario?
| Just set the seed to the same as the first go.
| duxup wrote:
| > Isn't random() often used for non-cryptographically sensitive
| operations?
|
| I was wondering just that, a little disappointed that there's no
| answers for anything in the article.
| antonyh wrote:
| It certainly is in my experience: everything from
| deterministically shuffling lists to Rogue-like map generation
| to audio/visual glitch & noise effects.
| cryptica wrote:
| I hate how bloated software development has become nowadays and I
| hate all these tools which keep raising warnings about
| vulnerabilities which are not relevant to the use case.
|
| It's unbelievable that we live in a society where we're
| absolutely obsessed about achieving 100% test coverage of all our
| small petty software systems but our monetary system itself (the
| mother of all systems) is not even integration tested the
| slightest... What's worse about the monetary system is that
| vulnerabilities don't even get patched after decades of active
| exploits! The software industry is a joke, rife with ignorance
| and hypocrisy.
| tiborsaas wrote:
| Meanwhile in graphics programming land: float
| rand(vec2 co){ return
| fract(sin(dot(co.xy,vec2(12.9898,78.233))) * 43758.5453);
| }
| LolWolf wrote:
| Honestly, the one thing that got me into graphics (from physics
| and math) was just the incredible amount of: "you can literally
| do _anything_ so long as you make it pretty in the end. "
|
| I took that as a life philosophy and it's been pretty great so
| far.
| madsbuch wrote:
| Is there something I am overlooking here? Randomness is used for
| many other things than cryptographic usages.
|
| Eg. for randomised algorithms you need a fast source of
| randomness.
| magicalhippo wrote:
| As much as it's overkill for most people, I'm a fan of safe
| defaults so I say let random() be slow and good. It's better to
| find out your code is slow due to a slow random() than to find
| out it's broken because you didn't know and thought random()
| was really random.
|
| If you need a fast source of randomness, for some Monte Carlo
| algorithm for example, then you know this and can pick a
| deliberate pseudo-random generator that fits your needs.
|
| I worked on a Monte Carlo path tracer. Early on we swapped out
| the random number generator from the standard random().
| Initially not for speed, but due to the poor distribution.
|
| After optimizing other areas it became a bottleneck and we
| swapped it out again for a faster one.
| hannob wrote:
| The cryptographic randomness has practically no downside if you
| use it for non-cryptogrpahic purposes. Not true the other way
| round. And I'm inclined to say given how many misconceptions
| around randomness there are around, I don't think people are
| good at knowing whether they need secure randomness.
|
| The only possible justification for insecure randomness would
| be performance, but you'd need to generate a lot of random
| numbers to even be able to measure that.
| gwbas1c wrote:
| > The cryptographic randomness has practically no downside if
| you use it for non-cryptogrpahic purposes
|
| Cryptographic randomness is typically slower than other forms
| of randomness.
|
| In all of the programming I've done in my career, I've only
| needed cryptographic randomness a few times. For the rest, a
| fast pseudorandom number generator seeded by the clock was
| the correct choice.
| pdpi wrote:
| Inversely, in my career there's only been a handful of
| times where cryptographic randomness was too slow.
|
| I'd argue it's better to do the safe thing by default and
| switching to the faster alternative when you have proof you
| need it. Doing the fast thing by default and fixing
| security later is how we got Meltdown/Spectre.
| mreome wrote:
| It's going to depend on your experience, for me I have
| often run into the exact opposite extreme... where the
| _non-secure_ random is to slow for my uses-cases (games,
| graphics, procedural texture gen, etc) and a much faster
| but less statistically random generator better suited my
| needs.
|
| I would argue that the default behavior should favor the
| novice and non-domain-expert. Should game programmers,
| graphic programmers, etc, be expected to know that they
| need to tune the performance of random() or should the
| domain-experts writing cryptographic algorithms be
| expected to understand the limitations of random() as it
| applies to their use-case?
| Nullabillity wrote:
| Which has the worse consequences for misuse?
|
| The game programmer who needed better performance can
| "just" switch to a faster algorithm when the profiling
| calls for it (and if you don't notice it, well, no harm
| anyway).
|
| The guy who just needed to generate some cryptographic
| keys? Rotate everything, and you had some pretty horrible
| hidden vulnerabilities in the meantime.
| mreome wrote:
| My counter would be that if someone "doesn't know whether
| they need secure randomness" then the problem is not that
| random() is not secure, it's the fact that someone is doing
| something they really should not be doing in the first place.
| duckerude wrote:
| It is. The question was how often that's the case. If 50% of
| the uses of random() are bad, then getting those fixed may be
| worth the cost of annoying the authors of the legitimate 50%.
|
| It turned out to be much less useful than that. So they got rid
| of it.
| otabdeveloper4 wrote:
| No, you are not.
|
| Cryptographic random() is an extremely niche use case that you
| shouldn't be using unless you're writing your own crypto
| libraries. (Don't do that.)
| jcranmer wrote:
| That's not true.
|
| To answer the question as to when you should use
| cryptographic random(), ask yourself "What is the worst that
| could happen if someone guesses the result of random()?"
|
| If the answer is "I don't know," go cryptrographic. You'll
| save your butt if you didn't know it was important.
|
| If the answer is along the lines of "someone could
| impersonate a user, or leak information they shouldn't see,"
| for the love of all that is holy, _use cryptographic_. This
| is basically every scenario where you are using random to
| generate an ID of some kind, and while it 's only truly
| critical if that ID is all you need for validation, it does
| provide another layer of security even if you also require
| other information to match before giving out elevated access.
|
| If the answer is "it defeats the algorithm I'm trying to do"
| (think something like ASLR, where you're randomizing the
| offsets of addresses so that attackers don't know where
| things are located), well, the reason why you need to use
| cryptographic should be blindingly obvious.
|
| If the answer is instead "they can reproduce my results,"
| well, you shouldn't use cryptographic in this case. And
| that's not a lot of cases: Monte Carlo simulations, testing,
| fuzzing are the obvious poster children for this category,
| and indeed reproducibility in these cases tends to be a
| highly valuable feature rather than an anti-feature.
|
| Cryptographic random is almost never harmful to your
| application, and almost always provides some benefit in
| reducing guessability of your system. You should err on the
| side of using cryptographic random(), and only not use it
| when you are sure that guessability will not harm security in
| any way and you know that the cryptographic nature actively
| harms your application.
| mreome wrote:
| I would argue that if you're asking yourself "What is the
| worst that could happen if someone guesses the result of
| random()?" and your answer is "I don't know," then you're
| doing something you shouldn't be doing.
|
| There are a lot of domains where security is a non-issue
| and performance is a huge concern (graphics, game logic,
| many kind of simulations, etc), and the default is the
| reverse... always just use the installed non-secure
| random() and if that's _too slow_ consider other options.
|
| Having a flag you can enable to warn about a non-secure
| random() usage, when it makes sense for your company/usage,
| sure. But banning it outright makes no sense, and the
| default behavior you want is very situational.
| jcranmer wrote:
| When it comes to optimization, there's a useful adage:
| make it work, then make it fast. Secure should really be
| seen as a necessary component of correct (and that it
| often isn't is a testament to the failure of our
| profession).
|
| In that vein, the _default_ random should be
| cryptographically-secure, with all the logic necessary to
| actually effect that security (e.g., not reusing seeds
| after a call to fork). You can also go ahead and provide
| an insecure random as well, but choosing the insecure
| random should always be something that the programmer has
| to go out of their way to do.
| mreome wrote:
| Secure should really be seen as a necessary component of
| correct _security._ I don't see random() as part of
| security, and the problem is that people use it as such
| (that's the failure of our profession as I see it). You
| wouldn't want the _default_ string equality operator to
| be constant time to prevent a possible timing attack, and
| in the same way I don't think random() should be
| cryptographically secure by default. If you need secure
| random values, you are (should be) a domain-expert and
| should be selecting an appropriate cryptographically
| secure random generator from a security library, in the
| same way you would with a constant-time equality
| function.
|
| I guess it's a matter of perspective over _who_ random()
| is for. I see random() as for the programmers who don 't
| know what kind of randomness they need, and don't _need_
| to know that because they just need something 'random'
| not something secure. I expect the domain-experts to know
| that it's not what they need. In my mind it's not that
| random() is not secure, it's that using it for something
| it's not intended for is insecure.
| chmod775 wrote:
| >When it comes to optimization, there's a useful adage:
| make it work, then make it fast.
|
| When you need something to be fast, you better design it
| from the start to be fast. This is terrible advice for
| everything but some UI/web cases.
|
| Speed is a feature. Not every feature can be just 'added'
| to existing code without changing most of it.
|
| All of that is _especially_ true for running simulations
| and the like. Whether these are fast is often determined
| by the architecture you decided on in the beginning.
|
| Nowadays the world is full of libraries, frameworks, etc.
| that will never be as fast the competition, because they
| can't become fast without changing their APIs completely.
| stickfigure wrote:
| Server-side folks generate random identifiers and shared
| secrets all the time. Yes, it's niche, but not "extremely"
| and you don't use a crypto library for this (you use secure
| random!)
| mreome wrote:
| There is a difference between _generating_ these kind of
| IDs and _writing the generator_ for these kinds of IDs. You
| shouldn 't be rolling your own UUID generator if you don't
| fully understand the concerns/requirements in regards to
| your source of randomness.
|
| Generally speaking, I'd agree the need for a
| cryptographicly secure random is niche in that it is
| limited to the implementation of specific
| libraries/functions that despite being widely used, should
| NOT be frequently re-implemented.
| josephg wrote:
| I do this in nodejs all the time for IDs:
| require('crypto').randomBytes(15).toString('base64')
|
| Is this bad practice? Can you say more about why?
| tedunangst wrote:
| What bad things will happen if I use cryptographic random for
| a non niche use case?
| madsbuch wrote:
| It is expensive to increase entropy of a random source. So
| for randomised algorithms you might not get the performance
| that merited the algorithms in the first place.
| mreome wrote:
| It's not that you _shouldn 't be using_ it necessarily, it's
| just that for many cases (games, procedural generation,
| graphics, many kind of simulations) it's unnecessary and
| slow. In my experience if someone doesn't know if they need a
| cryptographicly secure random(), or if a given random()
| implementation is secure then they (a) don't need it or (b)
| are trying to implement something they shouldn't be.
| analog31 wrote:
| Indeed, I use something like it from a vendor supplied C math
| library for a noise generator on an embedded app, where I
| really just care about its crude statistical behavior.
|
| But short of saying "banned," any review of security critical
| code should include an explanation of where the random numbers
| are coming from and why they're trusted. Or in general for any
| code review: Why do you believe your numbers?
| antonyh wrote:
| Seeded random is a glorious thing in the right circumstances. As
| an example, I've used it for 'random' testing sequences (jumbling
| up a list of inputs) but in a way I can later re-run EXACTLY the
| same test.
|
| It's also useful for other data generation tasks where the output
| can basically be saved as a seed, making it lightweight and easy
| to store - it could be written it on a scrap of paper in seconds.
|
| Maybe it's a bad name though - it should be called seededRandom()
| or semiRandom() or deterministicRandom(). Or perhaps it should be
| true random is no seed is set. Hard to know. Maybe the true
| random only needs to be the seed to a deterministic random and
| reset on a frequent basis in some cases.
|
| Then there's the category of casual random that doesn't matter,
| like random colours just for the sake of it. It doesn't need to
| be a secure safe random.
|
| And... assuming that any random function is truly random is a
| mistake anyway. Basing on hardware, and it may fail. Base it on
| software and where's the source of entropy. Add to that the
| possibility of bugs/defects in the implementation, and it's
| possible that it might not be as random as it needs to be. It's
| better to assume ALL RNGs are PRNGs, with the caveat that some
| are decidedly better than others.
|
| So no I wouldn't support a ban on it, nor would I support
| removing it from any language/runtime where it might be useful.
| argvargc wrote:
| notRandom() might be usefully descriptive in this case.
| dbcurtis wrote:
| Came here to say this. I have spent a lot of time in hardware
| validation. Pseudo-random (explicitly NOT random) sequences are
| hugely useful.
|
| I once had a lights out server room of 60 servers whose entire
| purpose was to take skeletonized tests and a seed for a pseudo-
| random function and generate a test instance. That test
| instance went to one of a dozen test jigs. What was recorded
| was: pass/fail, the git sha of the template, and the seed. Any
| failing test could be reproduced at any time from just the git
| sha and the seed. True random would have killed that whole
| methodology.
| CivBase wrote:
| Most static code analysis tools I've used allow you to write
| exceptions for rules into your code using comments that follow a
| particular signature. Isn't it sufficient to just ban the use of
| random() and require devs to use one of those comments to
| effectively "sign off" on it if they encounter a good use case?
| wilsonthewhale wrote:
| No mention of arc4random(3)? Seems like a solved problem in BSD
| land.
|
| The key takeaways I feel like are: 1. You want as simple of an
| interface as possible. arc4random(3) returns a single random 32
| bit integer, or you can tell it to fill a buffer with them. 2.
| Just make it cryptographically secure. arc4random does it and it
| seems to be fine.
| nosefrog wrote:
| As an aside, I've worked with Dev Akhawe at Dropbox. Smart guy,
| knows his stuff :)
| f-word wrote:
| "Banning" language features that are only "banned" when a linter
| is placed as a roadblock between the developer and the versioning
| system have to be the dumbest thing us developers have inflicted
| upon.
|
| How is this preventing me from recreating my own shit `random()`
| when it's entirely too late in the evening, deadlines are looming
| and the garbage office politics preclude me from disabling this
| asinine thing?
|
| I used to regularly trip on this damned reified rituals where
| we're only supposed to use a single type of quotes, or maybe
| using short vars like `i,j,k` on for loops and other garbage
| "rules" that might have sounded great when originally put in
| place but are horrible on a day-to-day basis.
|
| There's also the behavioral cost, I've noticed more and more
| people simply don't the code in code reviews anymore. Most
| feedback I get these days is stuff like "that's not supposed to
| be snake_case" or "a single space should be put between methods",
| and sometimes a glaring logic bug will crop up after 3 or 4
| people who "approved" the review will gladly and openly admit
| _they_ _did_ _not_ _read_ _the_ _code_, and I think this is
| related to us overstressing the importance of all this tiny
| "form" misshaps and disregarding the "function" bits because it's
| harder to write a roadblock that checks for them.
| klodolph wrote:
| "Fix rate" is an interesting metric, but I don't think it's a
| good proxy for engineering value.
|
| When I see a false positive flagged by a compiler warning or
| static analyzer, sometimes I'll fix it just because I'm not sure
| I want to turn off the rule. For example, I often use -Wunused-
| parameter with -Werror with Clang or GCC, and then just use
| (void)arg; to silence the false positives.
| admax88q wrote:
| Just make Math.random() cryptographically secure, now all your
| apps are fixed, and no existing code broken. I can't imagine
| anything relying on Math.random() being "less" random than a
| CSRNG.
|
| Why must CSRNGs always have alternative obtuse APIs. We're still
| stuck on C style srand() + rand().
|
| Cryptography is so ubiquitous now that failure to provide
| cryptographically secure random numbers should be viewed as a
| hardware flaw.
| throw0101a wrote:
| Some folks purposely want random-ish results. When OpenBSD was
| changing the behaviour of its legacy POSIX random functions it
| was observed: This API is used in two
| patterns: 1. Under the assumption it provides good random
| numbers. This is the primary usage case by most
| developers. This is their expectation. 2. A 'seed'
| can be re-provided at a later time, allowing replay of
| a previous "random sequence", oh wait, I mean a
| deterministic sequence...
|
| They went through the code, especially the third-party
| packages/ports, to identify uses:
|
| > _Differentiating pattern 1 from pattern 2 involved looking at
| the seed being given to the subsystem. If the software tried to
| supply a "good seed", and had no framework for re-submitting a
| seed for reuse, then it was clear it wanted good random
| numbers. Those ports could be eliminated from consideration,
| since they indicated they wanted good random numbers._
|
| > _This left only 41 ports for consideration. Generally, these
| are doing reseeding for reproduceable effects during
| benchmarking. Further analysis may show some of these ports do
| not need determinism, but if there is any doubt they can be
| mindlessly modified as described below._
|
| * https://lwn.net/Articles/625562/
| nixpulvis wrote:
| Unless I'm wrong, the only valid reason to not use a better
| random number generator is for performance / simplicity,
| which then demands benchmarks and evaluation.
| admax88q wrote:
| This is exactly what I mean about being stuck in the C
| mindset. You're looking at the problem though the lens of
| what this giant pile of ancient C software does.
|
| Why should newer languages take the same approach to APIs
| that these old code bases did? It's not like we're porting
| all those programs to JS. Those C APIs were written long
| before hardware could provide fast good randomness, heck even
| before cryptography was standard practice instead of a
| special use case.
|
| Not to mention in JS you can't even seed the random number
| generator. If you want predictable "random" numbers, you
| should have to jump through additional hoops. By default
| random numbers should be cryptographically secure.
|
| EDIT: It's also worth mentioning that from your reported
| dataset, 41 of 8800 programs analyzed used srand to get a
| repeatable set of "random" numbers. That's 0.47%. I'm happy
| to break less than half a percent of software if it helps
| prevent the far more ubiquitous failures of software using
| insecure random numbers.
| throw0101a wrote:
| I'm looking at the problem through the lens of changing the
| behaviour of an existing API.
|
| If you want to create 'secure' APIs that 'do the right'
| thing, I'm not against it. But leave the old stuff around,
| or mark it deprecated, throwing warnings and errors on
| compilation even, for possible future removal--don't change
| it.
| aeturnum wrote:
| It seems like the "proper" solution to this problem would be to
| make all random number generators pull from the cryptographically
| secure randomness pool by default. If your random number needs
| are within what can be provided with strong guarantees, it
| doesn't seem like there's any reason to give you anything but
| strongly random numbers.
|
| People who need more random numbers per second than can be
| generated securely will simply have to pass explicit parameters
| indicating they want to stop getting high quality numbers. This
| would be easy to see in code review and highlight the choices
| being made.
| Quillbert182 wrote:
| Semi-unrelated question: How secure are the hardware random
| number generators on say, a raspberry pi. Would these sort of
| things be cryptographically secure?
___________________________________________________________________
(page generated 2021-02-11 23:01 UTC)