81–90 of 214 posts
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.
Earlier quoted context omitted.
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 install…
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…
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.
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.
> 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.
"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.
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…
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.
Earlier quoted context omitted.
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.
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, e…
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.
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…