Should random() be banned? • Hacker News Board

Re: Should random() be banned?

#21

Post by [deleted] » Thu, Feb 11, 2021, 5:49 PM UTC

Spivak wrote: post #8

ThePadawan wrote: post #3

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

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]

Re: Should random() be banned?

#22

Post by mannerheim » Thu, Feb 11, 2021, 5:52 PM UTC

ThePadawan wrote: post #3

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

accursedUnutterablePerformIO

https://hackage.haskell.org/package/bytestring-0.11.0.0/docs...

Re: Should random() be banned?

#23

Post by analog31 » Thu, Feb 11, 2021, 5:53 PM UTC

madsbuch wrote: post #4

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.

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?

Re: Should random() be banned?

#24

Post by klodolph » Thu, Feb 11, 2021, 5:53 PM UTC

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

Re: Should random() be banned?

#25

Post by aeturnum » Thu, Feb 11, 2021, 5:55 PM UTC

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.

Re: Should random() be banned?

#26

Post by cogman10 » Thu, Feb 11, 2021, 5:55 PM UTC

zrm wrote: post #6

ThePadawan wrote: post #3

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

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…

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.

Re: Should random() be banned?

#27

Post by wnevets » Thu, Feb 11, 2021, 5:55 PM UTC

cpeterso wrote: post #5

ThePadawan wrote: post #3

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

Firefox has a secret setting used in test automation called “turn_off_all_security_so_that_viruses_can_take_over_this_computer”. https://searchfox.org/mozilla-central/rev/3ff133d19f87da2ba0...

hmm I wonder what would happen if I enable this setting...

Re: Should random() be banned?

#28

Post by sobriquet9 » Thu, Feb 11, 2021, 5:56 PM UTC

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.

Re: Should random() be banned?

#29

Post by [deleted] » Thu, Feb 11, 2021, 5:56 PM UTC

ThePadawan wrote: post #3

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

[deleted]

Re: Should random() be banned?

#30

Post by hannob » Thu, Feb 11, 2021, 5:56 PM UTC

madsbuch wrote: post #4

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.

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.