What to worry about when using encryption

I just published PassLok Universal and began promoting it more or less in earnest, and ran into a few articles reviewing competing products. What I saw left me somewhat puzzled. Hence this article, which I hope will clarify things for readers (perhaps after confusing them first).

I began developing PassLok and its derivatives before the Snowden revelations. Why? Because it hit me that, sooner or later, people were going to want to exchange very confidential data over Internet, and email and such are more like writing on postcards. Sure enough, it turned out that those electronic postcards were being routinely scanned by the “good guys” (we want to think). What the “bad guys” were and are doing is anyone’s guess, but email and text haven’t gotten any more secure since.

The difference is that now there are a number of offerings besides mine touting security for email and suchlike, but are they really secure? Let’s begin with an example.

Google said, back in 2014, that their Gmail service was going to have end-to-end encryption very soon. A few months later they open-sourced their effort via a GitHub page. Not much has happened since. For all we know, nobody associated with Google is working on this anymore. My take, and I’m not the only one saying this, is that they realized the email encryption ran directly against their business model, which requires them to be able to read your stuff in order to serve you targeted ads.

This vacuum has allowed a number of competing email services to spring up and thrive somewhat. Here’s an article of mine on the most prominent of the bunch. But are they really more secure than Gmail?

Perhaps we should begin with a more basic question: what’s the point of encryption anyway? Who is it that I don’t want them to read my stuff? Is it hackers? Google? The Russians? The US Government? And then, why?

Which brings in the related question: Why should I be using encryption when I don’t anything to hide?

So let’s start with the last question, which has an easy answer: You don’t have anything to hide . . . until you do, and then you’ll be glad you know how to do it. You see, we are moving from a paper-based economy to an electronic one, but the transition is not yet complete. My doctor likes to fax tests and prescriptions, and is rather insistent about my standing right next to the fax machine when he sends me something. My lawyer says his firm a special secure mail for the firm (though he hasn’t used it for my patent correspondence). My contractor friend sometimes mails, sometimes faxes, sometimes uses email for contracts and bids, and sometimes he just has someone walk the documents over to the other guy’s office. But this kind of thing is going to look primitive sometime soon. Electronic communication of confidential data is the thing, and the sooner we learn how to use it, the better.

Having settled that everybody is going to have to send or receive confidential data by electronic means sooner or later, we can move on to answering the first question: who am I protecting my data against? But first, I’ll use this paragraph for a quick rundown on how conventional email works, which you may want to skip if you know already. You write your email in a computer, whether through a web page of a native app, which sends it to a server. Today this first communication is typically done using TLS, which means that the transfer from your computer to the server is encrypted (using a one-time key that is discarded after the transfer is complete), but the data itself is not, so that the server is perfectly able to read what you sent. Then the server on your end (say, Gmail or Yahoo, or a private server at your workplace) will send it to the recipients’ servers using the Internet backbone. If your are on Gmail and the recipient is also on Gmail or a corporate email provided by Google, then this second step is internal to the server and your data is never exposed, but if the recipient’s server is different, then your data will be exposed as it travels from one server to another, which typically takes several server-to-server transfers, all of which can read your precious confidential data if it’s not encrypted from source. According to this article, back in 2016 as much as 76% of traffic between Gmail and other mail servers was encrypted in transit, which is awesome, but you cannot know ahead of time which servers have this arrangement with Gmail. When the recipient logs in, his/her/its server transmits the data to the private computer, likely also by TLS.

In other words, the weakest links are:

  • Your server or the recipients’ servers, which might not be fully trustworthy. Indeed Google, to name one, has a history complying with “legal” requests for users’ data a bit too easily. Is your email provider on the same list?
  • The transmission between servers, about which you have no control whatsoever unless your recipients are on the same server (or system of servers, like Gmail) as yourself.

Observe that your computer, or the recipients’ computers, or the links between those and their respective servers, are not nearly as problematic as what I mention above. It’s the servers, stupid! Which brings the obvious question: how can I be assured that I can trust them?

Short answer: you can’t. Even if you’d trust your own server with your life (maybe because you are running it), what about the recipients’ servers, or the sender’s server if you are on the receiving end? For all you know, they could be recording everything you send them in order to give it to the North Korean government. Sure, lots of promises of confidentiality, servers located under a secret mountain in the middle of Switzerland, and all that. But how can you be sure?

The only way to make sure is to encrypt everything on your end, and have recipients decrypt on their end. The much touted (but seldom implemented, as we saw above) end-to-end encryption. But this is hard to use, isn’t it?

That depends. It is hard if you are using PGP or RSA, which amounts to the same, and which is the current standard that works quite well for communications between computers. But there are equally secure methods that aren’t nearly as hard. And here’s my one-line plug for PassLok, which is based on 255-bit elliptic curves and uses public keys so short that you can send out with every message, and manage automatically. And with PassLok Universal, you can use any email server. End of plug.

To be fair, there are some services that make using PGP a snap. Here are a couple:

  • Proton Mail uses PGP to encrypt and decrypt locally on your computer. This is why it asks you for two passwords: one to log in to the server, and the other for encryption. Their server knows the first one, but not the second. The problem is that you have to use their servers, and pretty much also the recipients as well so the decryption process goes smoothly. Of course, that’s what they want in order to make money.
  • FlowCrypt does the same thing, but as a plugin for Gmail. Here you have to use the Gmail password, which typically is automatic, and then FlowCrypt asks you for the encryption password whenever it’s needed. Again, the problem is that, since FlowCrypt only works with Gmail, both senders and recipients must be on Gmail, which begs the question: who am I defending against? Answer: only Google, since they are the only ones who would be able to see your data.

In fact, the case of Proton Mail is not that different: it’s only Proton Mail itself that could possibly see your data, since you are communicating with users of the same service. If you trust them to begin with (after all, they are supplying the encryption code, and they are managing your encryption keys), keeping them from possibly being able to read your data doesn’t add a lot to what you are already entrusting them.

This could be said of every solution out there. They are saying, “Don’t trust the others, but trust us! We’re the good guys!” Why, I’m saying the same with my apps, but at least you can see all the code as it runs, whereas my competitors can’t do that because you can’t see code that doesn’t run on your machine. Funny thing is, people tend to trust those who charge them money, which gives them the impression of quality, but this really has nothing to do with trust.

I have good friends who judge wines, clothes, and just about everything, by their price tag. I guess it’s a decent shortcut if you really don’t have a refined taste for wine or clothes. In this case you’re trusting the taste of those who bought the product before you did. But then, buying a sweater that comes apart in two months might be disagreeable, but it’s easily fixed; but how do you fix compromising your medical records, or a patent process, or your fingerprints?

We all got some thinking to do…

One thought to “What to worry about when using encryption”

  1. @Greg. Yes, in order to have full capability the other side must have the encryption app installed, and you must have gotten their Lock (public key) by means of an encrypted message from them. This is why the app defaults to an “Invitation” message, which does not require anything from the recipient, so long as it doesn’t have that piece of data. Once it gets it, the recipient appears on the list and you only need to select those you want.

Leave a Reply to Paco Ruiz Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.