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

161–170 of 214 posts

Re: Should random() be banned?

#161

Post by lbblack »

People ban programming functions? That is against the law for anyone respected and honest in the open source and scientific communities!

THAT IS AGAINST THE 1ST AMENDMENT RIGHTS for any American citizen. Any human citizen within the sovereignty of this mighty country only for for Legendary souls is bought bought - but earned. With the hands of both Life and Death. And programming is the most divine magic of them all - which only holy warriors should be able to touch. Programming is a lost art and forgotten by anyone who is respected in the eyes of the Heavenly Courts. Learn something new tomorrow.

Happy New Year Joe Biden, greatest president of the upcoming 21st century. Long live VALHALLA, and the mighty deliverer's of justice themselves. For the holy water which makes up Lake Tahoe, can only be touched by those granted access from a source of the Heavenly Courts. I believe and trust in my faith and my personal opinions.

Lucas Bernard Black is actually really known by very few, but admired by many. Stay humble, stay rooted and shoot for the stars

Re: Should random() be banned?

#162

Post by aaomidi »

bigiain wrote: post #146
aaomidi wrote: post #115

Earlier quoted context omitted.

There isn't a threshold where you become capable of working on crypto problems and code. Making this safer makes mistakes far less likely and makes all of us safer.

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.

Re: Should random() be banned?

#163

Post by zrm »

bigiain wrote: post #147
zrm wrote: post #6

Earlier quoted context omitted.

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…

Then we’ll end up with a csprng getting used in a tight loop iterating over every pixel in a raytracer... “Lazy people who don’t want to type” are not the sort of people I want writing the code I might use or interact with that requires cryptographically secure random numbers...

> Then we’ll end up with a csprng getting used in a tight loop iterating over every pixel in a raytracer...

Which will then be conspicuous enough for the developer to notice and fix it.

> “Lazy people who don’t want to type” are not the sort of people I want writing the code I might use or interact with that requires cryptographically secure random numbers...

Bad news though.

Re: Should random() be banned?

#165

Post by millstone »

zappsepp wrote: post #37
zabzonk wrote: post #11

To answer this, we would need to know what you mean by random(). You haven't provided any language, library or other context.

Differences would be marginal. Computers are inherently bad at randomness.

random() is just a function name that could do anything. We can't answer the question if we don't know what random() means.

Re: Should random() be banned?

#166

Post by wbl »

Macha wrote: post #61
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…

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

How many of those applications are ones where a single AES encryption is too slow?

Re: Should random() be banned?

#167

Post by Khaine »

Dylan16807 wrote: post #140
Khaine wrote: post #138

Earlier quoted context omitted.

The other thing is, true randomness doesn't seem random to humans. Which is why spotify and others had to modify shuffle. So true random might not be appropriate for the use case. What is appropriate to use comes down to context.

You don't modify shuffle to make it seem more random, you modify shuffle because a non-clumping algorithm is more pleasant.

It's more pleasant because it is less random. I naive implementation might use true randomness which to a human doesn't appear random.

https://www.businessinsider.com.au/spotify-made-shuffle-feat...

Re: Should random() be banned?

#168

Post by patrec »

MauranKilom wrote: post #117
patrec wrote: post #94

Earlier quoted context omitted.

Mersenne Twister is the MD5 of random number generators: it's neither secure nor fast (and unlikely md5 not space-efficient, or simple to implement either). You can have something that has better randomness, runs several times faster, uses less space and has a much more compact and simple implementation. So given that Mersenne Twister sucks in pretty much every possible way other than having a catchy name, likely the…

> You can have something that has better randomness, runs several times faster, uses less space and has a much more compact and simple implementation. Could you share at least one example of such a generator? Most of these aspects are trivial to improve on, but having "better randomness" on top is quite the bar.

https://en.wikipedia.org/wiki/Mersenne_Twister#Alternatives

https://nullprogram.com/blog/2017/09/21/

I don't think better randomness than MT is as high a bar as you make it out to be, both links above also briefly mention statistical shortcomings of MT.

Re: Should random() be banned?

#169

Post by ThePadawan »

Macha wrote: post #61
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…

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

Did you mean to reply to my comment?

I don't disagree with anything you say, but it also doesn't refer to my comment.

Re: Should random() be banned?

#170

Post by bscphil »

lmm wrote: post #160
h_anna_h wrote: post #106

Earlier quoted context omitted.

> If you want predictable "random" numbers, you should have to jump through additional hoops Why? > By default random numbers should be cryptographically secure. Why not both?

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

If by "predictable" all that's meant is "you can deterministically recreate every output bit generated by the function, forever, using a single value that represents the starting state of the function", then you can certainly have that and a secure RNG function. Just use ChaCha20's function with the key representing your seed.
Post reply on HN