Hacker Newsnew | past | comments | ask | show | jobs | submit | jodiscr's commentslogin

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.


Sorry but that's just an idiotic assertion.

Closed source proprietary crypto, you just don't know who wrote it, who audited it and who backdoored it and who knows of any flaws in it.

Open source crypto, it's there. Go read the source. Anyone can and it's open for audit.

There aren't enough eyeballs I agree but there are infinitely more trustworthy people looking at it than closed source.


"Many eyes make bugs shallow", goes the saying; but it's true that that does require that people actually do look at it - and with the state OpenSSL is in it's clear people took it for granted for years. I'm as guilty of that as you. It was ugly and crufty and I'd assumed and hoped that it'd been thoroughly reviewed and was the way it was because it was being conservative with changes; turns out no, actually it's a giant hairball which they're now shaving, BoringSSL is trimming, and LibReSSL is gleefully taking a combine harvester to!

But reflect on this: we're looking at it now. There are more eyeballs looking at open-source crypto than closed source crypto. Reflect on that for a moment, and on the RSA BSAFE/NSA 'enabling' and the like, and remember that being well-funded didn't stop Apple's source-available implementation from going directly to fail.

I wonder, for example, what's really under the hood of, say, Microsoft SChannel/CAPI/CNG? I'm a reverse-engineer (which means I don't need no stinking source code, given a large enough supply of chocolate) so I may look in detail, when I get a large enough patch of free time. I've heard it's not as bad as it could be… but I know on this subject, for example it ships Dual_EC_DRBG as alternative in CNG (but uses CTR_DRBG by default from Vista SP1 onwards, thank goodness). The old RtlGenRandom wasn't too great, I know that much.


Transparency is a dependency of trust. The "well-funded proprietary counterparts" are non-transparent (per the definition of "proprietary software"), and therefore are untrustworthy.


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...


The RNG device for Mac OS X's XNU kernel is open source [1]. The kernel for OS X is open source and you can compile your own kernels if you want.

[1]: http://www.opensource.apple.com/source/xnu/xnu-2422.1.72/bsd...


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.


... and in some cases, we've seen how using proprietary software turned out.

You're not making a substantial argument, but if someone has a track record of writing completely safe software that doesn't have to be secured through third party products, like Microsoft, I will be willing to listen.


These are the arguments people have been making for/against open source software for decades. They are old, tired, and well traveled. If we want to rehash them yet again, let's go to the Slashdot archives or Usenet and have a nostalgia party. Otherwise, let's try to focus on something actually interesting.


> Otherwise it feels like some of that autogenerated SEO-style spam, which Google should penalize.

I assumed Google already recognized these near-duplicates and are penalizing them


I ain't switching from Perl 5.8 to golang until a shared hosting provider becomes available.


Google App Engine


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: