Emerging Email Encryption Extensions

The other day I was curious about what other extensions the Chrome Web Store thought were “related” to my own apps, which led me to discover a number of possible competitors that I knew nothing about. In this article, I am critiquing a number of those competing with PassLok for Email and the just released PassLok Universal.

First of all, let me explain what I mean by “related” and “emerging”. The Chrome store lists as “related” apps and extensions that actually do quite different things, but perhaps use similar keywords in their descriptions. So in this case “related” is going to mean apps that the Chrome store lists under the “Related” tab in its PassLok for Email page, and which actually do encryption and decryption of email messages (file encryption is a plus, but the focus is on text messages). I’ve used the word “emerging” to designate apps that, like PassLok for Email, have amassed a viable number of installs (around 1000) so that one can suspect there is a (small) community using it, which might eventually grow.

Okay, so here’s the list I put together during my one-day research, which took place September 5th, 2019:

• Jumble
• SecureMail for Gmail
• Cipher Mail
• Lock Magic
• CryptoData
• Encipher It
• SendSafely

You may notice substantial omissions. For instance, neither Mailvelope nor FlowCrypt are listed here. This is because they are no longer “emerging” after having surpassed 62k users (FlowCrypt) or even 172k users (Mailvelope). Besides, I have looked at them in separate articles, like this one for Mailvelope, and this one for FlowCrypt.

Here’s a handy table synthesizing some of the data gleaned from the Chrome Store (as of 12/10/19), with PassLok for Email added as a comparison:

A critique of each one follows:

Jumble

Billed as a commercial solution, Jumble appears to use a method similar to PGP: symmetric encryption (they use AES) with a new key for each message, and then the key is RSA-encrypted with the user’s private key. Recipients can fetch public keys from the Jumble server. In order to simplify (and perhaps control?) the process, quote from their website: “Jumble generates a new RSA key-pair for a given email address when it’s not already available from our API but only releases the private section of the key-pair to someone who can prove they own the email address linked with the key-pair.”

Which means they have your private key. Users are authenticated by their email address. We’ll see this later, but I contend that authenticating someone by their email address isn’t enough security. After all, the whole point of encrypting email is that email can be intercepted by a third party, who presumably can then impersonate the sender. Even if they were to go to great lengths to authenticate each new user, the fact that they have access to their private keys is troublesome. Verdict: Buyers beware.

SecureMail

Also commercial, they follow the older method of holding your data in their servers, presumably in a very secure way, and controlling who has access to it. Their website states they use “Military-level AES-256 encryption; in transit and in storage,” which means they have your data, and your keys. Encryption is purely symmetric. Add to this that they are based in Britain, whose dismal record on citizen privacy is documented back more than four centuries, and is currently the worst in the EU (before Brexit), and you start wandering why on earth anyone could be duped to use them. Marketing, I guess? Verdict: Thank goodness it’s not working.

Cipher Mail

It uses industry-standard S/MIME, which involves the exchange of certificates similar to PGP keys (essentially, PGP public keys signed by an official signing authority, as in the TLS protocol underneath https). This recommends it and un-recommends it at the same time because, despite efforts extending many years, the industry has failed to entice private citizens to use S/MIME certificates. Maybe it’s that the process to obtain them is too complex, or it’s the handling of such certificates that is onerous. Besides, just about every email client already supports S/MIME certificates, and people don’t use them. The developer is Red Cool Media, which has many other apps. It is possible that the modest user base of Cipher Mail is a result of the developer’s heart not being fully behind it. There have been no updates for over a year and a half. Otherwise, the interface is slick and it seems to work. Verdict: you can kiss a frog to turn it into a princess, or you can use S/MIME.

Lock Magic

This one has me befuddled. The extension itself is tiny, signaling that there’s hardly any local processing and everything is done by a server. And they insist no password is needed. What? Apparently, both senders and recipients are authenticated by a sort of patented magic. I was curious and read their patent (US8825999B2), from which I gleaned the following: their “Extending Encrypting Web Service,” or EWS for short, symmetrically encrypts the sender’s data, together with a list of recipients (presumably, email addresses), and sends it back to the sender, who sends it to the recipients by regular email. The recipients send the encrypted stuff back to the EWS, which decrypts it and figures out if they’re on the list of authorized recipients, in which case it sends them back the decrypted data.

They make much of the fact that their EWS does not store encrypted data, but it is quite apparent that it is the only holder of the decryption key. It is also apparent that recipients are authenticated merely by their email addresses, so an interloper wouldn’t have difficulty impersonating them and thus obtaining the secret data. In other words: merely apparent security. Verdict: Hocus Pocus.

CryptoData

