Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LibreSSL's PRNG is Unsafe on Linux

agwa.name

Post reply on HN
Print view View original

51–60 of 151 posts

Re: LibreSSL's PRNG is Unsafe on Linux

#51

Post by jodiscr »

wbl wrote: post #48
jodiscr wrote: post #46

Given things like the Debian OpenSSL fiasco and Heartbleed, can we honestly put as much faith into open source crypto as it's well-funded proprietary counterparts? I honestly prefer open source and recognize the problem the author points out as clearly significant problem - as well as the benefits of LibreSSL, but I'm just not convinced there are enough eyeballs looking at open source crypto.

Ever hear of BSAFE? They took a million dollars from the NSA to implant a backdoor. How do you evaluate code you cannot see?

yes, but I'm talking about RNG from likes of Microsoft or Apple...

Re: LibreSSL's PRNG is Unsafe on Linux

#52

Post by nitrogen »

jodiscr wrote: post #51
wbl wrote: post #48

Earlier quoted context omitted.

Ever hear of BSAFE? They took a million dollars from the NSA to implant a backdoor. How do you evaluate code you cannot see?

yes, but I'm talking about RNG from likes of Microsoft or Apple...

If you can't evaluate it, you can't trust it. Plus, Apple had gotofail, and MS has had its share of issues as well.

Re: LibreSSL's PRNG is Unsafe on Linux

#53

Post by jodiscr »

nitrogen wrote: post #52
jodiscr wrote: post #51

Earlier quoted context omitted.

yes, but I'm talking about RNG from likes of Microsoft or Apple...

If you can't evaluate it, you can't trust it. Plus, Apple had gotofail, and MS has had its share of issues as well.

can't evaluate > not enough funds to evaluate

In other words, with proprietary sw, at least SOMEBODY evaluated it and placed their seal/name on it. With open source, you are relying on a hope that somebody out there somewhere does it. And in various cases, we've seen how that turned out.

Re: LibreSSL's PRNG is Unsafe on Linux

#54

Post by AlyssaRowan »

hsivonen wrote: post #40

Can we, please, have a syscall in Linux that returns random bytes from the system CSPRNG or blocks if not seeded yet and doesn't involve dealing with file descriptors? But even while one isn't available, why is LibreSSL trying to use a userland CSPRNG instead of always reading from /dev/urandom and aborting when that fails?

Yes. Actually, the relevant IETF list is now calling for that: Linux needs getentropy(2). I may cook up my own and submit it to LKML, or perhaps someone else can, but there's no way out of this one without kernel support.

I don't know why the rest of the function even exists. It's the kind of cruft libReSSL is trying to get rid of.

I am not entirely sure a PRNG should even exist in the library, and personally, I'd pass it onto /dev/urandom or /dev/random or the relevant syscall.

I agree with making it (154-156) a hard kill for a TLS library not to be able to get entropy.

And, this is great! This is exactly the kind of thing we're able to find now that some of the code isn't a hedge-maze.

Re: LibreSSL's PRNG is Unsafe on Linux

#55

Post by blahrf »

agwa wrote: post #50
blahrf wrote: post #43

You can't simply seed it before a chroot. Look at the code. chacha adds entropy periodically and folds it in. You need entropy in the chroot. The author should probably read 10 lines below the same code he posted in the article. While I'd love to see a solution for this particular contrived example, considering in the much more common use cases it actually is more secure than OpenSSL's. Especially so if your kernel h…

> chacha adds entropy periodically and folds it in. You need entropy in the chroot. If that's the case then the fix will not be as simple as I envisioned it. Still, the point stands that LibreSSL should allow you to initialize the PRNG once, before you chroot, so that you can use the PRNG safely once inside the chroot. This could be accomplished by keeping a file descriptor to /dev/urandom open.

