FlowCrypt review

Looking through some chatroom records, I came across FlowCrypt, a Chrome and Firefox extension that adds easy PGP encryption to Gmail. Since it is supposed to do pretty much what my own PassLok does with Gmail, I loaded the extension and took it for a spin. Unlike other products in the same space that are receiving lots of attention (ProtonMail, Virtru, etc.), FlowCrypt impressed me. It’s a shame it isn’t better known. In this article I offer you my clearly biased but perhaps richer than usual review of this extension, and compare it with my own PassLok for Email.

FlowCrypt focuses on making PGP easy to use, and I must say it succeeds spectacularly at this. My hat is off my head, and so should be the hats of researchers such as Whitten and Tygar who have looked into the issue of PGP’s legendary user unfriendliness. So if you are looking for a way to add PGP encryption to your Gmail account, look no further. Don’t even look at PassLok, which does not use PGP, just get FlowCrypt and you’re good to go. Now, if you want to know why I’m saying this, read on.

Let’s say you’ve just added FlowCrypt (formerly known as MuCrypt) to your installation of Chrome. You’ll be immediately presented with a page that asks you whether you want to import an existing PGP key or make a fresh one. I’ve tried both ways, with different Chrome accounts. In one of them I imported a GPG key (GNU Privacy Guard, a variety of PGP) I had stored in my hard drive, which FlowCrypt took without a fuss after I gave it the passphrase that unlocks it which, miraculously, I still remembered. In the other account, I told it to make a fresh key, which took a few seconds after I supplied a passphrase to unlock it. In either case, I was asked for my Gmail address, which is no secret. And then I loaded Gmail.

FlowCrypt’s integration with Gmail is simply beautiful. Encrypted messages are recognized automatically, so they decrypt as soon as you click the headers in order to view them (after supplying the passphrase if FlowCrypt forgot it, more on this later). If you want to reply to them, the Reply button takes you to FlowCrypt’s own compose box, with looks almost like the Gmail original except that Google doesn’t get what you type (at least, in plaintext). If it is not a reply but the start of a new thread, Gmail now has a big button right above the Compose button on the left side, to load FlowCrypt’s secure compose window instead. Google saves what you type in this window as a draft, just as it does with its own compose or reply window, except that the contents are encrypted and therefore they don’t know what you typed. If you stop writing and later decide to continue that message, it remains available in Gmail’s draft list, and it will load back into FlowCrypt’s compose window as if nothing had happened. Even better, if the recipient has installed FlowCrypt, the extension recognizes the fact without your needing to load any public keys or do any key management at all. Let me say it again: just beautiful!

The code can be inspected within Chrome but I haven’t done it because that takes a lot of work, and FlowCrypt’s privacy policy, which should be detailing what gets sent to their and other servers and what they do with it, is not very helpful in this regard, so I’m going to guess what magic is taking place underneath. I originally guessed that drafts were being saved to Gmail servers encrypted with a symmetric key derived from the passphrase and not with an asymmetric key like the final message, but a message from the developer tells me that indeed they are being encrypted with the user’s RSA-based public Key, which happens much faster than the decryption process. I’m also guessing (I think FlowCrypt’s FAQ page says something about this, though) that the reason why other FlowCrypt users are recognized right away is because there is a communication between the extension and FlowCrypt’s own key server, which they call “Attester,” as soon as you open a secure reply or compose window. That server then sends the recipient(s) public keys to the client (possibly more than one, but I haven’t checked this), and the PGP encryption takes place with those public keys. The developer tells me that public keys are stored locally in IDBDatabase, but when a public key isn’t there a request is sent to the FlowCrypt server. Likewise, at first I was guessing that the user’s own private key is sent to that server (likely encrypted) so that it can be loaded into other machines or other browsers, as suggested by this FAQ item. Indeed, I was able to use mine right away as soon as I opened Gmail in a machine different from the one I used to install it first. But then, the developer has told me (see the comments below) that the private key is not sent to their servers, but rather stays local (possibly synced through Chrome).

If the recipient is not a FlowCrypt user, his/her/its name (I ran out of pronouns, sorry!) appears greyed out rather than highlighted in green in the compose window. This means that FlowCrypt cannot send me the public key and therefore the message won’t be PGP-encrypted. Instead, it will be encrypted with a symmetric key that is to be supplied by the sender at the time of encryption, and which is supposed to be sent to the recipient by a different channel. In this case the encrypted message doesn’t go to Gmail, but rather gets sent to FlowCrypt. Gmail gets a message with a link to it, which opens a webpage where the password can be supplied. After clicking the action button, the message opens there. If more than three days have passed, the FlowCrypt server instead displays a page telling you that the message has expired. Their FAQ states that they’ll delete the encrypted message from their server after a few more days.

Did I mention FlowCrypt also handles attachments? They can be loaded on the reply or compose windows just as in the original Gmail, and appear to be sent in exactly the same way as regular attachments, only encrypted (on the other hand, FlowCrypt’s privacy policy gives the impression that attachments are handled through their servers, but they say in their comment below that attachments go through Gmail servers). The recipient sees the encrypted attachments as an image which, when clicked, triggers decryption resulting in a link. Right-click this link and do a “Save as” in order to get the original file. I know how this works since PassLok does pretty much the same. The link actually contains the file encoded in base64.

