@forest I'm sad. Apparently Linus Torvalds has proposed changing the default behavior (flags = 0) for the getrandom. Because some programmers use it even when they don't need "secure" random numbers because it's too convenient.
(Ripping out all of the nuance) He suggests we interpret flags=0 as a request for plain old random numbers and expect that users add a new GRND_SECURE flag if they really want security.
But really he says that we should maybe only change the default behavior for calls that request 16 bytes or less. Because who is really using 128 bits or less of randomness when they're expecting security?
The real tragedy is that code which runs at boot time may unexpectedly block, so we HAVE TO fix that by disregarding what we initially specified the system call to do.
I did not see us transitioning so fast from "/dev/random is more secure than /dev/urandom" to "Well, okay. Maybe it's fine to use properly initialized urandom for security purposes but /dev/random is still more 'secure'" to "Whatever. Unexpected blocking is way worse than every other security issue."
Let me restate what I really meant. It's shocking that the mainstream conviction was and still is [purposeless] blocking is here to stay because /dev/random is more secure, then the sensible solution finally made it into the kernel as a new enitrely separate interface, then shortly after that things got to the point where people start floating getting rid of purposeful blocking too.
Of course, I'm basically just talking about on how I believe the unruly mob thinks and projecting it onto one person who happens to be an authority figure. (My actual annoyance is with the crowd that is adamant that things should work a certain way because some old manpage written in the dark ages said something.)
I don't know the history and don't follow the community nearly well enough to know whether or to what extent Linus is personally responsible for the problem.
It seems so bizarre to me that anyone would even consider responding to misuse of a security critical system call by breaking an existing ABI contract and providing an insecure hack to accommodate the programmers using tools the wrong way.
It blows my mind that to this day the standard for getting random numbers in most environments will give you crap.
I'm sure there are some circumstances where crap "random" numbers are fine. But in those cases it won't hurt you to use secure random numbers.
If you actually need so many random numbers that the performance hit due to a proper PRNG becomes an issue, you should better know what you're doing and have a damn good argument, why adversarial behavior isn't a problem.
I use a lot of random numbers in hardware; however, outside of cryptography, where do people use random numbers in practical applications? It seems to me, if everyone is using /dev/random for cryptographic means, and it's inadequate, why not just make it cryptographically appropriate?
@SEJPM We've been 10 years away from a viable fusion reactor as long as I have been reading about physics.
I was thinking about that a few days ago. Videogames definitely use a lot of random numbers. (But water is probably done in a shader, so it gets its randomness from a hash function.)
Fisher-Yates shuffle. It requires log(n!) bits and is used a lot.
Less common but still common are randomized data structures. Skip lists, treaps, some hash tables, plus QuickSort pivot selection.
But in those cases you probably want secure random numbers in order to prevent denial of service attacks.
I was trying to think of examples besides videogames and simulations. But since most of my computer programming thought is dedicated to security related stuff I couldn't come up with much else.
I suspect whatever processes happen to be running on your BSD computer aren't fully representative of the variety ways different people use random numbers, b degnan. So that kind of profiling is probably limited.
Really the kernel should have a new interface for requesting human-unpredictable non-deterministic numbers.
Like some RNG API designed for people that want different numbers every time the computer is booted or a process is launched/forked but that don't care too much about security.
It's imperfect, but it would be far preferable to applications that currently use the alternative (not /dev/(u)random or getrandom) totally insecure kernel RNG.
At least then you could convince people to switch to that instead of what I think is an LCG or XorShift RNG or instead of some ad-hoc construct. The ad-hoc is really bad because people don't know what they're doing and you can't do a string search for any specific keywords to identify RNG misuse.
It would probably be a bad idea to make it a new syscall because people who don't know better might use it instead of something secure.
If it was a system call though then I'd like to see it take advantage of a strong RNG if it's available. Use /dev/urandom if your computer has been on long enough for it to be properly initialized. Sort of like opportunistic encryption.
@bdegnan Why? Typical hardware RNGs produce output at speeds measured in kilobits per second. AES circuits on bog-standard CPUs that you could buy at the computer store around the corner, if computer stores still existed, produce output at speeds measured in gigabits per second.
@FutureSecurity System call vs. /dev node vs. sysctl vs. vDSO function call vs. kernel API function vs. whatever else is all orthogonal to whether a particular operation blocks/fails or silently returns something predictable immediately.
Due to the physics of semiconductors. The noise is purely random, so you use a purely random source. Our simulations are generally very close to the actual devices. The "hiss" you hear in audio for example, when we simulate the ICs vs the fab'd versions, they are dead on.
Now, maybe the particular nonuniform distribution on the noise is hard to simulate because you don't know how to characterize it. But that's a separate issue from any notion of whether it's ‘purely random’ in the sense of being unpredictable to an observer without the secret {key, internal physical state}.
well, semiconductor noise is two-way shot noise. The classical johnson noise models are incorrect when derived from 1st principles. I should look into it. Regarding AES, you could use a shot-noise model to look derive how many transistors switched. You wouldn't know "which ones". This would be similar to what I could get from a power attack.
if you raised the AES core voltage, it'd be noisy as hell. It's strongly correlated with voltage across the channel.
Actually, that's a unique attack. I could inject voltage via an ion beam onto the sources of the AES core, and then extract the noise from the power supply to get an attack. The target wouldn't know it's under attack.
Obviously an employer absolutely can't require employees to vote for any particular candidate (or even to vote for any candidate rather than spoiling their ballot), but if it was included as a clause in employees' contracts that they must (in company time) attend the appropriate polling station a...
Is it just me, or does the latest answer on that SHA256 scam almost seem like it's trying to net donations for the fraudsters? crypto.stackexchange.com/a/74388/29554
It's not clear from the post that the poster recognizes that they are frauds
I have become quite familiar with Bulletproofs the last few months. Bulletproofs is the name given to a zero-knowledge proof system for arithmetic circuits, by Benedikt Bünz et al. It is a specific protocol with specific properties.
When Bulletproofs are discussed, they are often contrasted with...
