4 ms·

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

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

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