So far it’s been a lot of positives. Let me summarize them as a bulleted list:

• FlowCrypt integrates beautifully with Gmail; it looks and feels like a native part of Gmail.
• Key management is absolutely painless, both for private and public keys. This is perhaps its biggest selling point, which makes me recommend it for the majority of users above all other PGP encryption apps out there. I don’t bestow this kind of recommendation lightly.
• It does attachments beautifully as well.
• It does drafts just like native Gmail, but Google never gets the plaintext (or so I’m told).
• It can send encrypted messages to users who don’t use PGP, although this involves the exchange of a symmetric key through a separate channel.

But unfortunately there are a few flaws. Some of them left me scratching my head at the odd choices, which could have been done right with little effort. I’ll start with the highly insecure choice that the developer has made to store the user’s passphrase pretty much indefinitely by default. Yes folks, unless you specifically uncheck a box when you are creating or loading a key pair, entering your passphrase once causes FlowCrypt to remember it so long as Chrome remains in memory. Closing Chrome is not enough: unless you make absolutely sure that your browser has unloaded from memory before you leave to get a cup of coffee, anyone walking by your computer can decrypt all your encrypted messages and files as if he/she/etc were you. This could have been avoided by having the extension forget the passphrase after some period of inactivity, as all other encryption apps and password managers do, and as PassLok has done since the beginning. This feature is very easy to program, and so its omission is quite puzzling. If this was intended to make FlowCrypt even more user-friendly, it has gone too far.

I mentioned that FlowCrypt’s compose box is a lot like Gmail’s original, but not quite. For instance, there is no rich formatting whatsoever, as in italics, boldface, etc. You can’t add images to the message, only as attachments. This is also relatively easy to program, and PassLok has had it almost since the beginning. ProtonMail and other PGP-encrypted email apps have it too (the developer, in their comment below, promises this will be added soon). Likewise, there’s no way for your encrypted email messages to have an unencrypted part, which can come in handy sometimes. This is because the “Encrypt” button sends the message without giving you a chance to edit it or add anything before this happens.

You have the option to attach your public key to your encrypted messages. Perhaps this is done in case the recipient uses a different PGP app, where key management isn’t automatic. Still, this seems redundant given that FlowCrypt’s key server is always ready to supply it.

Have I mentioned that, since FlowCrypt remembers your passphrase essentially forever, anyone can also get your private key out of the app while you’re having that cup of coffee? Then they can impersonate you any time they want, and decrypt all messages sent to you, past, present and future. Egad!

And then, only Gmail is supported. This is likely a consequence of the deep integration with Gmail, which would be hard to achieve with other email services. Indeed, FlowCrypt seems to use Gmail APIs for sending and receiving messages straight from and into the DOM elements under its control, and to send and retrieve attachments, rather than rely on Gmail’s native functions. But then one may ask, why encrypt at all if the messages are going to be handled internally within Gmail, and they are never going to leave their servers? Google, we are told, encrypts all the traffic between its own servers, and therefore messages between Gmail users are never exposed to third parties as they travel from one server to another. The benefit of FlowCrypt, then, is reduced to preventing Google, and those Google might allow, from seeing the contents of the messages.

FlowCrypt does have a method for encrypting messages that go out to users for whom it does not have a public key, which I described earlier. I find it rather clunky, however. For one thing, the encrypted messages are handled through the FlowCrypt server rather than through Gmail, which is odd since Google can’t decrypt them anyway. When I first wrote this, I guessed that this was being done so that they can be given an expiration date, after which the FlowCrypt server refuses to deliver the message, but the developer tells me this is actually all the way around and they are using their own servers only because the Gmail servers don’t handle relatively large symmetrically-encrypted material gracefully. They tell me they do this quite reluctantly, and they wish their servers wouldn’t have to handle any data. I think that eventually this will allow them to monetize FlowCrypt, which is something they may or may not have thought about yet. This is what Virtru does for everything, and people don’t seem to mind it despite the forced trust entailed and the obvious danger to security. We’ll see what develops.

Speaking of monetization, FlowCrypt’s pricing page mentions a few premium features that you get with a paid subscription, but none of them entice me to open my wallet. They all seem to give greater access to the FlowCrypt server, but in my opinion server interaction should be minimized as a matter of principle. Having an app of this type myself (which by the way is 100% free), I understand that the business model for this kind of app is very hard to figure out. The moment you have a server you incur expenses that have to be paid, which requires income. I wish them well with their current subscription model, though.

And now, a feature whose inclusion I can’t figure out. FlowCrypt allows you to sign, rather than encrypt, a message. This is one of the functions of PGP as well as of all the other asymmetric encryption primitives. When the sender signs a message, it appears to be encrypted but in reality it is not. Anyone in the world can retrieve the contents of a signed message. What’s special about a signed message is that recipients can be sure that it came from that particular sender, because they have his/her public key to verify that his/her private key, which no one else has access to, was the one used to apply the signature. But email messages are not posted on a general board but rather come from a source that the email program verifies in principle. Therefore, message signatures seem to me rather redundant and unlikely to be used. There’s also the danger of confusing users so they’ll end up signing a message, which provides zero security, instead of encrypting it.

