8 ms·

Open-source crypto is no better than closed-source crypto

83 points by throwawaymath 8y ago

throwawaymath 8y ago
The titular thesis of this article is that Linus' Law doesn't really apply to cryptographic security vulnerabilities. To lend some authority to that (probably controversial) claim: the author of this article is JP Aumasson, a well known cryptography researcher and engineer. There aren't many cryptographers who work in both theory and application the way Aumasson does. He recently wrote Serious Cryptography and has done professional cryptanalysis since 2012. He is also a co- or primary author for several cryptographic algorithms; including BLAKE/BLAKE2, NORX, SipHash, and Gravity SPHINCS. In the course of establishing his argument he groups cryptographic vulnerabilities into four main categories. The basic idea is that vulnerabilities in cryptography require a different set of skills to find than "regular" security vulnerabilities do. They also have different requirements for exploitation. Aumasson's overall point is that the higher difficulty of finding bugs in cryptography for each category means there won't be a meaningful difference in security between open and closed source code. And for what it's worth he's only talking about open versus closed source implementation here. He's not talking about Schneier's Law or closed source designs.
- warkdarrior 8y ago
  Did you mean Kerckhoffs's principle ("a cryptosystem should be secure even if everything about the system, except the key, is public knowledge")? Instead of Schneier's Law ("any person can invent a security system so clever that she or he can't think of how to break it").
  - throwawaymath 8y ago
    I did, that's right! Thank you for the correction, I should've double checked that :)
- snaky 8y ago
  > The basic idea is that vulnerabilities in cryptography require a different set of skills to find than "regular" security vulnerabilities do That may be true for traditional low-level hand-optimized implementations. But if we consider the trend is clearly toward the high-level proof-based code[1], which is way easier to audit, then open source is obviously better. [1] "Simple High-Level Code For Cryptographic Arithmetic - With Proofs, Without Compromises" https://deepspec.org/entry/Paper/Simple+High.2DLevel+Code+For+Cryptographic+Arithmetic+.2D.2D+With+Proofs.2C+Without+Compromises https://deepspec.org/entry/Paper/Simple+High.2DLevel+Code+Fo...
  - blattimwind 8y ago
    Most issues (apart from legacy asymmetric primitives) are actually either in the implementation (common in widely deployed software) or the design (even more common in widely deployed software) of higher level protocols. Many implementations issues in crypto code are just regular code bugs. Meanwhile, design issues are not so readily apparent. There is no linter that will tell you that using the same AES key for years and keeping a block counter in an untrusted location is a bad idea. And if you make your code obscure enough ("abstract" in all the wrong ways), then people will have a really hard time figuring stuff like this out. And no one does proofs on protocol implementations in practice. Yes, there are some. Yes, there has been some progress to apply it to e.g. OpenSSL — after everyone has been using it for critical infrastructure for decades — so there's like, literally, one practical implementation that has seen a sliver of formal verification.
    - nickpsecurity 8y ago
      There's tooling like Cryptol and SPARK to make this a lot easier than it was in the past. Cryptol can generate software or hardware that implements the high-level spec of the algorithm. Far as practical use, certainly not just one even though still extremely rare. Here's some more: Altran/Praxis Correct-by-Construction for a cert authority http://www.sis.pitt.edu/jjoshi/Devsec/CorrectnessByConstruction.pdf http://www.sis.pitt.edu/jjoshi/Devsec/CorrectnessByConstruct... Same company ports Skein from C to SPARK, finds trouble http://www.skein-hash.info/sites/default/files/SPARKSkein.pdf http://www.skein-hash.info/sites/default/files/SPARKSkein.pd... SPARK Ada is available under GPL and commercial licenses. The book below is quite easy to read compared to most stuff with formal methods. The companies building stuff like this usually also have tools to generate tests (property-based testing) from contracts/specs and can automatically turn anything you can't prove into runtime checks. Shocked it's not used more often in areas like smart contracts or cryptocurrency protocols. https://www.amazon.com/Building-High-Integrity-Applications-SPARK/dp/1107656842/ref=sr_1_1?ie=UTF8&qid=1538687861&sr=8-1&keywords=high+integrity+applications https://www.amazon.com/Building-High-Integrity-Applications-... Galois built Cryptol for NSA but open sourced it. https://www.cryptol.net/ https://www.cryptol.net/ Rockwell Collins built SHADE and some other tools for high-assurance crypto. They build stuff for the defense sector mainly funded by NSA. They even have a separation-preserving, verified CPU. http://www.csl.sri.com/users/shankar/VGC05/Hardin.pdf http://www.csl.sri.com/users/shankar/VGC05/Hardin.pdf
