Posted 1 month, 1 week ago
Code source for encryption and other cybersecurity software is a sticky topic for many in the information security world. In one camp, you’ll find those who champion open source software as being inherently more secure. And opposite them, you’ll see those who say proprietary is the only way to go since open source has no accountability attached to it. The broader open-source vs closed-source debate has been raging for decades, since the early days of software. Both sides have their prominent proponents and just as prominent opponents.
So what’s a company to do when looking for strong end-to-end security solutions? If you go with open-source, you’ll please some of your stakeholders and at the same time cause some to go ballistic with concern. Yet, if you go with closed-source, you’ll have the exact same effect just in reverse.
Here’s the bottom line—open-source software (OSS) is simply more secure than closed-source, or black-box software. There are many reasons for this, and we’ll be looking at several of them today. Cybersecurity measures, particularly email encryption, secure your communications with trusted partner organizations, individuals, and act as a buffer between your network and nefarious fraudsters looking to infiltrate and steal your confidential data--and you, not a third party, needs to be in control of that security. It’s for that simple reason that you should be considering an open-source email encryption solution.
In short, to keep unauthorized entities from seeing their contents, right? You know that scene in every action movie where the good guy handcuffs a locked briefcase to their wrist? They don’t have the key for the briefcase, just for the handcuffs. Only the person who put the confidential dossier in the case and the intended recipient have the briefcase key. End-to-end email encryption works a lot like that briefcase. At no point during transport can any unauthorized third party see what’s in your message.
Back in the real world, you have confidential corporate data that you need to share with a trusted partner. So you use an e2e encryption solution to lock down the communication channels you have with them. The software uses your private key to lock and sign the data in an encrypted, virtual briefcase before it leaves your computer. Then upon receipt, the partner uses their key to open the briefcase once it’s safely on their desk. At no point during transit was that data accessible or even visible to an intruder.
But, there are two potential threats to the security of the documents in that briefcase. First, there’s the guard who handcuffs the briefcase to his wrist. If he also built the briefcase based on proprietary designs, he might know some secret backdoor for opening it up and accessing its contents. Second, there’s the possibility of someone scanning the contents, then reading it later, after they have time to decipher the scan.
For your data to be truly secure, the only people who should be able to get that briefcase open are you and the individual you sent it to. Or, back in the real world, you and the recipient of the email you’re sending.
Since the soundness of the underlying software generating your encryption keys is one of the critical aspects of securing the contents of your emails, ensuring said soundness should be a top priority. Looking back on the briefcase analogy, would you rather have an outside specialist go over the plans for the briefcase before you trust it to secure your top-secret dossier? We sure would. Remember, knowing how the briefcase was built says nothing about the ease or difficulty of obtaining the key.
What this independent scrutiny provides is verification that the briefcase is indeed solid, doesn’t have a hidden backdoor through the hinges, and that the contents can’t be scanned by a handheld scanner or other device. Back to encryption software: by allowing a world-wide community of crypto experts to analyze the code behind the encryption scheme, open-source security software offers an inherently higher level of security. The sheer number of eyes potentially reading the code means that any bugs, potential backdoors, or sketchy code can be located and eradicated, fast.
As you’ll see momentarily, this openness is what leads to OSS being the stronger option when it comes to security in general and email encryption in particular, versus the black-box style offerings where you have to take the producer’s word for its security.
This access is what prevents catastrophic results, like what happened when it came out that a prominent provider of cryptography machines and cipher devices was intentionally building in backdoors to allow for state-sponsored espionage. We’re talking about the Crypto AG scandal from a couple of months ago.
Crypto AG was a Swiss manufacturer of security devices founded in the 1950s. It was later bought by the US’s CIA and the former West Germany’s Federal Intelligence Service. Since they used dummy corporations and other means to hide the true nature of this ownership, the company was able to continue selling its devices and services to everyone from major multinational corporations to government bodies around the world.
The scandal broke when it was discovered that for decades, Crypto AG was building in backdoors, allowing access to the data being encrypted, including state secrets.
This is admittedly an extreme example, but it serves our purposes here in that it was the black-box nature of the Crypto AG products that allowed this subterfuge to continue for decades.
Existing crypto libraries are constantly scrutinized and updated, so they are already less vulnerable to the latest flaws or bugs. New code releases are descended upon by scores of these experts within moments of their release. Bugs are then either fixed and noted or pointed out to the developers for attention. This instant feedback cycle means that within days of initial release the code has been shored up and all potentially exploitable flaws have been patched. That sounds like an added layer of security to us.
Once again, it’s key to remember that this access to the base code is NOT the same thing as access to your confidential content. If there are flaws in the encryption, an attacker or other actor finding a zero-day or exploiting a backdoor or opening a vulnerability becomes an attack vector. But if the software supporting the encryption is really safe and free of backdoors then access to the code base wouldn’t be nearly enough to decrypt the messages you're sending. As long as your private key remains private, even the encryption providers themselves won’t be able to break the encryption.
This sort of complete visibility means that when a flaw is found in open-source software, it’s fixed immediately. If not, the developer’s reputation would take a dive since the flaw is known and everybody in the community is watching for their response. The transparency of an open-source project leads to two primary sources of accountability: the developer wanting to maintain their standing, and their desire to keep their users happy and using their product.
By alerting that user base to the discovery of an exploit or bug, the developer is able to mitigate damage to both their reputation AND the users’ data. Assuming there are no bugs to be found, this kind of validation by experts leads to much more reliable protection than the kinds of external certifications that black-box encryption solutions receive. Need we remind you that the NIST encryption standard contained a deliberate backdoor for years? With an open source solution, no such backdoor could remain hidden for long.
Just like its non-crypto counterpart in the OSS community, open encryption algorithms are immediately analyzed by an expert community of cryptanalysts – potentially from around the globe. This multiplication of not only eyes on the code but also different cultural origins means that the examination this code is given is many times more exacting than anything a single developer or in-house team could provide.
Black-box solutions are created in-house, tested in-house, and released without an ongoing global-scale code-check. The user is then asked simply to trust that it is secure and that all flaws, backdoors, exploits, and bugs have been found prior to release--and that the provider hasn’t pulled a Crypto AG and added a backdoor intentionally. When was the last time you ran a software update on a commercial package, only to have a bug fix released the very next day? If that had been your email encryption software, how many emails could have been sent with faulty encryption in the time it took the software company to announce that fix, let alone get it published?
As in our briefcase analogy above, where the main entry point would be the lock on the briefcase itself, with encryption the entry point is the key, not the algorithm that generates it. Even in the case of black-box algorithms, there are so many crackers out there that even these “secret” and “proprietary” algorithms aren’t secure. Knowing HOW the key is generated doesn’t help the hacker obtain the key itself.
Unlike secretive black-box encryption, OSS doesn’t have a single entity behind it. Those single entities can have ulterior motives, like answering to a silent partner, that can trump your privacy concerns. Alternatively, OSS projects have that worldwide community of experts that stand behind their product and analysis. These individuals (or teams in some cases) rely on the product to be proof of their professionalism and build their reputations from there.
End-to-end email encryption is just as important for the privacy of your company’s confidential data as a strong network security solution, if not more so since the data is inherently vulnerable when it leaves the relative security of your network.
p≡p’s solution is built on the principles that we’ve outlined above: Our open source software is subject to stringent code reviews and analysis by expert cryptographers, and our builds are entirely reproducible. Our solution is truly peer-to-peer, which means that there’s no centralization and no way for us to read the messages you send using our technology. Plus, it’s all automated and invisible to email users—this means that companies can just plug and play in order to reduce susceptibility to phishing and business email compromise overnight. We ensure confidentiality, integrity, and authenticity for your email messages, and we automatically swap out and store public and private keys, so your security standards never loosen due to user error. Other businesses ask for your trust in their encryption based on outside certifications, but our open source principles mean that you can see for yourself that there’s no vulnerabilities or backdoors in our code.
p≡p Security launches p≡p for Thunderbird and p≡p for iOS, together with new versions for Outlook and Android
Sept. 7, 2020, 6 a.m.