This is purely symmetric AES encryption with no pretense of user authentication, key exchange, certificates, servers, and the whole shebang. Lovely in its simplicity: just highlight what you want to encrypt or decrypt, right-click on it, and you’ll see the option to do what you want, after you supply the password. This password must be known to the recipient and no one else, and the app won’t help you to get it there, but for what it does, it’s great. Of course, this approach eliminates 90% of the hassle inherent in cybersecurity, but it becomes impossible to use unless you have exchanged that pesky password in advance. Verdict: Chicken and Egg.

Encipher It

Another AES implementation, running locally. This one has been around for years and retains a good user base despite not having been updated in five and a half years. Sender and recipient can skip installing the extension and use instead a web page that does the same. As with CryptoData, it’s up to the users to figure out how to exchange the all-important key. Verdict: Egg and Chicken.

SendSafely

Larger user base, but befuddling. The description prominently states “Built on OpenPGP,” and a bit below it says “With SendSafely, the people you share items with don’t need to download or install on anything on their computer. If they have a web browser, they can receive your files.” Which begs this question: how can you possibly use PGP with a recipient that has done no homework on his/her/its part? PGP is based on using a recipient-generated public key to do the encryption. If the recipient hasn’t done anything, there is no public key to encrypt with. One of the example screenshots has the app saying “Hi Alice, here’s the password to log on to your system,” followed by some random-looking text. This makes me think that it’s the service, rather than the user, who generates (and stores) private keys, which then are given to recipients (if truly PGP is being used) after some sort of authentication. The website says something about SMS authentication, which begs the question of who supplies the phone number, and how do they know it’s legit?

If you go to the “How it works” tab of sendsafely.com, you’ll see that the whole process uses symmetric encryption using “OpenPGP message format,” which is not the same as using the full OpenPGP. The key is composed of a part generated by the sender, and another made by the service, which stores the sender-encrypted data. When the recipient clicks a link sent by email (which contains the sender’s half of the key hidden within the fragment identifier of the link, following a # character so it doesn’t get sent to the server), the server authenticates the recipient (by email, duh, or by SMS) and then gives her the half of the key it holds. And then the recipient, having both halves of the key, can finally decrypt the message, which the server was storing for her. Aside from the fact that storing the encrypted data seems unnecessary, the whole process seems to have as its objective that the recipient must definitely prove to the server that she is the person owning that email address. But if this is done via confirmation email, any interloper could do it just as easily. Additionally, the service is commercial and rather stingy at its “free” level. Verdict: faint smell of snake oil.

I didn’t try them all because the descriptions seemed clear enough, but I did try Lock Magic and SendSafely because I was curious about they managed to maintain security without passwords (Lock Magic), or by sending them automatically (SendSafely). I will refer to both together because my experience ended up being quite similar for both. I installed the extensions on one Chrome account, which acted as the sender. I used another chrome account as recipient, with its own separate email address, as but I did not install the extensions there (at first). Sending followed the expected routine: click the icon, a “secure” window appears, type the secret message, click “send”. Both services required an account to be made (of course), which was fairly straightforward, and then Gmail sent the email to the recipient. SendSafely offered a link to be sent by other means, which makes sense since that’s what the email contains, more or less disguised by graphics.

Fun began when the recipient got the email. SendSafely refused to give the decrypted secret before first authenticating the recipient, which was done by clicking on a confirmation email sent to the same address, and then it opened a separate tab containing the secret. Clicking on the link later just opened the tab with the decrypted secret, since presumably the recipient had been previously authenticated. Lock Magic forced me to make an account, with a password, and to go through hoops authenticating it by the same confirmation email method, with a few failures in-between. Later decryptions happened automatically if the Lock Magic extension was installed.

So how do they compare with PassLok for Email and PassLok Universal? They fall roughly into two categories: PGP and such implementations (Jumble, Cipher Mail), and trusted server holding data and/or keys (SecureMail, Crypto Data, Encipher It, Lock Magic no matter how hard it claims that no password is needed, and SendSafely no matter how hard it claims PGP status). PassLok is closer in concept to the PGP apps because it uses no trusted server (it’s worthwhile repeating this: no server). A server can be hacked or legally forced to betray its users. An app that consists solely of code can also be compromised so its security is only apparent, but this is much harder because it would imply changing the code at all sources (and continuing to do so after each update) via hack or legal strong arm. In the US, the legal integrity of computer code is protected by the 1st Amendment to the Constitution, as the original PGP case proved. No one can be forced to produce and/or publish compromised code, since code is catalogued as “speech” under US law.

Epilogue:

I actually wrote this article three months ago, but it was unpublished until yesterday I discovered I had forgotten to do it. Which prompted me to update the numbers. Most extensions have gone up in users (except Jumble, that has gone down), with Mailvelope and Flowcrypt, which actually didn’t get discussed much, having made the largest gains. Could this mean that users are, finally, warming up to email encryption?