Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Should random() be banned?

r2c.dev

Post reply on HN
Print view View original

191–200 of 214 posts

Re: Should random() be banned?

#191

Post by mytherin »

f-word wrote: post #83

"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 t…

> 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.

The goal of linters should be to ensure this doesn't happen. By turning non-compliant code into a test failure no reviewer attention ever needs to be wasted on formatting issues (which I fully agree is a complete waste of everyone's time).

* If the tests pass, the formatting is correct. Great, reviewers have nothing to complain about.

* If the tests don't pass, the formatting has to be fixed before the code will be merged. Code that doesn't pass the tests should never be merged in the first place. As a result, reviewers don't need to care as it has to be fixed anyway.

Reviewers that still feel the need to point out formatting inconsistencies are likely just disinterested in providing genuine feedback, and would not have provided useful feedback regardless of the presence of linters.

Re: Should random() be banned?

#192

Post by ThomasWinwood »

This is probably a hot take, but I don't think standard libraries should contain a random number generator.

There is no globally correct choice of PRNG algorithm. If you need randomness, you should ask what kind of randomness - cryptography wants secure, Monte Carlo methods want fast, games can often benefit from N-dimensional equidistribution, etc. - and find a library specialised for that use case. A standard library function that nobody uses because there's always a better alternative elsewhere is a bad standard library function.

Re: Should random() be banned?

#193

Post by thekyle »

aaomidi wrote: post #162
bigiain wrote: post #146

Earlier quoted context omitted.

I disagree. Making one specific aspect of incompetent crypto coding “safer” doesn’t solve any of the problems. We can argue about what threshold you need to reach to be considered “capable” of writing crypto code (that’s not just a learning exercise), but not knowing the deficiencies of random() is clearly well below that bar. Even knowing that is barely past the “don’t eat your crayons” level of skill. If anything,…

You could be a great mathematician and not realize what kind of random you're picking. It's not as simple as you put it. This discussion goes for other stuff too. Rust is getting popular because even amazing C and C++ devs make terrible mistakes that cause severe security and privacy problems down the line.

Just because someone is a great mathematician does not mean they would be a great cryptographer. Mathematics and cryptography are about as related as computer science and cryptography (not that much).

Re: Should random() be banned?

#194

Post by lucideer »

FalconSensei wrote: post #73
Macha wrote: post #61

Earlier quoted context omitted.

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 -…

Also: if someone is working on crypto and doesn't know that random() isn't true random, should they be working on that?

> should they be

This is the point of people suggesting things like bans or explicit warnings. They "shouldn't", but what's stopping them.

Re: Should random() be banned?

#195

Post by nemo1618 »

repsilat wrote: post #131
nemo1618 wrote: post #86

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 ca…

> You can generate gigabytes of secure entropy per second in userspace. I haven't thought about this before, so please have patience: I guess the "secure" qualifier does a lot of work in this sentence? That there's 32 bytes of "true entropy", but "secure entropy" is theoretically weaker but practically just as strong with reasonable assumptions about an attacker's computing resources. So I'd guess the "secure" qualif…

Correct -- the RNG output does not reveal anything about its input, just like the output of a strong cipher does not reveal anything about its input.

djb has a good article on the subject: https://blog.cr.yp.to/20170723-random.html

I've implemented his "fast-key-erasure CSPRNG" in Go: https://github.com/lukechampine/frand

Re: Should random() be banned?

#197

Post by brynet »

To quote Theo de Raadt's recent commit to OpenBSD's rand(3)/random(3) man pages, since people seem to be very confused here.

    +The deterministic sequence algorithm changed a number of times since
    +original development, is underspecified, and should not be relied upon to
    +remain consistent between platforms and over time.
https://marc.info/?l=openbsd-cvs&m=161314944608164&w=2

Re: Should random() be banned?

#198

Post by admax88q »

throw0101a wrote: post #77
admax88q wrote: post #76

Earlier quoted context omitted.

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 wa…

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.

> or possible future removal—don't change it.

The future is now, insecure code has had long enough to catch up.

Re: Should random() be banned?

#199

Post by admax88q »

h_anna_h wrote: post #190
lmm wrote: post #160

Earlier quoted context omitted.

> Why? Because you're doing something that often causes major security bugs. > Why not both? It's not possible for random numbers to be both predictable and secure at the same time.

In addition to what bscphil said > Because you're doing something that often causes major security bugs. Okay, sure, but I might be running a simulation or something, why should I be punished because some idiot decided to srand(time(0))?

Because your in the minority. Why should rand() be reserved for your use case and people with other use cases need to use a more obtuse SecureRandom() API?

Defaults should be secure. The simple case should be secure.

Re: Should random() be banned?

#200

Post by admax88q »

kevin_thibedeau wrote: post #101
admax88q wrote: post #76

Earlier quoted context omitted.

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 wa…

A reproducible pseudorandom sequence is necessary for fuzz testing with randomized inputs. It isn't strictly the domain of "ancient C". Why should everyone be hobbled by security guarantees they won't need?

Why should everyone be compromised because fuzzers want to use the simpler rand() API instead of something different?

I'm not saying we shouldn't have a way to generate predictable "random" sequences. But the default, simple, API for random numbers in any given language should be secure.

The vast majority of software does not need pseudorandom sequences. Developers shouldn't have to think every time "is pseudorandom good enough for this use case?" It should just be strong random every time. If you need a pseudorandom we should have a separate API for that.

Post reply on HN