- yholio 8y ago
  The conclusion seems sensible with regard to implementations of a given, secure algorithm. But the title suggests a much wider claim: that closed source crypto in general, hiding everything from system design and primitive selection to implementation is just as secure as open source crypto, where the author expects and receives public scrutiny and must not rely on any obscurity. This wider claim still seems false to me.
  - Digital-Citizen 8y ago
    The wider claim that "Open-source crypto is no better than closed-source crypto" points to a problem with both the philosophy behind the open source development methodology which makes promises which it can't always deliver such as "open-source software has fewer bugs than closed-source software because more people have access to OSS and to its code" (as the article author put it). And there are significant problems with the logic of the article. This also points to why free software and open source aren't the same thing. Free software makes no promise to fewer bugs or other development methodology claims. Free software argues that the inequity of software non-freedom is unethical; software non-freedom is no way to treat computer users. Software non-freedom works against users spirit of cooperation and community. It is precisely this focus on ethics that the open source developmental methodology was founded to run away from. There are still show-stopper problems with the article's ridiculous claim: by definition nobody knows all that happens in so-called "closed source" software, better known as proprietary software. Any claims as to proprietary software security are unverifiable even if one is deeply familiar with a particular popular implementation of some proprietary software. So the title ("Open-source crypto is no better than closed-source crypto") immediately makes a claim it can't defend. The article also claims, without evidence, that "Paid security audits help but won’t find all the bugs, as they tend to be broader than they are deep.". That's quite a claim made on behalf of "paid security audits" -- they're "broader than they are deep". I'm not entirely sure what that means, but there's nothing in the article to indicate where one can find that survey data needed to back up that claim. Ultimately the article poses no challenge to a free software ethics-based understanding of proprietary software: no matter how difficult cryptography software is to fully understand, no matter how insecure current FLOSS cryptographic implementations are, that's no reason for equating software freedom with software non-freedom. Cryptographic software is no exception to the need for respecting computer user's software freedom. Software freedom lets us do as we wish with our copies of the published free software and thus control our computers and treat each other ethically. Software non-freedom invites dependency and apparently incentivizes malware (see https://www.gnu.org/proprietary/ https://www.gnu.org/proprietary/ for around 400 examples of proprietary malware). As that page says, the "initial injustice of proprietary software often leads to further injustices: malicious functionalities.". Why? https://www.gnu.org/proprietary/ https://www.gnu.org/proprietary/ explains: "Power corrupts; the proprietary program's developer is tempted to design the program to mistreat its users. (Software whose functioning mistreats the user is called malware.) Of course, the developer usually does not do this out of malice, but rather to profit more at the users' expense. That does not make it any less nasty or more legitimate. Yielding to that temptation has become ever more frequent; nowadays it is standard practice. Modern proprietary software is typically a way to be had."
gmuslera 8y ago
It can be said for most software categories. But for specially for crypto, trust matters a lot. Specially today with governments pushing for forcing backdoors in crypto.
m-p-3 8y ago
At least the open-source crypto can be proven to be good and audited by anyone. I'd rather use an open-source crypto than take a security russian roulette on a closed-source one.
webkike 8y ago
Let’s invert the thesis: closed source crypto is no better than open source crypto. So why on earth would you ever choose closed source components?
- NullPrefix 8y ago
  Because you get to pay money for closed source. And if you're paying, you can justify it for yourself that it's somehow better, because it costs money.
- TheDong 8y ago
  That's a logically false inversion, assuming you take 'no better than' to mean '<=' (as I think makes sense in context). OSS <= CSS does not imply CSS <= OSS... > why on earth would you ever choose closed source components There are often no open source alternatives to closed source things that are meaningfully equivalent. For example, the iPhone is a secure and closed source phone. There is no open source equivalent to that package. Android devices have critical closed source components with almost no exception, but also are not equivalent to an iphone in many meaningful ways. I think a better take-away is the nuanced "evaluate things on a case-by-case basis, don't let a security system having closed source components needlessly bias you"
  - deleted 8y ago
    [deleted]
  - webkike 8y ago
    I took “no better than” to mean approximately equal. I feel otherwise the author would have added “and possibly worse than”. I think your assumption however is probably more correct.
- throwawaymath 8y ago
  Hypothetically speaking, because you can get a better support contract with a closed (or semi-closed) source software vendor. Alternatively because closed source software is easier to monetize and likely has better resources to direct to feature development. But in practice almost all cryptography is deployed via open source software. Large tech companies like Google and Apple can develop reliable and safe closed source cryptography. But most companies don't because that's expensive and usually unnecessary.
alexandernst 8y ago
"Open source" doesnt mean it doesnt have bugs or backdoors. It just means that you can take the code, read it, and maybe find the bug/backdoor.
darawk 8y ago
Doesn't the very fact that he was so readily able to review these blockchain projects negate his thesis?
- TheDong 8y ago
  No. He's comparing it to closed source software he has also audited. CSS doesn't mean no one can see the code or that there aren't third-party audits.
  - Nullabillity 8y ago
    > CSS doesn't mean no one can see the code or that there aren't third-party audits. It does mean that there are no meaningful third-party audits. An audit (or benchmark, for that matter) that aims to be approved by the vendor is as useful as a rubber stamp.
    - TheDong 8y ago
      This is sometimes true, but not always. There are many auditors who will do a good and fair job. This is especially true if the audit is not intended to be publicly shared, but rather for the internal consumption of the company in question. I'd still say an audit where the reviewers are skilled professionals, but biased by the source of income, is better than the average open source project where few people will do such a thorough audit ever; likely none after the original author, excepting special cases like Linux.
  - darawk 8y ago
    I understand. But that is a pretty silly comparison for him to make. He's sampling two different universes. In the open source universe, everything is open to him, by definition. He has a complete sample space. In the closed source universe, he may only sample the companies who choose to contract his services. That is an extremely biased sample. Not to mention the basic fact that he's almost certainly not controlling for other factors, like project age, usage level, etc.
microcolonel 8y ago
So when Microsoft just refuses to roll out better crypto in some crucial piece of infrastructure (a network tunneling protocol perhaps) for years on end, and you can do nothing about it, that qualifies as "no better". I see, I see. Sure no cryptosystem is going to get better if nobody cares to actually validate it; but at least when it's open, you're allowed to fix it and move on (whether you're the first or six-millionth person to actually care whether it's good or not).
jerguismi 8y ago
I can easily write closed source crypto that will be absolute garbage. I can also write open source crypto that will be total shit. With enough seller skills I could convince some people to use the closed source crypto, I guess with open source crypto I would be called out quicker.
- watwut 8y ago
  Real world open crypto libraries have sometimes really atrocious code. Openssl being notorious. Open source is way to go imo, but the automatic assumption that it is good or someone reviewed it is wrong.
  - umvi 8y ago
    > or someone reviewed it Sometimes I wonder if everyone assumes everyone else has reviewed it, therefore nobody has reviewed it
    - watwut 8y ago
      It is awful lot of hard work and requires a lot of special knowledge not that many have. Plus it is guaranteed political fight afterwards. Average programmer don't know what to look for and can't do it over wekend.
  - nickpsecurity 8y ago
    I covered this in an essay about security of various models of source sharing. It came down to talent and methods of developers and reviewers being what determines trustworthiness of a specific project/product. Although my stuff is text (old school), roryokane on Lobste.rs kindly made a better-formated, HTML version here: https://gist.github.com/roryokane/d02addfa9329c579f15daef5b4ebae2f https://gist.github.com/roryokane/d02addfa9329c579f15daef5b4... EDIT: This also answers another commenter's question about when I'd trust closed-source software. Essentially if I trust the developer and/or reviewer. Then, I have to know I'm using the same thing. So, they have to publish signed hashes and so on of either the binary or source.
- 8y ago
fipple 8y ago
The advantage of using open source crypto is that when you get hacked so do a lot of other sites, so you become only one part of a big story.
hyperman1 8y ago
This is a strange way of thinking: For this kind of bug, OSS doesn’t necessarily win, when 82% of projects on Github have fewer than 45 stars (a figure I just made up, but you get the idea). It is true, but also irrelevant. Most OSS are orphaned hobby projects, and that's what he sees here. But when comparing to CSS, the relevant OSS is the small parts of it that has users, builds a community, etc.. For these projects, Linus' law is a serious win for OSS. This won't help the last category of hard bugs, but is a great booster for OSS that' missing from CSS. He's probably dead right about the hard bugs, BTW Additionally, OSS has another less visible bonus: Everybody tests their tooling on OSS simply because they can. If you write something like AFL, coverity, ... , you load tons of code from github and see how your tool behaves on it. Then you write a blog post with your great results. So you either have to file bugs against the OSS projects you scanned, or the community will think yo're an asshole. On the other hand, CSS has a less visible malus: The horrible quality of in-house tooling at governments, banks, etc... I've seen a case where a government Architect decided to encrypt every person's personal data with AES, using the birth date + a few extra digits as password, and write this in a spec posted on their site. An auditor saw AES and declared the protocol secure enough for transport over the public Internet. It took most of a year before our team got through to him that this amounts to about 20 bits of key space, i.e. brute force-able in a few minutes on a phone with its some interpreted language, live coded before his eyes in a meeting. (He then decided to pad the key with zeros until he got it to 256 bits. For some reason you're not allowed to whack government officials with their own spec, even when their IQ is below that of an average doorknob. But after long meetings we eventually got to a minimally sane encryption). And we were the only organization that 'caused so much trouble', the others either didn't understand the issue or simply didn't care. I am really really really scared about the security of anything governemental now.
- dejaime 8y ago
  I would say he misses a big point on the hard bugs though. Saying something is proprietary does not mean it makes enough money to hire such high caliber professionals, on the contrary. I have worked with a lot of extremely competent developers on open source, but my experience with proprietary software was quite the opposite: professionals are untrained (to the point where they can't even use versioning properly) and would be incapable of finding such bugs anyway. Now assuming that a proprietary cryptocurrency has the resources to hire a respectable audit firm... it is more far fetched than assuming that such star developers will just work on an open source one for fun.
theyinwhy 8y ago
If the company devloping the crypto dedicates the same amount of resources, would open or closed source crypto be more secure? For me the answer clearly is open source crypto.
msla 8y ago
Open-source crypto wins because it's never just crypto. It's a whole system with crypto as one element. The crypto may be the only hard part, but it's still just one part. Like in a password manager: Even if the crypto is somehow known-good, if the whole thing's closed-source, I don't know if the non-crypto parts aren't exfiltrating my plaintext passwords so my accounts can be sold to botters. In an open-source project, there's a good chance something like that will be caught without some bored person deciding to run Wireshark at the same time they're running a password manager.
amelius 8y ago
> Open-source crypto is no better than closed-source crypto If the weakest link is the hardware (e.g. Intel ME, or Chinese Trojan chip), then this proposition doesn't even matter much.
- noobermin 8y ago
  I think the author's point is that all things held equal, OSS crypto isn't better than CSS crypto in their experience.
jvehent 8y ago
Open Source crypto is no worse than closed source crypto. This is fantastic news and a strong validation of the open source development model for security systems. ;)
yitchelle 8y ago
Open source != good quality code
commandlinefan 8y ago
Well I guess the only logical solution is to roll your own, then.
tinus_hn 8y ago
The title is a bit vague and the article doesn’t really clarify. The point of the article is that open-source implementations of designs involving cryptography are no better than closed source implementations. The purported reason is that cryptography is difficult and therefore reviewers are unlikely to spot issues. I presume that much open-source software is written by hobbyists while a closed source software development company may hire a crypto expert for the sensitive code.
rurban 8y ago
I don't think it's a matter of open vs closed source, it's more a matter how many maintainers and contributors the projects has. As most bigger projects (>3 maintainers) show, the more contributors the worse is the quality of the code, and logically the rate of bugs is higher. Closed source projects typically have the best number of maintainers: 1-2. With open source it could easily degrade into a minefield, like with openssl, apache, linux, gnome, python, perl, ruby, node, ...
dejaime 8y ago
Ignoring the biggest problems of proprietary software (e.g. the fact that such software can be deactivated at any time for no reason, backdoors) and citing pseudo problems on free software. "You can also argue that OSS tends to be reused by other OSS, which amplifies the impact of a given bug." This guy clearly as a horse on that race.

83 points by throwawaymath 8y ago

The titular thesis of this article is that Linus' Law doesn't really apply to cryptographic security vulnerabilities. To lend some authority to that (probably controversial) claim: the author of this article is JP Aumasson, a well known cryptography researcher and engineer. There aren't many cryptographers who work in both theory and application the way Aumasson does. He recently wrote Serious Cryptography and has done professional cryptanalysis since 2012. He is also a co- or primary author for several cryptographic algorithms; including BLAKE/BLAKE2, NORX, SipHash, and Gravity SPHINCS. In the course of establishing his argument he groups cryptographic vulnerabilities into four main categories. The basic idea is that vulnerabilities in cryptography require a different set of skills to find than "regular" security vulnerabilities do. They also have different requirements for exploitation. Aumasson's overall point is that the higher difficulty of finding bugs in cryptography for each category means there won't be a meaningful difference in security between open and closed source code. And for what it's worth he's only talking about open versus closed source implementation here. He's not talking about Schneier's Law or closed source designs.

warkdarrior 8y ago
Did you mean Kerckhoffs's principle ("a cryptosystem should be secure even if everything about the system, except the key, is public knowledge")? Instead of Schneier's Law ("any person can invent a security system so clever that she or he can't think of how to break it").
- throwawaymath 8y ago
  I did, that's right! Thank you for the correction, I should've double checked that :)
snaky 8y ago
> The basic idea is that vulnerabilities in cryptography require a different set of skills to find than "regular" security vulnerabilities do That may be true for traditional low-level hand-optimized implementations. But if we consider the trend is clearly toward the high-level proof-based code[1], which is way easier to audit, then open source is obviously better. [1] "Simple High-Level Code For Cryptographic Arithmetic - With Proofs, Without Compromises" https://deepspec.org/entry/Paper/Simple+High.2DLevel+Code+For+Cryptographic+Arithmetic+.2D.2D+With+Proofs.2C+Without+Compromises https://deepspec.org/entry/Paper/Simple+High.2DLevel+Code+Fo...
- blattimwind 8y ago
  Most issues (apart from legacy asymmetric primitives) are actually either in the implementation (common in widely deployed software) or the design (even more common in widely deployed software) of higher level protocols. Many implementations issues in crypto code are just regular code bugs. Meanwhile, design issues are not so readily apparent. There is no linter that will tell you that using the same AES key for years and keeping a block counter in an untrusted location is a bad idea. And if you make your code obscure enough ("abstract" in all the wrong ways), then people will have a really hard time figuring stuff like this out. And no one does proofs on protocol implementations in practice. Yes, there are some. Yes, there has been some progress to apply it to e.g. OpenSSL — after everyone has been using it for critical infrastructure for decades — so there's like, literally, one practical implementation that has seen a sliver of formal verification.
  - nickpsecurity 8y ago
    There's tooling like Cryptol and SPARK to make this a lot easier than it was in the past. Cryptol can generate software or hardware that implements the high-level spec of the algorithm. Far as practical use, certainly not just one even though still extremely rare. Here's some more: Altran/Praxis Correct-by-Construction for a cert authority http://www.sis.pitt.edu/jjoshi/Devsec/CorrectnessByConstruction.pdf http://www.sis.pitt.edu/jjoshi/Devsec/CorrectnessByConstruct... Same company ports Skein from C to SPARK, finds trouble http://www.skein-hash.info/sites/default/files/SPARKSkein.pdf http://www.skein-hash.info/sites/default/files/SPARKSkein.pd... SPARK Ada is available under GPL and commercial licenses. The book below is quite easy to read compared to most stuff with formal methods. The companies building stuff like this usually also have tools to generate tests (property-based testing) from contracts/specs and can automatically turn anything you can't prove into runtime checks. Shocked it's not used more often in areas like smart contracts or cryptocurrency protocols. https://www.amazon.com/Building-High-Integrity-Applications-SPARK/dp/1107656842/ref=sr_1_1?ie=UTF8&qid=1538687861&sr=8-1&keywords=high+integrity+applications https://www.amazon.com/Building-High-Integrity-Applications-... Galois built Cryptol for NSA but open sourced it. https://www.cryptol.net/ https://www.cryptol.net/ Rockwell Collins built SHADE and some other tools for high-assurance crypto. They build stuff for the defense sector mainly funded by NSA. They even have a separation-preserving, verified CPU. http://www.csl.sri.com/users/shankar/VGC05/Hardin.pdf http://www.csl.sri.com/users/shankar/VGC05/Hardin.pdf
yholio 8y ago
The conclusion seems sensible with regard to implementations of a given, secure algorithm. But the title suggests a much wider claim: that closed source crypto in general, hiding everything from system design and primitive selection to implementation is just as secure as open source crypto, where the author expects and receives public scrutiny and must not rely on any obscurity. This wider claim still seems false to me.
- Digital-Citizen 8y ago
  The wider claim that "Open-source crypto is no better than closed-source crypto" points to a problem with both the philosophy behind the open source development methodology which makes promises which it can't always deliver such as "open-source software has fewer bugs than closed-source software because more people have access to OSS and to its code" (as the article author put it). And there are significant problems with the logic of the article. This also points to why free software and open source aren't the same thing. Free software makes no promise to fewer bugs or other development methodology claims. Free software argues that the inequity of software non-freedom is unethical; software non-freedom is no way to treat computer users. Software non-freedom works against users spirit of cooperation and community. It is precisely this focus on ethics that the open source developmental methodology was founded to run away from. There are still show-stopper problems with the article's ridiculous claim: by definition nobody knows all that happens in so-called "closed source" software, better known as proprietary software. Any claims as to proprietary software security are unverifiable even if one is deeply familiar with a particular popular implementation of some proprietary software. So the title ("Open-source crypto is no better than closed-source crypto") immediately makes a claim it can't defend. The article also claims, without evidence, that "Paid security audits help but won’t find all the bugs, as they tend to be broader than they are deep.". That's quite a claim made on behalf of "paid security audits" -- they're "broader than they are deep". I'm not entirely sure what that means, but there's nothing in the article to indicate where one can find that survey data needed to back up that claim. Ultimately the article poses no challenge to a free software ethics-based understanding of proprietary software: no matter how difficult cryptography software is to fully understand, no matter how insecure current FLOSS cryptographic implementations are, that's no reason for equating software freedom with software non-freedom. Cryptographic software is no exception to the need for respecting computer user's software freedom. Software freedom lets us do as we wish with our copies of the published free software and thus control our computers and treat each other ethically. Software non-freedom invites dependency and apparently incentivizes malware (see https://www.gnu.org/proprietary/ https://www.gnu.org/proprietary/ for around 400 examples of proprietary malware). As that page says, the "initial injustice of proprietary software often leads to further injustices: malicious functionalities.". Why? https://www.gnu.org/proprietary/ https://www.gnu.org/proprietary/ explains: "Power corrupts; the proprietary program's developer is tempted to design the program to mistreat its users. (Software whose functioning mistreats the user is called malware.) Of course, the developer usually does not do this out of malice, but rather to profit more at the users' expense. That does not make it any less nasty or more legitimate. Yielding to that temptation has become ever more frequent; nowadays it is standard practice. Modern proprietary software is typically a way to be had."

gmuslera 8y ago

It can be said for most software categories. But for specially for crypto, trust matters a lot. Specially today with governments pushing for forcing backdoors in crypto.

m-p-3 8y ago

At least the open-source crypto can be proven to be good and audited by anyone. I'd rather use an open-source crypto than take a security russian roulette on a closed-source one.

webkike 8y ago

Let’s invert the thesis: closed source crypto is no better than open source crypto. So why on earth would you ever choose closed source components?

NullPrefix 8y ago
Because you get to pay money for closed source. And if you're paying, you can justify it for yourself that it's somehow better, because it costs money.
TheDong 8y ago
That's a logically false inversion, assuming you take 'no better than' to mean '<=' (as I think makes sense in context). OSS <= CSS does not imply CSS <= OSS... > why on earth would you ever choose closed source components There are often no open source alternatives to closed source things that are meaningfully equivalent. For example, the iPhone is a secure and closed source phone. There is no open source equivalent to that package. Android devices have critical closed source components with almost no exception, but also are not equivalent to an iphone in many meaningful ways. I think a better take-away is the nuanced "evaluate things on a case-by-case basis, don't let a security system having closed source components needlessly bias you"
- deleted 8y ago
  [deleted]
- webkike 8y ago
  I took “no better than” to mean approximately equal. I feel otherwise the author would have added “and possibly worse than”. I think your assumption however is probably more correct.
throwawaymath 8y ago
Hypothetically speaking, because you can get a better support contract with a closed (or semi-closed) source software vendor. Alternatively because closed source software is easier to monetize and likely has better resources to direct to feature development. But in practice almost all cryptography is deployed via open source software. Large tech companies like Google and Apple can develop reliable and safe closed source cryptography. But most companies don't because that's expensive and usually unnecessary.

alexandernst 8y ago

"Open source" doesnt mean it doesnt have bugs or backdoors. It just means that you can take the code, read it, and maybe find the bug/backdoor.

darawk 8y ago

Doesn't the very fact that he was so readily able to review these blockchain projects negate his thesis?

TheDong 8y ago
No. He's comparing it to closed source software he has also audited. CSS doesn't mean no one can see the code or that there aren't third-party audits.
- Nullabillity 8y ago
  > CSS doesn't mean no one can see the code or that there aren't third-party audits. It does mean that there are no meaningful third-party audits. An audit (or benchmark, for that matter) that aims to be approved by the vendor is as useful as a rubber stamp.
  - TheDong 8y ago
    This is sometimes true, but not always. There are many auditors who will do a good and fair job. This is especially true if the audit is not intended to be publicly shared, but rather for the internal consumption of the company in question. I'd still say an audit where the reviewers are skilled professionals, but biased by the source of income, is better than the average open source project where few people will do such a thorough audit ever; likely none after the original author, excepting special cases like Linux.
- darawk 8y ago
  I understand. But that is a pretty silly comparison for him to make. He's sampling two different universes. In the open source universe, everything is open to him, by definition. He has a complete sample space. In the closed source universe, he may only sample the companies who choose to contract his services. That is an extremely biased sample. Not to mention the basic fact that he's almost certainly not controlling for other factors, like project age, usage level, etc.

microcolonel 8y ago

So when Microsoft just refuses to roll out better crypto in some crucial piece of infrastructure (a network tunneling protocol perhaps) for years on end, and you can do nothing about it, that qualifies as "no better". I see, I see. Sure no cryptosystem is going to get better if nobody cares to actually validate it; but at least when it's open, you're allowed to fix it and move on (whether you're the first or six-millionth person to actually care whether it's good or not).

jerguismi 8y ago

I can easily write closed source crypto that will be absolute garbage. I can also write open source crypto that will be total shit. With enough seller skills I could convince some people to use the closed source crypto, I guess with open source crypto I would be called out quicker.

watwut 8y ago
Real world open crypto libraries have sometimes really atrocious code. Openssl being notorious. Open source is way to go imo, but the automatic assumption that it is good or someone reviewed it is wrong.
- umvi 8y ago
  > or someone reviewed it Sometimes I wonder if everyone assumes everyone else has reviewed it, therefore nobody has reviewed it
  - watwut 8y ago
    It is awful lot of hard work and requires a lot of special knowledge not that many have. Plus it is guaranteed political fight afterwards. Average programmer don't know what to look for and can't do it over wekend.
- nickpsecurity 8y ago
  I covered this in an essay about security of various models of source sharing. It came down to talent and methods of developers and reviewers being what determines trustworthiness of a specific project/product. Although my stuff is text (old school), roryokane on Lobste.rs kindly made a better-formated, HTML version here: https://gist.github.com/roryokane/d02addfa9329c579f15daef5b4ebae2f https://gist.github.com/roryokane/d02addfa9329c579f15daef5b4... EDIT: This also answers another commenter's question about when I'd trust closed-source software. Essentially if I trust the developer and/or reviewer. Then, I have to know I'm using the same thing. So, they have to publish signed hashes and so on of either the binary or source.
8y ago

fipple 8y ago

The advantage of using open source crypto is that when you get hacked so do a lot of other sites, so you become only one part of a big story.

hyperman1 8y ago

This is a strange way of thinking: For this kind of bug, OSS doesn’t necessarily win, when 82% of projects on Github have fewer than 45 stars (a figure I just made up, but you get the idea). It is true, but also irrelevant. Most OSS are orphaned hobby projects, and that's what he sees here. But when comparing to CSS, the relevant OSS is the small parts of it that has users, builds a community, etc.. For these projects, Linus' law is a serious win for OSS. This won't help the last category of hard bugs, but is a great booster for OSS that' missing from CSS. He's probably dead right about the hard bugs, BTW Additionally, OSS has another less visible bonus: Everybody tests their tooling on OSS simply because they can. If you write something like AFL, coverity, ... , you load tons of code from github and see how your tool behaves on it. Then you write a blog post with your great results. So you either have to file bugs against the OSS projects you scanned, or the community will think yo're an asshole. On the other hand, CSS has a less visible malus: The horrible quality of in-house tooling at governments, banks, etc... I've seen a case where a government Architect decided to encrypt every person's personal data with AES, using the birth date + a few extra digits as password, and write this in a spec posted on their site. An auditor saw AES and declared the protocol secure enough for transport over the public Internet. It took most of a year before our team got through to him that this amounts to about 20 bits of key space, i.e. brute force-able in a few minutes on a phone with its some interpreted language, live coded before his eyes in a meeting. (He then decided to pad the key with zeros until he got it to 256 bits. For some reason you're not allowed to whack government officials with their own spec, even when their IQ is below that of an average doorknob. But after long meetings we eventually got to a minimally sane encryption). And we were the only organization that 'caused so much trouble', the others either didn't understand the issue or simply didn't care. I am really really really scared about the security of anything governemental now.

dejaime 8y ago
I would say he misses a big point on the hard bugs though. Saying something is proprietary does not mean it makes enough money to hire such high caliber professionals, on the contrary. I have worked with a lot of extremely competent developers on open source, but my experience with proprietary software was quite the opposite: professionals are untrained (to the point where they can't even use versioning properly) and would be incapable of finding such bugs anyway. Now assuming that a proprietary cryptocurrency has the resources to hire a respectable audit firm... it is more far fetched than assuming that such star developers will just work on an open source one for fun.

theyinwhy 8y ago

If the company devloping the crypto dedicates the same amount of resources, would open or closed source crypto be more secure? For me the answer clearly is open source crypto.

msla 8y ago

Open-source crypto wins because it's never just crypto. It's a whole system with crypto as one element. The crypto may be the only hard part, but it's still just one part. Like in a password manager: Even if the crypto is somehow known-good, if the whole thing's closed-source, I don't know if the non-crypto parts aren't exfiltrating my plaintext passwords so my accounts can be sold to botters. In an open-source project, there's a good chance something like that will be caught without some bored person deciding to run Wireshark at the same time they're running a password manager.

amelius 8y ago

> Open-source crypto is no better than closed-source crypto If the weakest link is the hardware (e.g. Intel ME, or Chinese Trojan chip), then this proposition doesn't even matter much.

noobermin 8y ago
I think the author's point is that all things held equal, OSS crypto isn't better than CSS crypto in their experience.

jvehent 8y ago

Open Source crypto is no worse than closed source crypto. This is fantastic news and a strong validation of the open source development model for security systems. ;)

yitchelle 8y ago

Open source != good quality code

commandlinefan 8y ago

Well I guess the only logical solution is to roll your own, then.

tinus_hn 8y ago

The title is a bit vague and the article doesn’t really clarify. The point of the article is that open-source implementations of designs involving cryptography are no better than closed source implementations. The purported reason is that cryptography is difficult and therefore reviewers are unlikely to spot issues. I presume that much open-source software is written by hobbyists while a closed source software development company may hire a crypto expert for the sensitive code.

rurban 8y ago

I don't think it's a matter of open vs closed source, it's more a matter how many maintainers and contributors the projects has. As most bigger projects (>3 maintainers) show, the more contributors the worse is the quality of the code, and logically the rate of bugs is higher. Closed source projects typically have the best number of maintainers: 1-2. With open source it could easily degrade into a minefield, like with openssl, apache, linux, gnome, python, perl, ruby, node, ...

dejaime 8y ago

Ignoring the biggest problems of proprietary software (e.g. the fact that such software can be deactivated at any time for no reason, backdoors) and citing pseudo problems on free software. "You can also argue that OSS tends to be reused by other OSS, which amplifies the impact of a given bug." This guy clearly as a horse on that race.