We need to talk about encryption and data safety. Yes, encryption can be complicated at times. The effort is certainly worth it and, in today’s state of affairs with mass surveillance, the effort is almost mandatory. Hackers abound, alphabet agencies and First World governments are bulk collecting, and even for-profit companies are trading in consumer data and profiles like they are baseball cards.
This post isn’t going to go into the fathom depths of technicalities. Encryption is my job, however, and it has quickly become a hobby as I see data stolen, sifted and traded in the 21st Century. We are going to fracture the whole of encryption into three separate pieces in order to categorize and discuss them. These are proprietary, open-source , and end-to-end encryption. No, these categories aren’t on the same plane, nor are they mutually exclusive of each other. But they serve our discussion for today.
PROTIP: You never have, nor will you ever, read on this blog anything regarding “military-grade encryption.” The reason for this is elementary: it’s bullshit. There is no such thing as military-grade encryption – there are military standards for encryption levels, and those levels are available to everyone on the Internet. If you ever hear someone talk about it seriously, walk away. If you read about it online, close the tab and never go back. Military-grade encryption is not a special program or service available only to the military. Anyone that tries to sell products or services as such are either grossly inept at encryption or are not on the level about their products. I would insta-distrust someone if they used that term.
Encryption methods are either proprietary or open-source code. Proprietary means closed-source. That is, it is developed as copyrighted methods or products, and its code (or, source) is closed for inspection or public view. Think of KFC’s chicken recipe or Coke. You know what the product is and what it does, but you don’t and won’t ever know what exactly goes into making it. Microsoft’s BitLocker encryption that is part of Windows Professional operating systems or Enterprise editions is a prime example. Does BitLocker encryption work? Absolutely. Is it good enough to stop hackers if your computer is physically stolen? You bet. Good enough to be a safe harbor for HIPAA protection of Protected Health Information? Sure is. Able to stop the NSA? Not a chance.
It’s the last bit of the preceding paragraph that should grab you. It won’t stop a government from accessing your data. Microsoft builds the encryption into the operating system, and not around it as an outer shell. Microsoft may or may not have back doors built into it. The public won’t ever know, because the public can’t view the source to inspect with certainty for back doors. So if it can’t be proven no back doors exist, then the possibility (even if not probability) exists.
Is that to say proprietary encryption has no use? Certainly not. BitLocker is fast with little to no overhead on the computer’s boot times or resources. In many cases, it’s good enough. ProtonMail, encrypted email based in Switzerland, is the same. There are plenty of times when ProtonMail is sufficient for emailing colleagues.
The converse to proprietary is open-source. By definition, open-source means the source code (or, recipe) is open for any and all to view, modify for their own use, or fork and make a branch to create their own version based on the original source (with some caveats like it has to stay open-source or you have to attribute the original code, etc.). The now-abandoned TrueCrypt is/was an open-source encryption program. VeraCrypt is a fork of TrueCrypt, and a current open-source encryption program still maintained and quite the successor. I have personally read through the source code of VeraCrypt version 1.16 as well as version 1.18a (as of this post, the current version). GPG encryption (for email, as well as data) is another open-source example
The benefit with open-source code is two-fold: the public at large can inspect it to look for holes or bugs; and the public’s scrutiny for bugs aids the developer and strengthens the code overall.
Finally, the discussion needs to include end-to-end encryption. This is when a message is encrypted by the sending party before transmission occurs, and is only decrypted after the recipient receives the message and has it on a device. The importance here is that no party in between the sender and recipient can open the encryption (telcomm, Internet Service Provider, software maker, etc.). Skype uses end-to-end encryption, as do many other messaging services like Wickr, WhatsApp, iMessage, Signal, ProtonMail and others.
So end-to-end encryption is the silver bullet, right? Unfortunately, no. End-to-end encryption can be susceptible to man-in-the-middle attacks, spoofing the sender or recipient, and a host of endpoint security issues (if the sending or receiving device has been compromised before the message was sent or received). But overall, end-to-end encryption can be very strong…
The main caveat to end-to-end encryption is one of the other fractions previously discussed: proprietary software. Skype is a messaging service with end-to-end encryption. But, what if Microsoft can open that message with a backdoor on a whim from an NSA request? End-to-end encryption means nothing at that point. Strong encryption uses open-source software with very long, random passwords to lock it. Strongly encrypted messages must further employ open-source encryption with end-to-end encryption. When emailing or instant messaging critical data, both end-to-end and open-source encryption must be used, along with good endpoint (device) security and strong security methods (no reuse of passwords, no sharing of passwords, no malware infections on the endpoint, etc.).
That means the strongest encrypted email would have to use open-source encryption and end-to-end methods. This is why GPG encryption methods are preferred for email. But, you have to have the technical know-how to generate your own private keys (to encrypt your data) and public keys (so others can encrypt data to send you). Both private and public keys are required to unlock GPG encryption emails. If a reader were to send me a GPG-encrypted email, they would have to use their private key and my public key to encrypt it. That way, only they and I can open or read it. No other private or public keys will work. Conversely, to send them a GPG-encrypted email, I would use my private key and their public key. What if I didn’t already have their public key? I couldn’t send them a GPG-encrypted email. Public key exchanges are a prerequisite to GPG-encrypted emails. This is why you see more and more journalists post their public keys in their signature lines of their online articles, to facilitate receiving truly encrypted emails from someone.
If you are interested in setting up your own GPG keys and encyrption, download GPG4Win (with Kleopatra already built in) to create your keys and Mozilla’s Thunderbird email client with the add-on EnigMail to send/receive and use GPG keys. Protip: when creating GPG keys, never forget to set an expiration date on the key (meaning, it’s good forever). EVER! And, don’t accidentally give out your private key when you mean to give out your public key.
My public key for my email address of c [dot] robertson95 [at] gmail [dot] com is: 6894 4162 AD3B D3AF 43BD 37E7 CE20 34C2 0395 040F
…No, you can’t have my primary secure email address(es) :p
Featured image used under CC license from Pixabay.com