"If that's the case?" - Didn't you read the code? :) Sounds like you would prefer no stirring of any new entropy after you chroot... Looks to me like they're trying to require that additional entropy be available, always. (and if you don't have a completely hacked up kernel sysctl is still there..) - maybe we might get something better before it (sysctl) goes away for real instead of just in c-library-du-jour.

Re: LibreSSL's PRNG is Unsafe on Linux

#56

Post by gaadd33 »

quotemstr wrote: post #32
agwa wrote: post #25

Earlier quoted context omitted.

> The key is to acquire resources in places that can fail and use them in places that can't. I'm amazed and disappointed that the LibreSSL people aren't following this basic principle. To be fair to the LIbreSSL devs, the Linux-specific /dev/urandom code is currently encapsulated rather nicely behind an interface that's compatible with the OpenBSD getentropy() syscall. Following your suggestion would create a layer v…

> Following your suggestion would create a layer violation and move LibreSSL closer toward the (much maligned) OpenSSL approach to cross platform compatibility. The OpenSSL approach to portability is doomed: it can only deal with cosmetic differences between platforms. I appreciate the principle of using compatibility functions instead of #ifdef, but at some point, you need to incorporate the panoply of architectures…

Isn't this the same way that they do porting for OpenSSH? Why do you say that method is doomed when it seems to have been working fine for over 10 years?

Re: LibreSSL's PRNG is Unsafe on Linux

#57

Post by _pmf_ »

Don't rain on their parade. OpenSSL has been determined to be a laughing stock by super-informed internet forum people, and we need to keep up pretending that a rewrite of a major piece of internet infrastructure is feasible and makes sense.

Re: LibreSSL's PRNG is Unsafe on Linux

#58

Post by blahrf »

Even though it looks like it won't get called, I'm wondering how bad the voodoo is? Anyone looked at what it is spitting into that hash function? How predictable are those clocks as they change between the memory fetches. Will Linux have predictable memory access times where those pages land?

Re: LibreSSL's PRNG is Unsafe on Linux

#59

Post by agwa »

blahrf wrote: post #55
agwa wrote: post #50

Earlier quoted context omitted.

> chacha adds entropy periodically and folds it in. You need entropy in the chroot. If that's the case then the fix will not be as simple as I envisioned it. Still, the point stands that LibreSSL should allow you to initialize the PRNG once, before you chroot, so that you can use the PRNG safely once inside the chroot. This could be accomplished by keeping a file descriptor to /dev/urandom open.

"If that's the case?" - Didn't you read the code? :) Sounds like you would prefer no stirring of any new entropy after you chroot... Looks to me like they're trying to require that additional entropy be available, always. (and if you don't have a completely hacked up kernel sysctl is still there..) - maybe we might get something better before it (sysctl) goes away for real instead of just in c-library-du-jour.

You're correct :-) - it does periodically stir in new entropy.

I'm fine with stirring in new entropy after chrooting - I just don't want to see sketchy entropy being used, especially for the initial entropy source. If you could make LibreSSL open (and keep open) /dev/urandom before you chroot, LibreSSL could read additional entropy from the already open file descriptor, even after chrooting.

In any case, note that the chroot issue is a bit of a sideshow compared to the much more serious fork issue.

Re: LibreSSL's PRNG is Unsafe on Linux

#60

Post by agwa »

AlyssaRowan wrote: post #54
hsivonen wrote: post #40

Can we, please, have a syscall in Linux that returns random bytes from the system CSPRNG or blocks if not seeded yet and doesn't involve dealing with file descriptors? But even while one isn't available, why is LibreSSL trying to use a userland CSPRNG instead of always reading from /dev/urandom and aborting when that fails?

Yes. Actually, the relevant IETF list is now calling for that: Linux needs getentropy(2). I may cook up my own and submit it to LKML, or perhaps someone else can, but there's no way out of this one without kernel support. I don't know why the rest of the function even exists. It's the kind of cruft libReSSL is trying to get rid of. I am not entirely sure a PRNG should even exist in the library, and personally, I'd pa…

Yeah, if LibreSSL continues to implement its own PRNG in userspace, a getentropy syscall only solves the chroot issue, not the fork issue. You're probably right that a PRNG should not exist in the library.
Post reply on HN