Of course I know about other hardware RNGs. I already pointed to VIAs and the occasional one strapped to an ARM core. I put some of them in some of those chips. Back then I was into iterated hashes, but I've learned the error of my ways and these days it's block ciphers and field arithmetic all the way.
Rumor has is that I may know something about the RNG you just referenced. It may be two years old to you, but it didn't come into existence in 10 minutes. It doesn't really matter. These repeated crypto software failures point to a holier than thou attitude of some crypto software writers that does the public no good. You can't play in this game without accepting that it's easy to be wrong and you'd better have things checked and cross checked by the smartest people you can find and don't get all defensive when you've been found to be wrong. Mark it down to experience and move on. That's how it works. When Theo can't accept that the universe works this way, he automatically loses his security credibility license.
The Switcher: The Switcher was really only released as a "toy", and was fairly irrelevant after about 1987, when Macs could have more than 256K (yes, that's KILObytes) of RAM, and since System 7 supported Virtual Memory, it was REALLY irrelevant then. Heck, I wrote a floppy-based "Switcher" for my Apple ][. Took about 4 seconds to swap-out 48K of RAM (pretty much every single byte of it!). Was cool to be able to run Magic Window (for documentation) and your Software Development "IDE" (in my case, usually my specially-modified version of the TED][ Editor/Assembler) and be able to flip back and forth.
Ahh. Much respect. I have switched to using a CFFA3000 for my apple 2e and have recently turned back to programming 6502 assembler, like I did when I was 10 years old.
MacOS was horrible, and so was DOS and Windows 3.x. Compared to the state of the art those systems were like school projects, they only succeeded in the professional world because of the applications. Everyone in the real world was going full steam ahead with Unix (Unix wars started around then).
I clearly remember the shock of finding SysV has won and all that BSD goodness was not a part of my work day. This was on Suns.
No memory protection. No virtual memory. The switcher. Sad Mac Icon. Things were not perfect. These days a Mac is a robust thing. The tradeoff is that is it a government and corporate portal into your home and life.
I'm not. There are normal capability bits though. So software can be written to do the right thing on each platform.
The point is that even in a chroot jail with no access to/dev/urandom and a completely predictable PID, instructions are still there on intel CPUs, VIAs and some arms, yet the library ignores all those options, resulting in a collision case. It's certainly the right thing to do to mix in cheap, fast sources into your CSPRNG state on each call. You don't have to trust the source and no harm will arise, but if the source is actually trustworthy, it will cover for cases such as these very effectively.
CSPRNGs are a fine component in a system. But it doesn't let anyone off the hook for gathering and extracting entropy.
Hardware vendors have to do it. Things are ok on PCs these days, but the plethora of amateur SoCs have re-opened the field for entropyless systems.
Something somewhere needs to implement policy, in terms of what is trusted to be entropic and combining and processing sources. A library can do that. But a CSPRNG as we have seen in this case, is particularly precarious in a user library because it's state can be duplicated. You're better off with a system resident service of some sort. An OS will do, or a hardware interface that supports multiple consumers without coordination (like CPU instructions), or anything else than can keep any PRNG state in a well controlled context.
I've gone for bypassing the OS as best I can and delivering the entropy directly from hardware. OSs don't have the situational awareness to know whether or not what they have is really entropic. It works most of the time until you try and run it on an arm processor in a fully synchronous chip in a cheesy router pulling random numbers at early boot time.
The last time I looked, OpenSSL claimed to provide command line tools for managing certs. It's a security product. OpenSSL recently greatly improved its RNG code, but the BSD folks borked it.
Not that I'm a fan of OpenSSL at all. I'd like to see it wiped off this planet. But replacing it with another TLS implementation is not what I'd call a success.
LibreSSL relied on specific PID behavior to be secure. Linux has conditions in which recent PIDs of disappeared processes can be reused in new processes. This broke the LibreSSL assumptions.
From other comments it seems the state space of the PIDs is pretty small anyway. The birthday collision bound is waiting to trip you up even on BSDs.
Don't rely on the PID to provide you with crypto security properties.
The design is requiring the PID to not just be unique, but to be unpredictable. So after untangling the cords, you end up with the same requirement on your PID as you have on your RNG. Therefore the RNG design is wrong.
Slashdot Mirror
Of course I know about other hardware RNGs. I already pointed to VIAs and the occasional one strapped to an ARM core. I put some of them in some of those chips. Back then I was into iterated hashes, but I've learned the error of my ways and these days it's block ciphers and field arithmetic all the way.
Rumor has is that I may know something about the RNG you just referenced. It may be two years old to you, but it didn't come into existence in 10 minutes. It doesn't really matter. These repeated crypto software failures point to a holier than thou attitude of some crypto software writers that does the public no good. You can't play in this game without accepting that it's easy to be wrong and you'd better have things checked and cross checked by the smartest people you can find and don't get all defensive when you've been found to be wrong. Mark it down to experience and move on. That's how it works. When Theo can't accept that the universe works this way, he automatically loses his security credibility license.
The Switcher: The Switcher was really only released as a "toy", and was fairly irrelevant after about 1987, when Macs could have more than 256K (yes, that's KILObytes) of RAM, and since System 7 supported Virtual Memory, it was REALLY irrelevant then. Heck, I wrote a floppy-based "Switcher" for my Apple ][. Took about 4 seconds to swap-out 48K of RAM (pretty much every single byte of it!). Was cool to be able to run Magic Window (for documentation) and your Software Development "IDE" (in my case, usually my specially-modified version of the TED][ Editor/Assembler) and be able to flip back and forth.
Ahh. Much respect. I have switched to using a CFFA3000 for my apple 2e and have recently turned back to programming 6502 assembler, like I did when I was 10 years old.
MacOS was horrible, and so was DOS and Windows 3.x. Compared to the state of the art those systems were like school projects, they only succeeded in the professional world because of the applications. Everyone in the real world was going full steam ahead with Unix (Unix wars started around then).
I clearly remember the shock of finding SysV has won and all that BSD goodness was not a part of my work day. This was on Suns.
ps -e FFS!
>Horrible in what way?
No memory protection. No virtual memory. The switcher. Sad Mac Icon. Things were not perfect. These days a Mac is a robust thing. The tradeoff is that is it a government and corporate portal into your home and life.
In 1991, real computing was done on unix workstations running BSD (Sun 3/60 anyone?).
The PC market was a cess pit. The Macintosh was nice, but the OS was horribly unreliable.
>What was unique with PowerPC was to be cheaper, that's all.
And yet it never was.
Does no one in the federal government have a smartphone? Why are there no pictures of the vials being pulled from dusty refrigerators?
No. Negativity is a normal condition for crypto oriented people.
Why are you using a CPU that doesn't provide an entropy source to run crypto code? Software cannot fix that for you.
The root is self signed obviously.
Everyone should have their own CA. The cert nag tax is only for web sites.
I'm not. There are normal capability bits though. So software can be written to do the right thing on each platform.
The point is that even in a chroot jail with no access to /dev/urandom and a completely predictable PID, instructions are still there on intel CPUs, VIAs and some arms, yet the library ignores all those options, resulting in a collision case. It's certainly the right thing to do to mix in cheap, fast sources into your CSPRNG state on each call. You don't have to trust the source and no harm will arise, but if the source is actually trustworthy, it will cover for cases such as these very effectively.
I got that email.
Of course I always click the links in emails claiming to be important.
When my certs expire I sign myself a new request. 30 seconds, mostly to find the script.
>I am glad that you've never managed to have a bug escape into the public testing phase of a product.
It doesn't work like that for some of us. It has to be right first time, every time. Which is probably why I'm always tired.
It's a shame the software didn't have a handy dandy instruction that it could execute without reference to the OS or libraries or permissions.
CSPRNGs are a fine component in a system. But it doesn't let anyone off the hook for gathering and extracting entropy.
Hardware vendors have to do it. Things are ok on PCs these days, but the plethora of amateur SoCs have re-opened the field for entropyless systems.
Something somewhere needs to implement policy, in terms of what is trusted to be entropic and combining and processing sources. A library can do that. But a CSPRNG as we have seen in this case, is particularly precarious in a user library because it's state can be duplicated. You're better off with a system resident service of some sort. An OS will do, or a hardware interface that supports multiple consumers without coordination (like CPU instructions), or anything else than can keep any PRNG state in a well controlled context.
>Entropy is the OS's job.
I've gone for bypassing the OS as best I can and delivering the entropy directly from hardware. OSs don't have the situational awareness to know whether or not what they have is really entropic. It works most of the time until you try and run it on an arm processor in a fully synchronous chip in a cheesy router pulling random numbers at early boot time.
The last time I looked, OpenSSL claimed to provide command line tools for managing certs. It's a security product. OpenSSL recently greatly improved its RNG code, but the BSD folks borked it.
Not that I'm a fan of OpenSSL at all. I'd like to see it wiped off this planet. But replacing it with another TLS implementation is not what I'd call a success.
The incrementing PID would collide with itself less than a random PID of the same number of bits.
PIDs aren't good sources of entropy.
Lets hope their PRNG is good :)
>how come you have spent years designing and programnming PRNGs
I do them in hardware, where they should be. Software is no place for an RNG.
LibreSSL relied on specific PID behavior to be secure. Linux has conditions in which recent PIDs of disappeared processes can be reused in new processes. This broke the LibreSSL assumptions.
From other comments it seems the state space of the PIDs is pretty small anyway. The birthday collision bound is waiting to trip you up even on BSDs.
Don't rely on the PID to provide you with crypto security properties.
The design is requiring the PID to not just be unique, but to be unpredictable. So after untangling the cords, you end up with the same requirement on your PID as you have on your RNG. Therefore the RNG design is wrong.
Linux's PID behavior is not a security feature. LibreSSL should not rely on it. Security products needs to be held to a higher standard.
The reason is because LibreSSL thought it was OK to put a CSPRNG in a place where it was not ok.
>you are a fucking idiot.
Maybe, but on this topic, I know my shit.