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").
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.
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/ 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/ 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."
The claim is the authors opinion. It’s a blog post not a study. I believe is he correct. Paid security audits are indeed broad and rarely deep.
The reason why is so obvious to anyone who’s engaged in them that what you’re asking for is like demanding a study that restaurants are more crowded around lunch time.
Paid security auditors must deliver vulnerability findings. The end. Deliver findings, get paid. Failing to deliver findings means not getting hired by that client again, or, in the case of bug bounties not getting paid at all. It really cannot be understated that if you are a professional auditor sitting at some client site you absolutely, positively need to be adding findings to the report. If you develop a pattern of not finding things then your colleagues will not respect you or want to work with you anymore.
Therefore, it is only rational to look broadly at the target for common classes of bug. There just isn’t time to deeply understand the target, and it’s foolish to try when everyone else just looking for common mistakes gets more findings and by virtue is more productive/valuable than you.
People have been known to make serious errors in judgment before examining evidence because they felt so sure about their widely-shared opinion. Glenn Greenwald pointed this out in regards to Omar Mateen's killings in the Orlando, Florida nightclub ("Pulse") in https://theintercept.com/2018/03/05/as-the-trial-of-omar-mat...
"Mateen’s alleged motive in choosing Pulse — that he wanted to target and kill LGBTs due to some toxic mix of self-hatred over his own sexual orientation and his fealty to Islam — has been treated as unquestionably true in countless media accounts, statements from public officials, and ultimately in the public mind. But ample evidence now affirmatively casts serious doubt about whether there is any truth to this widely accepted belief about Mateen’s motives in attacking Pulse. While some of this conflicting evidence has been reported in the same media outlets that originally disseminated the narrative that Mateen sought to target the LGBT community, it has been downplayed to the point where few in the public are even aware that the original theories about Mateen’s motives have been undermined."
The point being that people formed their view before the evidence was in. After the evidence was examined people learned that their view was nowhere near as justified as they initially believed and told others. They should learn that it's not helpful to guess about why something happened without the evidence. Although what we're talking about in this thread could theoretically involve life and death matters (whereas the Pulse murders objectively do), I think there's something to learn in calling for evidence before formulating one's opinion. Something that blog post doesn't do and we'd be wise to not join the author in that framing of the issue.
I do strongly support the claim that security audits are usually broader than deep because I do that kind of work and am personally familiar with the pressures and motivations described.
In my own experience, and in the experience of all of my friends who do this work, with whom I have discussed this exact topic at great length, the majority of the time we are in fact structurally restricted from going deeper. It doesn't mean this is all the time, but it is the case for most of the billable hours doing this stuff. It pays reliably going broad and not deep.
But you're totally right. That's just like, my opinion man.
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+Fo...
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.
Altran/Praxis Correct-by-Construction for a cert authority
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.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-...
Galois built Cryptol for NSA but open sourced it.
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.
You disprove your own assertion. Cryptography is very specialized. All specializations in this world require specialized knowledge and niche experience, cryptography included. Assumptions about the obviousness of a specialization is almost itself the definition of an error.
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.