Sure, the Gmail server can be hacked, but so can the FlowCrypt server, which users are being asked to trust blindly, for instance, in serving public keys automatically. Users are implicitly trusting that the keys send by the FlowCrypt server belong to the users whose email addresses they typed. When I enrolled a couple users and either loaded a key pair or generated a new one, I was never asked to prove that I was indeed who I said I was. The FlowCrypt server took those keys and associated them with the Gmail addresses I gave it without asking further questions. Not even a confirmation email to be replied to before the keys were finally accepted, mind you. Anyone could have pretended to be me and loaded keys under their own control; then they’d be able to read all the encrypted materials sent to me. This serious security flaw is shared by all PGP key servers, not just FlowCrypt’s, probably because PGP has a separate system for key authentication, called “web of trust,” which really hasn’t worked too well since it was proposed many years ago.

After I wrote this, the developer sent a comment (posted below) stating that email-based verification is needed in order to change the public key associated with a certain email address. The fact remains, however, that in my tests the first posting of a public key did not require such confirmation. Hopefully this is a bug that can be fixed easily.

So here’s a summary of FlowCrypt’s negatives, to match the positives:

• The passphrase that unlocks everything is remembered forever by default. This is a major security flaw.
• Unless you are very careful, people walking by your computer can also get your private key, which throws out the window all security past, present, and future.
• You may be forced to create new keys from time to time, with all the hassle that this entails (see the end of this post).
• No rich formatting or images in encrypted messages.
• Forced trust of FlowCrypt server for public keys and attachments (also private keys, I suspect).
• First posting of public keys in their server does not require email confirmation, although any changes afterwards apparently do.
• Only Gmail is supported.
• Redundant/useless features such as adding public key and signatures.
• Paid features don’t seem worth the money.
• Based on PGP.

Now that I started dissing PGP, I can’t stop myself. Yes, folks, PGP (or GPG) may be standard, but it has a lot of problems of its own. Read, for instance, this short article by Moxie Marlinspike, the developer of Signal, on which the encryption layer of WhatsApp is based. Some time ago I wrote an article about PGP’s problems, and why we need to move beyond it in order for mere mortals to be able to use encrypted communications. This is why my app competing with FlowCrypt, PassLok for Email, does not use PGP. Never has, never will. And thanks to this it is able to do a number of things that PGP-based programs just cannot begin to think about doing. For instance:

• The sender’s public key is always attached to every outgoing message. Thus, recipients get it easily and keep their own local key database, whose maintenance is transparent and automatic. No need for a key server or special trusts. PGP-based programs can’t do this because PGP public keys are simply huge.
• It has a forward-secret Read-once mode where messages truly can be decrypted only once (forward secrecy). This does not depend on timers or third parties deciding they don’t want to cooperate anymore. PGP was defined many years before forward secrecy was an issue, and therefore has no provision for it.
• There is no need to store your private key, which is a bit of a chore even if encrypted. PassLok’s private keys are synthesized on the fly when required, based on the user’s master Password, and destroyed after five minutes of inactivity, leaving no traces that might be exploited. Because PGP was originally based on the RSA key-generation algorithm, key pairs cannot be user-chosen but rather produced by a random search and then stored so they can be used again.

PassLok has more features that are rather uncommon among email encryption programs, such as several kinds of text and image steganography, which comes in handy when the mere presence of encryption can get users in trouble. It has a real-time chat option using the WebRTC protocol. If you are willing to give up email integration and do some minimal cut and paste, PassLok Privacy includes a bevy of symmetric encryption methods, including the absolutely uncrackable Pad mode, and Human mode, which can be used even without a computer.

FlowCrypt’s “heavy” integration with Gmail is certainly smoother than PassLok’s “light” integration with Gmail, Yahoo, and Outlook, but this sparseness of communication with the email services is what allows PassLok to cover more services. It also makes it more secure. The prize to pay for this extra security is simply one extra click when encrypting or decrypting a message. When encryption is not needed, the PassLok interface is reduced to a small icon that users don’t even notice.

But I do agree that FlowCrypt will be enough for many users. It is easy to use, and its security flaws are easy to correct as well. I hope the developer reads this.

Update: I let the article sit for about three weeks while I tended to other urgent matters, and I found that when I re-enabled FlowCrypt (which I had disabled in Chrome settings) in order to get some screen shots, my private key had been forgotten altogether, along with its matching public key. I had not deleted cookies or settings, and all my other extensions were working normally. While this is tolerable for a key pair that was backed up outside of FlowCrypt (mine was), this issue would cause users to have to come up with a new key pair, re-load it to the key server, and possibly have to inform correspondents of the change. For a user who has built up a number of encrypted-mail correspondents, this is not acceptable. Another thing for the developer to work on.