Arc4random in libressl 2.0.2(port70.net)
port70.net
Arc4random in libressl 2.0.2
http://port70.net/~nsz/47_arc4random.html
4 comments
The problem is Linux, not LibreSSL. Kernel.org needs to figure out if they are depreciating or keeping sysctl and if they aren't, find a failsafe way of gathering entropy inside a chroot or when file descriptors are exhausted. You can't expect OpenSSL nor LibreSSL to cater to the slapstick that is linux kernel development. If they can't get their shit together then switch to BSD or OSX.
I would propose that if Linux were truly broken, then LibreSSL portable (the "safe" replacement for OpenSSL) shouldn't be released for it. Plain and simple.
If, on the other hand, an actual official release of LibreSSL portable does show up for Linux, that is an implicit acknowledgment that it should be safe to use on Linux (though perhaps with restrictions, such as "must mknod /dev/urandom in a chroot environment, otherwise LibreSSL will abort and crash your app").
If, on the other hand, an actual official release of LibreSSL portable does show up for Linux, that is an implicit acknowledgment that it should be safe to use on Linux (though perhaps with restrictions, such as "must mknod /dev/urandom in a chroot environment, otherwise LibreSSL will abort and crash your app").
OSX? The compatibility code for getting entropy in OSX has just as much of a crummy fallback.
How shocking. OpenBSD guts OpenSSL, breaks something while doing so, then the top comment is "well, Linux is broken, use a BSD."
Did OpenSSL ever work right? If it were that simple, then it'd be easy to take that back into LibreSSL and fix the problem. Alas, the problem is not so simple.
I don't think anyone so far has been able to demonstrate a way to get entropy and reseed the rng after forks, in a manner that always works no matter what, on Linux. Everyone's got criticism, some people have suggestions, and when these suggestions are followed, more pitfalls are discovered. This is a problem with Linux -- Linux simply does not provide the right APIs and the right guarantees. Right now, it might very well be impossible to abstract the rng away on Linux like they do on OpenBSD.
So is Linux broken? Well, it sure likes to make things difficult. It is possible to work around the problem, but you cannot solve it in a library. No, OpenSSL could not solve it either. What did OpenSSL then do? It pushed the responsibility on to the applications, out of the library. Someone else's problem. Not solved! This might be a viable workaround as long as the problem is properly documented and all applications implement the workaround correctly (which apparently isn't the case).
OpenBSD isn't about workarounds. Much of what they do is about eliminating pitfalls that do not need to be there. This translates to less headaches for users & admins as well as developers. It's been demonstrated too many times that developers get things wrong. The OpenBSD people want to provide simple APIs that just work; ones you cannot use wrong. If there's a function that should provide randomness and the system is capable of providing randomness at all, then that function must work. Period. The programmer doesn't need to dance around it until it starts working. And the programmer shouldn't need to dance around it every once in a while again to keep it working. This is how we can get more secure software.
EDIT: Feel free to correct me if I am wrong. Can you show the world how to implement this right?
I don't think anyone so far has been able to demonstrate a way to get entropy and reseed the rng after forks, in a manner that always works no matter what, on Linux. Everyone's got criticism, some people have suggestions, and when these suggestions are followed, more pitfalls are discovered. This is a problem with Linux -- Linux simply does not provide the right APIs and the right guarantees. Right now, it might very well be impossible to abstract the rng away on Linux like they do on OpenBSD.
So is Linux broken? Well, it sure likes to make things difficult. It is possible to work around the problem, but you cannot solve it in a library. No, OpenSSL could not solve it either. What did OpenSSL then do? It pushed the responsibility on to the applications, out of the library. Someone else's problem. Not solved! This might be a viable workaround as long as the problem is properly documented and all applications implement the workaround correctly (which apparently isn't the case).
OpenBSD isn't about workarounds. Much of what they do is about eliminating pitfalls that do not need to be there. This translates to less headaches for users & admins as well as developers. It's been demonstrated too many times that developers get things wrong. The OpenBSD people want to provide simple APIs that just work; ones you cannot use wrong. If there's a function that should provide randomness and the system is capable of providing randomness at all, then that function must work. Period. The programmer doesn't need to dance around it until it starts working. And the programmer shouldn't need to dance around it every once in a while again to keep it working. This is how we can get more secure software.
EDIT: Feel free to correct me if I am wrong. Can you show the world how to implement this right?
OpenSSL doesn't handle it any better. As per Matthew D Green "It's like asking whether the crew of the Space Shuttle should have parachutes to protect them in the event that the shuttle explodes. OpenSSL says 'yes,' LibreSSL says a better idea would be to prevent the shuttle from exploding in the first place".
LibreSSL isn't even production ready yet, getentropy_linux.c is still in the tree getting worked on, and the sysctl method works (for now) with (most) linux kernels as a failsafe API to gather entropy while inside a chroot/file descriptors exhausted.
For all we know next month kernel.org could roll out a new failsafe API for entropy collection and finally kill off sysctl.
LibreSSL isn't even production ready yet, getentropy_linux.c is still in the tree getting worked on, and the sysctl method works (for now) with (most) linux kernels as a failsafe API to gather entropy while inside a chroot/file descriptors exhausted.
For all we know next month kernel.org could roll out a new failsafe API for entropy collection and finally kill off sysctl.
I'd like both if I'm heading to space--I want my vehicle to not explode, and if it does explode I want a way to get back down to Earth reasonable safely.
At least several of the Challenger crew survived the explosion and were definitely conscious and functioning for at least several seconds afterwards, and oxygen use records indicate they were alive for the fall to the ocean (whether they were conscious or not for the whole fall depends on whether or not the cabin depressurized, which is not known).
So, parachutes for a Space Shuttle crew are not prima facie unreasonable. There are engineering issues, which ultimately were determined to make them not worth it.
At least several of the Challenger crew survived the explosion and were definitely conscious and functioning for at least several seconds afterwards, and oxygen use records indicate they were alive for the fall to the ocean (whether they were conscious or not for the whole fall depends on whether or not the cabin depressurized, which is not known).
So, parachutes for a Space Shuttle crew are not prima facie unreasonable. There are engineering issues, which ultimately were determined to make them not worth it.
Capitalizing arc4random seems like a mindless application of the rules for the sake of mindlessly applying the rules. It's the name of a function in a case sensitive language; it's all lowercase.
Once again, the critics and the LibreSSL team are talking two different languages.
To LibreSSL, if the OS doesn't have a secure, reliable source of entropy, it's broken, and the "right" behavior for a crypto library is to fail. That's even an option in the Linux compatibility layer -- if there's no good entropy source, fail.
To the critics, the entropy the responsibility of the crypto library, and if the OS can supply it, the library should have a fallback.
The LibreSSL fallback layer is what's in question here, and if you really want security, don't use the fallback layer and get a fixed for the Linux kernel that provides the ideal kind of OS-level entropy.
To LibreSSL, if the OS doesn't have a secure, reliable source of entropy, it's broken, and the "right" behavior for a crypto library is to fail. That's even an option in the Linux compatibility layer -- if there's no good entropy source, fail.
To the critics, the entropy the responsibility of the crypto library, and if the OS can supply it, the library should have a fallback.
The LibreSSL fallback layer is what's in question here, and if you really want security, don't use the fallback layer and get a fixed for the Linux kernel that provides the ideal kind of OS-level entropy.
Not sure what you're talking about, because one of the major complaints with the recent LibreSSL release was that in the event there was no reliable entropy source, it happily used an unreliable one.
LibreSSL does that because the FAIL_INSTEAD_OF_TRYING_FALLBACK is off by default, but the source clearly says it's not a good thing:
"This code path exists to bring light to the issue that Linux does not provide a failsafe API for entropy collection.".
Incidentally, OSX has nearly the same issue, as does Solaris.
For maximum security, define FAIL_INSTEAD_OF_TRYING_FALLBACK and if there's no reliable entropy source, LibreSSL won't try to use a bad one from the OS.
Incidentally, OSX has nearly the same issue, as does Solaris.
For maximum security, define FAIL_INSTEAD_OF_TRYING_FALLBACK and if there's no reliable entropy source, LibreSSL won't try to use a bad one from the OS.
Is the portable LibreSSL library being written by the OpenBSD folks or someone maintaining a fork? My impression of their plans was that they would focus on OpenBSD first and foremost and once they were happy with it, then would be the right time to start porting it to other platforms (or any platform which provides the same guarantees as OpenBSD's API could already use it).
The OpenBSD folks are doing it, and in the comments in the source they make it clear they expect the OS to provide a secure and stable entropy source.
And I expect my car to provide a reliable form of transportation, but if I turn the key in the morning and chickens fly out from under the hood, I stop what I'm doing, I don't keep driving to work.
Agreed. Maybe the default in LibreSSL should be swapped from "go ahead and use this fallback faux-entropy if we have to" to "fail if we can't get good entropy". It'd be a matter of changing and undef to a def in the code.
Not only is this entirely uninteresting, but this is not the way to do software development. Take it to the respective mailing list, issue tracker, IRC channel, etc. That's what they are there for. I'm sure it's less distracting to the developers as well.