Modified interlock protocol for authentication

Of the many difficult problems dealing with public key cryptography, there are few so hard to crack as public key authentication. Public keys are easy to obtain (that’s why they are “public”), and because of this, it is hard to be sure that a certain key belongs to a certain person, what is known as authentication. Usually it is recommended that the key be handed out in person or that it be identified (directly or through a one-way hash) by a rich communication medium such as voice or video.

But sometimes it might be possible to do it strictly by email, even though you suspect someone might be watching. Read on for details.

If you cannot make contact with the other person through a rich channel such as voice or video, you’re going to have to start using somebody’s public key without knowing for sure if that public key is genuine. Trust will build up gradually, as the messages sent back and forth serve to confirm the identity of the participants. But there are ways to discover if a public key is fake with only a few messages traveling back and forth.

The easiest thing to do is to send a message to the public key owner, including a question whose answer only the two of you know, and asking him/her to send you his/her public key, encrypted with a symmetric key that is the answer to that question. If the answer is correct, you’ll be able to decrypt the message, and thus retrieve the genuine public key (which should match the one you have). An interloper who is watching and perhaps modifying your traffic won’t be able to decrypt the message in order to change it, and thus he/she must be content with preventing you from getting that message, in which case you’ll know the public key in your possession have is fake.

But the easy way has the problem that the other person’s answer must be exactly the answer I know, down to the smallest spelling detail, or the message won’t decrypt. There is another way to authenticate a public key using a variation on the “interlock protocol,” which admits answers that don’t have to be exact. It is enough if the persons asking the questions can recognize the answers as valid in a more general sense.

This protocol is based on the “interlock protocol,” first described by Rivest and Shamir in this paper. In essence, people encrypt messages but only send half, and wait to get the other person’s first half of a reply before sending out the second half. This causes a “man in the middle” a big headache because, since he cannot decrypt half an encrypted message, he needs to make up messages to keep the exchange going, or his cover is blown. Unfortunately, it has been shown that this protocol can be defeated by a particularly clever interloper, using this method. Does that mean that the interlock protocol is no good? Far from it. What’s needed is extra cleverness in the way it is set up. As a clever user says in this posting, the key lies in asking questions that require an answer.

So here ‘s the way you can set up a slightly modified interlock protocol in order to authenticate a public key. Since the following is extracted from the manual for PassLok, which uses non-standard nomenclature for the sake of novice users, let’s get that out of the way first. In PassLok, a public key is called a Lock, and a private key a Key. A digital signature is a Stamp, and a one-way hash is an ID. Encrypting is referred to as “locking” and decrypting as “unlocking”.

With that clarified, let’s look at this exchange between Alice and Bob:

1.     Alice obtains her friend Bob’s Lock, but she fears that it might be counterfeit and someone else might be unlocking the messages she sends to Bob, reading them, perhaps changing them, and then re-locking them with Bob’s actual Lock for him to read. So Alice sends Bob this email:

“Dear Bob. I just got your Lock for the app called PassLok from your email signature. I fear that I’m under surveillance, so it’s very important that I make sure that this Lock actually belongs to you. Here’s what I want you to do:

a.      Write a question whose answer only the two of us know, and lock it with my Lock, which is included at the bottom of this email. Then split it in two parts and send me the first part. I’ll be waiting for it.

b.     When I get it, I’ll send you the first half of a similar question, which has been locked with your Lock. When you get it, send me the second half of your locked question.

c.      When I get that, I’ll send you the second half of my question, and also the answer to yours, which then I’ll be able to read. I’ll send the answer locked with your Lock.

d.     If I answered your question correctly, put together the two halves of my question and unlock it. Then write the answer, lock it with my Lock, and send it back to me. Then I’ll know that your Lock is authentic. Your friend, Alice.”

2.     When Bob gets this, he decides it’s going to be fun to do all his, and writes a question whose answer only Alice knows, locks it with her Lock, which was appended to her email, splits the locked message into two parts, and sends Alice the first half.

3.     Alice gets the first half, and writes her question to Bob. Then she locks it with Bob’s presumed Lock, but only sends him the first half. Because nobody can unlock half a message, she must wait to get the second half of Bob’s message in order to answer his question.

4.     Bob gets the first half of Alice’s locked question, and he sends her the second half of his locked question.

5.     Alice gets the second half of Bob’s question. Now she can put the two halves together and unlock them with her Key. She writes a message answering Bob’s question, locks it with Bob’s presumed Lock (no need to split it now), and sends it back to him along with the second half of her question to Bob.

6.     Bob gets Alice’s email and can now unlock both messages from her. He sees the correct answer to his question in the first one, so he unlocks the one containing Alice’s question. He writes the answer, locks it with Alice’s Lock, and sends it to her. Had he been unable to unlock Alice’s question, he would have told her so. If her answer to his question was wrong, he would have told her, too.

7.     Alice gets Bob’s message, unlocks it and, seeing the correct answer to her question, is satisfied that Bob’s Lock is authentic. Otherwise she gets a message from Bob telling her that things didn’t work out, or something other than a message answering her question, or nothing at all, and she decides that “Bob’s Lock” was bad.

An alternative to splitting locked messages is to make the ID of the locked or unlocked message and send it ahead of the message itself, or apply a Stamp to the message and send the Stamp ahead of the message. The recipient will then check the ID or Stamp after the message is received, and will know that something’s wrong if it is not the same. Another option is not to lock the answers to the questions, in steps 5 and 6, since authentication also works if those messages are not locked; locking just preserves those answers, which might be sensitive, from a less-than-powerful eavesdropper who might see the exchange.

If Alice does not know Bob well enough to be able to ask him a question whose answer is known only to the two of them, or maybe Bob doesn’t know Alice well enough to ask a similar question, there is still something they can do, so long as Alice can recognize Bob in some way, and Bob can recognize Alice. Instead of a personal question, the asker can direct the other person to simply repeat something contained in the “question” message, but to do so in a video or audio recording, which is then put somewhere in the cloud, and the URL is sent back as an answer. The asker will then see or hear the other person, whom he/she recognizes, saying something that she/he would not be saying unless she/he has read the question message.

Let’s see how this protocol foils Mallory, who is able to intercept and modify their communications without them knowing anything. He poses as Alice before Bob, and as Bob before Alice. In this case, Alice does not have Bob’s genuine Lock, but one that Mallory made in order to impersonate Bob. Likewise, Bob does not get the Lock that Alice sent in step 1, but one for which Mallory has the Key.

Things begin to go wrong for Mallory in step 3. Since Mallory cannot yet read Alice’s question but nevertheless has to send something to Bob to keep the exchange going, he must send him a question from “Alice” that likely has nothing to do with the question the real Alice has asked. That, or pretend in step 2 that Bob is refusing to go along with the game, which is not going to do much to reassure Alice.

Mallory will then get the whole question from Bob, so he will be able to unlock it, re-lock it, and pass it along to Alice in step 4, and then get from her a reply that will satisfy Bob in step 6. But the damage has been done. Mallory is committed to sending Bob the second half of a question from “Alice” that is most likely not the question the real Alice asked, or otherwise Bob won’t be able to unlock the message, and Mallory’s cover will be blown. Bob might not discover the ruse at this point, but it is highly unlikely that his answer, or whatever else Mallory can come up with to replace it, will satisfy the real Alice’s question. Then she’ll know someone’s in-between and Bob’s Lock is not authentic.

If now they repeat steps 2 to 6 all over with one new question from either side, but this time with Alice asking the first question, Bob will also notice that something is wrong. But what if there is no Mallory, and “Bob’s Lock” was not being used to listen in but was simply corrupted or mistaken for another Bob’s Lock? Then Bob will simply be unable to unlock Alice’s question in step 6, and he will alert her of that fact. It is possible that a Mallory could still be watching without attempting to modify the messages passing through him unless he really has to, but it is unlikely that he could replace Bob’s announcement that the protocol failed with something that would satisfy Alice, because at that stage Alice won’t accept anything but a correct answer to her question, or she will decide that “Bob’s Lock” is bad.

It took some homework and three emails from each side, after which they still don’t know each other’s authentic Lock (which would be impossible with Mallory changing everything, anyway), but Alice has avoided being duped by an enemy.

Lessons from the VIC cipher

abelIn the mid-1950’s, the Soviet spy Reino Hayhanen, codenamed VIC, and his handler Rudolph Abel (in the picture) pulled off an incredible feat: they utilized a paper-and-pencil cipher that not even the FBI (the NSA wasn’t operating within US borders back then) was able to crack until Hayhanen defected and explained its inner workings. Computers already existed, and they were used primarily to crack ciphers like VIC. In this article, I go over some of its features, and how they can be used to enhance other simple ciphers. Read More

Remember strong passwords with this keyboard trick

keyboardEveryone knows that real people suck at coming up with strong passwords. They are either easy to remember and laughably weak, or decently strong and impossible
to recall. On top of that, it is highly recommended to use different passwords for different sites, so that compromising one won’t compromise the others. In this article, I follow Nobel laureate Manuel Blum’s recommendation of using not a password, but an easy to remember algorithm to come up with a way to generate strong, specific passwords for each site, and be able to remember them all.

In this talk, Manuel Blum asks four volunteers from the audience, who we presume not to have been prepared before the lecture, and explains to them a method which, when given a name to apply it to, leads them all to the same, apparently random result. The video does not reveal the method used, but some articles by Blum speak about mapping the alphabet (plus numbers) into a secret scrambled grid, and applying a secret walk to the successive letters of the name (presumably a website name) to be converted into something else. Thus, the user only needs to memorize the scrambled alphabet and the steps taken in the walk.

I don’t think I could do that, though, so here’s my counter-proposal: use the computer keyboard as my grid, and just memorize the method, plus maybe a simple code that I can change from time to time. Let’s say I want to come up with a strong password for amazon.com. I start, therefore, from the word “amazon”, which I am going to turn into something else. In order to increase security, I memorize the secret code “1234” (maybe I can’t memorize a scrambled alphabet, but this I can memorize). Now I do the following on an American qwerty keyboard like this:

keyboard

  1. Starting with the first letter in the original word, move down (and slightly to the right) on the keyboard as many keys as the first digit of the code. If this causes me to fall off the lower edge, I continue on the top row, on the key directly above the last one I touched. Since the first letter is “a” and the first digit is “1”, I move one key down from “a”, which is “z”.
  2. Repeat with the second letter of the name and the second digit, then do the same until all the letters have been transformed. If I run out of numbers, I take the first number again, and so on. Therefore the other letters are:
    1. “m” + 2 = “i” (wrap to “8” on the first step, and then down to “i”)
    2. “a” + 3 = “w” (wrap from “z” to “2” on the second step, and then down to “w”)
    3. “z” + 4 = “x” (wrap from “z” to “2” on the first step, and then down to “x”)
    4. “o” + 1 = “l” (observe that we go back to “1”, since we ran out of digits on the key)
    5. “n” + 2 = “u” (wrap from “n” to “7” on the first step, and then down to “u”)

Final result: “ziwxlu”, which likely does not appear in any dictionary and is therefore as hard to crack as a group of random letters. If the website demands that you add numbers, go ahead and add a few that you can easily remember (except “1234”, which would compromise the key). This time I will add “1111”, making the final password  “ziwxlu1111”. Never mind that the numerical part is weak; the strength is in the first part, which is one out of 366 = 2,176,782,336 possibilities (numbers are also part of the set).

What we have done is essentially to apply the Vigenère encryption algorithm to the word “amazon”, using “1234” as key and the qwerty keyboard read column by column as starting alphabet. Not secure by today’s standards, but again, we are using it to generate a password, which itself has a small probability of being revealed. Additionally, anyone having access to the password will still have to figure out the algorithm, since what I’ve presented above is just a sample. There are many other ways you can apply a key to a website name. For instance:

  • Do as above but instead moving up, or left, or right on the keyboard. Or maybe alternating directions, or even switching directions in a more complex pattern that is still easy to remember: a cross, a circle, etc.
  • Use an alphanumerical key, and then find the result key by doing a “Playfair” combination. In the classic Playfair cipher, two letters at a time combine into one, this way: if there are in the same row or column, take the letter following the first, right or down respectively, depending on whether they are on the same row (or is the same letter) or column. If they are on different row and column, trace a rectangle with the two letters as opposite corners, and then choose the upper new corner (or lower, or right, or left) as result. For instance: “”q” + “t” = “w” (same row), “r” + “v” = “f” (same column), “i” + “c” = “e” (neither). This method also can be subject to direction changes, if so desired.
  • Use no key at all, and just rely on direction changes to get the result. For instance, Blum used a one-step north-east-south-west repeating walk, which would turn “amazon” into “q,z/9m” on the qwerty keyboard, excluding non-character keys and the space bar.

There are several reasons why this method, even when not using a key at all, is easier and more secure than others.

  1. It is certainly easier than having to remember Blum’s secret square containing a scrambled alphabet. The keyboard is there, so why not use it? Otherwise, I might feel tempted to write down the square on a piece of paper because it is hard to do the translations all in the head. It is still hard to extract the key from a compromised password, since the details of the algorithm are unknown and the text sample very short.
  2. It is more secure than memorizing a single high-security password because, if that is compromised, then all logins are compromised. The result of the algorithm is very random-looking, which makes it hard to crack using a dictionary. Cracking by trying to guess the algorithm is hopeless, since you can use so many different possibilities for that too.
  3. Even if one password is compromised, that does not necessarily reveal the master key (“1234” in the above example) because the attacker does not know the exact series of steps in your algorithm. If he does, of course, he’ll get your key in no time at all, so don’t reveal your method. This is probably why Blum did not reveal his in the video.

Is self-destruct email possible?

Earlier this week, my new app SeeOnce was rejected (hopefully only temporarily) by the iOS app store for allegedly misleading users into thinking that it could make self-destructing messages. Leaving aside what exactly “self-destruct” means for a digital message and whether or not SeeOnce actually achieves this, a number of current and past apps have claimed precisely this. In this article, companion to the one on Privnote vs. SeeOnce, I go over these apps, how they work, and how they can be used most profitably. Read More

Privnote vs. SeeOnce

In this post, I review Privnote and compare it withSeeOnce. Both apps claim to generate self-destructing messages. Which one will be the winner?

Ladies and gentlemen, on this corner is Privnote, a really, really simple app to send self-destructing messages to someone. It works like this:

  1. Navigate to https://privnote.com. The interface contains a single box where you write your message and a big red button to create the note. Nobody asks you for any password or private info of any kind. There is an additional button for some options, such as encrypting it with a password (using AES), changing the default time for self-destruction, or getting an emailed confirmation that the note has been read and destroyed.
  2. Write the note and click the big red button. The box is replaced by a link like this: https://privnote.com/cv0Lcrsw#IgdQIQnTL already selected for you to copy.
  3. Copy the link and paste it into an email or whatever.
  4. When the recipient clicks on the link, Privnote loads on a secure page and displays the original message, plus assurances that the message has been destroyed at the source. Sure enough, reloading the page displays a warning that the message no longer exists.

Privnote is beautifully simple and it seems to work. Can anyone beat it?

On this other corner is SeeOnce, which also claims to generate self-destructing messages in a pretty simple matter. SeeOnce works like this:

  1. Navigate to https://seeonce.net. You are immediately asked to come up with a Password, though you are assured that you are not making an account anywhere. After supplying this, the interface contains a single box with way more buttons than Privnote, though many of them are things like “Select”, “Clear”, “Help”, etc. (Privnote doesn’t have any help, perhaps because it doesn’t need any?). There are no options to set in SeeOnce.
  2.  Write the note and click the highlighted Lock button. Now another dialog pops up, asking you to identify the recipient on a list, or send it as an (insecure) invitation to a still unknown user. This dialog doesn’t appear if you loaded SeeOnce from a link sent by someone else.
  3. After you do this, a piece of text containing a longish random-looking link fills the box. The link may be something like this: https://SeeOnce.net#@/gq1wS2sus6zUegwYZQ7+AMOLEAqBnAyPTd1Fff1lxI1MIURDA6igSnUiHI8pByPtcUX3lfSUS/GqTovQa46NoSu3tFddibJKieDgFI7XyWFw= and it is already selected as in Privnote.
  4. You can copy and paste the contents (the link alone is enough) into email or texting, or simply click the Email button, which will put the whole thing into your default email. Alternatively, you can click a Hide button, which will convert the stuff into apparently normal text taken from a cover text (a popup asks you for the cover text, if you haven’t loaded one yet), before emailing it.
  5. When the recipient clicks on the link, SeeOnce loads on a secure page and asks for a Password. After supplying this, the original message is revealed. Reloading the link and re-typing the Password leads to a message stating that “unlocking has failed” (SeeOnce needs to exchange two messages between the same parties before this happens right away, otherwise the link does not fail immediately but rather after writing a reply).

A little more complicated than Privnote, but still quite manageable. Now, the devil is in the details, as they say. We need to look at what’s inside as well as the features and the overall simplicity of the process. Price is not much of an issue since both apps are free, but availability on different platforms might be.

Price. winner: SeeOnce

Both apps are free, but Privnote has ads. This is not only uncool, but poses a security risk since the ads could potentially inject malicious code into the page, compromising everything. SeeOnce, on the contrary, stays true to the open source ethos and contains no ads. SeeOnce can do this because it doesn’t rely on servers for its operation and therefore expenses are insignificant.

Simplicity. winner: Privnote

It’s hard to be simpler than Privnote: you click a link, enter a message, copy a link; on the receiving side, just click a link and you’re done. SeeOnce is almost there, but it does ask you to come up with a Password, which is extra work and requires the user to exercise his/her memory, never a good thing (we’ll see later that this isn’t as bad as it looks). On the other hand, emailing can be done without cut and paste by just clicking an Email button. Still, Privnote wins this one.

Features. winner: SeeOnce

Privnote does have a few extra settings, such as the ability to encrypt the message with a chosen password rather than the default 54-bit key (but then, how do you send the password to the recipient in a secure manner?), whereas SeeOnce encryption is always under user control (and this is why it asks you for a Password before it does anything). Privnote also has the ability to send a read receipt, which SeeOnce lacks (we see why below). Still, SeeOnce wins this one because it has a comprehensive Help system (to its credit, Privnote hardly needs one) and the ability to hide its output as innocent text, which can be life-saving in places where encryption is frowned upon. SeeOnce also has the ability to switch to secure real-time chat if the correspondents find themselves emailing one another every few minutes.

Availability. winner: tie

Both apps are available from secure links on a regular browser, though SeeOnce can run offline and Privnote cannot. SeeOnce is also available as a Chrome extension and in the Android store. So SeeOnce has an edge here, but I’m going to call it a tie since sending emails requires Internet and most likely a browser.

Security. winner: SeeOnce

Ah, here’s the biggie. Both apps stem from radically different approaches to achieve the same goal. Privnote is fundamentally server-based (except its encryption option, which appears to be client-based), whereas SeeOnce is strictly client-based (after the web server delivers the code, that is). Let’s see what’s underneath each one:

  • In Privnote, the message (encrypted with a symmetric key, which is sent in plaintext with the link but the server does not see) is sent to a server, where it is stored. Clicking on the sender-generated link first instructs the server to send the encrypted message the recipient’s machine, where it is decrypted with the key contained in the link. The Privnote server will deliver the data if this is the first time this particular link has been clicked by anyone, and the other optional conditions, such as expiration date, have been met. Then the server deletes the stored data, or so we are told, so that a repeated request using the same link cannot be met. Still, Privnote can tell the difference between an expired link and one that was never issued, which leads me to think that some memory of having stored the message remains for a while.
  • In SeeOnce, the message is locally encrypted with the result of combining a public key, which was received in a previous message from the same correspondent, and a random private key that is stored locally and is overwritten when a new message for this correspondent is encrypted. The underlying protocol is fairly complex but transparent to the user. SeeOnce never communicates with servers, so the reason why a message “self-destructs” (actually, no longer can be decrypted) is that at least one of the keys has been overwritten and cannot be obtained anywhere else, even if someone has been copying every message exchanged. This is also why SeeOnce cannot produce a read receipt: it was a different program that actually sent the message; the SeeOnce server never knew about the sender or any of his/her data.

There are three reasons why the approach followed by SeeOnce is much more secure:

  1. The first one is that Privnote displays the decrypting key in plaintext (or an equivalent, given that the client-side code can be viewed at any time) as part of the link. It needs to do this because it does not ask for any information about the recipient before preparing the link, so anyone should be able to follow the link. If the link is sent by email, for instance (and remember we are encrypting the message because we believe email to be insecure), the link can be nabbed by someone else, who then can read the message, instead of the intended recipient. Getting some control over who can actually read the message would require some sort of recipient authentication, a password at the minimum, which is what SeeOnce does.
  2. Whenever data is stored in a server, the user loses control over it. Privnote can say they have destroyed the message until they are blue in the face, but they cannot prove it. If a government agency serves them a request to make a copy, they might be doing it without the users’ knowledge. A hacker can break in and look at the data. The server itself may be saving the data as part of a scheduled backup. Now, Privnote states that this data is encrypted with a key that is not sent to the server, but since that key is included at the end of the link sent by email (otherwise the recipient would never be able to decrypt the message), if the link is compromised as we saw above, then the agency or hacker can decrypt the message. The only protection against complete loss of security is user-controlled symmetric local encryption with a separate key, which Privnote offers as an option, but then the user has the problem of transmitting the key. SeeOnce stores data only locally, and so this is much less of a problem. Stored data is encrypted by the user Password (is it beginning to look like this wasn’t such a hassle after all?) and can optionally be wiped or moved to a different machine. Anything transmitted is encrypted with a public-key algorithm, so that key transmission is never an issue.
  3. Code executing on a server is invisible to the user. Therefore, a Privnote user has no way of making sure that the code is honest and free from errors. In Privnote, this means the code that supposedly is keeping track of how many times a particular link has been followed, and which deletes the data on the server. On the other hand, the complete SeeOnce code is visible to the user by just typing ctrl-U on the browser. It is long and complex, to be sure, but it hides nothing. The program itself has a mechanism to ensure that the code has not been tampered with by a third party, fully documented in the Help pages.

Both programs have features to recommend them but in the end it comes down to a personal choice: do you value ease of use above anything else, or is it security what you value the most in a security product? Perhaps the only way to tell is to take both for a spin and decide for yourself.

The case for symmetric encryption

In this day and age, everything dealing with encryption seems to be of the more complex asymmetric kind: PGP, SSL, TLS, BlockChain, you name it. So, is the old-fashioned symmetric encryption, where the same key is used to encrypt and decrypt, obsolete and done with? “By no means!” say a number of users. In this article, I begin quoting an email I got recently, adding some of my own musings, and making an announcement after that.

This is what a faithful user sent me. He did not want his name to be published but was okay with my quoting what he said:

The case for symmetric encryption:

There are circumstances when symmetrical encryption, that is where both sender and recipient use the same secret key to encrypt and decrypt messages, is the most practical and safest method for encrypting email.

Whenever a message sender, who is known by cryptographic custom as Alice, wishes to write an end-to-end encrypted email to a recipient, customarily known as Bob, one of two cryptographic systems can be used.

The simpler is symmetric encryption in which Alice and Bob have a single secret key, which is used by both of them to encrypt and decrypt messages. The obvious shortcoming of symmetrical encryption is that before Alice and Bob can email, they need to meet up – or have some other safe channel – through which to communicate the secret key. Asymmetrical encryption solves that problem. Both Alice and Bob have two mathematically related keys, one private one public. For Alice to send Bob an encrypted message she ascertains his public key and encrypts her message using it. The message can only be decrypted using Bob’s private key, which he keeps secret and safe.

It would seem, then, that asymmetrical encryption, involving no prior secret exchange of keys, enjoys a clear advantage, and for many purposes it does. But there are a number of things that can go wrong with asymmetrical encryption, which can’t happen with symmetrical encryption – or at least when the secret symmetric key is agreed face-to-face. Let us look at these:

1. Alice is sending Bob a message encrypted with Bob’s public key. However she needs to authenticate it; i.e. prove the message is from her. Precisely because Bob’s public key is public anybody could encrypt a message using it and then impersonate Alice. To prevent that, Alice “signs” the message using her own private key. To read the message Bob uses his private key; and to verify the authenticity of the message he needs Alice’s public key. The difficulty is solved, but only at the expense of complexity. With symmetric encryption signing and verification are not necessary because the ability to encrypt and decrypt using the single secret key is proof of authenticity.

2. Before Alice can email Bob she needs to find Bob’s public key, which may be on his website or in some other public place. But how can Alice be sure that the website or key server has not been tampered with, and that she is not encrypting the message with a key that can be read by somebody else? Equally, when Bob needs to find Alice’s public key from a public place to verify the message, how can he know it is genuine? If Alice and Bob had agreed a symmetric key face-to-face the issue of tampering and impersonation would not arise.

3. It could happen that Alice or Bob believe that their private key is no longer secret and safe. If someone else had acquired it all his or her incoming mail could be read, but revoking the key from a public place is not easy. To be successful, everyone who has or might use it needs to know of the revocation and of the replacement. With symmetric encryption, compromising one key only affects the two parties involved; they can then easily set up a new key – and maintain different levels of security for each key used with different people. Alice’s communication with Bob can be kept more securely than her communication with Bill, for instance.

Asymmetric encryption therefore brings with it a number of difficulties not suffered by symmetric encryption. The sole disadvantage of symmetric encryption is that Alice 2 and Bob need to agree a secret key face-to-face or through some other safe channel. But in many cases that it is no difficulty at all. It may well be that Alice and Bob meet in person as well as send emails. Alice and Bob could be lovers, or they could be members of a political action group which is under surveillance by security agencies. There is no safer form of email encryption than for Alice and Bob to meet, agree a twenty-character long password consisting of random numbers and letters, and for both of them to keep it secret and safe and to use it to encrypt and decrypt their text emails.

This is what he said, and this is what I’d like to add:

I have been focused on asymmetric encryption for a while because symmetric encryption has the seemingly insurmountable obstacle of key distribution. Namely, that there is no good secure way to get a new key to those who should use it other than meeting face to face. But if meeting is possible, then it is hard to beat symmetric encryption, especially if the agreed-on key is a random string that is deleted from its storage location when a new key replaces it. In this case, old encrypted messages become undecryptable, and they possess the very valuable property of forward secrecy.

PassLok does retain the ability to use symmetric encryption by providing a shared Key, instead of a Lock, whenever the program does an encryption. If the shared Key is not stored in the directory (it can be stored, just like a Lock), then it takes a click of the Edit button to reveal the box where that shared Key should be placed, and another click to get back to the Main screen. But the author of the above piece, and I presume many others, still consider this too confusing when faced with so many other options and buttons to be pressed.

Therefore, I have updated URSA so it does only symmetric encryption, bringing it to version 4.0. You can find it at https://passlok.com/ursa.  Its interface is similar to that of PassLok, replacing the directory box with a shared Key input box. Help is similar to that in PassLok and SeeOnce, but called from a button rather than occupying its own tab. There are no Options to choose. Because it is based on the NaCl engine like PassLok 2.2 (unlike URSA 3.3, which is based on the SJCL engine), URSA 4.0 is not compatible with version 3.3, but it is compatible with PassLok 2.2 so that messages locked with URSA 4.0 can be unlocked in PassLok, and (short mode) messages locked with PassLok can be unlocked in URSA 4.0.

My hope is that URSA can serve as an introduction to practical encryption for many people. After they feel comfortable with shared Keys and the basics of encryption and decryption (“locking” and “unlocking” in URSA and PassLok), then they can move to the fuller experience that is PassLok. If they still feel overwhelmed, they can try SeeOnce for a while, which will introduce them to asymmetric encryption in a relatively simple way, and then try PassLok.

So, check out the new URSA at https://passlok.com/ursa. Perhaps this is all you’ll ever need for your encryption needs.

Which end-to-end encrypted email is best?

After the 2013 Snowden revelations, there has been a push to make email more private than it currently is (which is, essentially, like writing on a postcard). The big guns, Google and Yahoo, have wowed to make their respective email systems end-to-end  (E2E) encrypted but progress has been slow. The official page about the Google effort has not been updated for months (as of June 2015). In this article, I go over some options available today, while we wait for that final solution that, at this pace, might still take a while to come.

There are dozens of options, but here I am going to review only a few that are better known in order to compare their features. Here I compare the following: Enlocked 2, Virtru,Proton mail, Mailvelope and, of course, my own PassLok. All of them promise to make encryption easy, at least compared to what it used to be. Some take pretty drastic shortcuts in order to achieve this, as we shall see. They all perform encryption and decryption at the user end, rather than at the server, since otherwise the server would have access to the plain content, with the consequent risk if subpoenaed or simply hacked. They all run the encryption code in JavaScript, which is a no-no for some, but currently there is no other way to run code locally on a browser.

Given that they all do the essential thing in some way or another, I looked into other desirable features of an end-to-end email system. Here’s a description of each feature:

  1. No need to change address. It’s a hassle if you need to use a different email address in order to have privacy. Here a Yes means that you can continue using your current email provider and address, and still obtain the benefit of encryption.
  2. Provider doesn’t store secrets. If it does, there’s always the danger that they’ll be forced to reveal them. Now, some providers store them in encrypted form, which is better, but still they’re storing something sensitive essentially forever.
  3. Provider cannot read email. As ludicrous as this may sound, at least one of the providers featured in this article is able to read your emails, or enable someone else to do so. We are assuming the encrypted content is easy to intercept.
  4. Account not required. Because some of us are paranoid enough to prefer not being forced to make an account anywhere, to prevent being tracked when we use it, or whatever other reason.
  5. Encrypt attachments. Not all we send is text. Often the sensitive information will be a picture, document, or any other kind of file. Encryption should be able to handle this.
  6. Encryption visible. A study published in 2013 showed that, for the time being, users prefer to see their messages in encrypted form at some point, in order to be assured that they are indeed encrypted before they send them out. They were willing to go as far as cutting and pasting the material in order to get this. This feature does not need to be on 100% of the time, but at least as an option.
  7. Encryption can be disguised. A number of users need encryption because they fear they are under surveillance. They would be even happier if they could make their emails and attachments appear as if they were not encrypted at all. This is called steganography, and at least one of the systems reviewed adds this feature to the mix.
  8. Forward secrecy. This means that the encrypted content remains secure into the future, even if the encryption key or the user password is obtained by an enemy. This is considered essential for instant messaging apps, and would be nice if email could also pull this trick, perhaps as an option.
  9. Multi-platform. It is no good if users need to use a particular kind of device (PC, iPhone, whatever) in this fractioned market.
  10. Portable across machines. This means that a give user should be able to use his/her E2E encrypted email on different machines, possibly of different kinds, with a minimum of risk and hassle.
  11. Multiple identities. What if several family members or coworkers share a computer? Can they keep privacy from each other? What if you’re schizophrenic or have multiple personalities?
  12. Open source. A deal-breaker for many, if it is not. Some of us feel a lot more reassured if the underlying  code is available and experts can subject it to scrutiny.
  13. Crypto engine. There are a number of cryptographic engines out there, some more recent than others, but all the systems presented here use an engine that has accumulated at least ten years of scrutiny.

So here’s the comparison as a table. Yes is good, No is bad. Some entries have a footnote right below the table.

FeaturesEnlocked 2VirtruProton mailMailvelopePassLok
No need to change addressYes1Yes1NoYes1Yes
Provider doesn’t store secretsNo2NoNo2YesYes
Provider cannot read emailYesNoYesYesYes
Account not requiredNoNoNoYesYes
Encrypt attachmentsYesYes3YesNoYes
Encryption visibleNoNoNoYesYes
Encryption can be disguisedNoNoNoNoYes
Forward secrecyNoNo3NoNoYes
Multi-platformYes5Yes5YesNoYes
Portable across machinesYes6Yes6YesNoYes
Multiple identitiesNoNoYesNoYes
Open sourceNoNoNoYesYes
Crypto enginePGPAESPGPPGPNaCl
Overall score (# of yes)545612

1. The app works only with certain email providers, not all of them
2. They do store encrypted private keys, hence the bad score
3. Separate encryption and delivery from server
4. They deny access to the encryption key (paid feature), but the key is not deleted
5. Browser plugins plus apps in iOS/Android stores
6. User secret data saved in servers (encrypted) enables this

Now a short description of each E2E provider, and why they got these scores.

Enlocked 2

Their first version got slammed by reviewers because it was doing the encryption on a server instead of the client. This meant that their server got  to see the plain text of your private stuff, even though they promised (who doesn’t?) that they didn’t store it. Enlocked 2 is a browser plugin (standalone mobile apps exist) that performs PGP encryption on the client. Their server holds each user’s public key so it can be sent to other users who want to encrypt messages for the owners of those keys to read. The plugin automatically retrieves each public key belonging to a recipient in an email and uses it to encrypt the content before sending the encrypted result to the actual email provider. Because it is a plugin, it only works with Gmail, Yahoo mail, Outlook, and a handful more.

In order to achieve portability, Enlocked also stores and serves the user’s private key, previously encrypted by his/her password. This is a problem, since compromising that password or choosing a bad one (Enlocked accepts bad passwords without complaint) makes all your encrypted emails readable by Enlocked or those to whom they give your private key.

Enlocked is a commercial service, which costs $9.99 every month for sending 100 messages, and goes up from there. You can sign up for a free account, though, which allows you to decrypt an unlimited number of messages and encrypt 10 messages every month. Their system seems to be glitchy: I’ve tried for several days to make a free account without success, leading only to error screens that instruct me to contact support (without any link to support, though).

Virtru

On the surface, Virtru behaves very much like Enlocked. They have slick plugins and mobile apps. They encrypt text and attachments. You only need your account password to use it anywhere you go. The difference is that they use symmetric encryption (256-bit AES) instead of asymmetric encryption (PGP). When you encrypt something, you send the actual, per message encryption key to Virtru, and they store it so they can give it to the recipients of your encrypted message. The whole process is quite automatic and makes it possible for new users to be added in a flash, since no initial key generation and exchange process is needed.

The downside is that they can read your encrypted messages, if intercepted (they are sent through your regular provider, from a limited list of supported ones), and enable anyone who asks nicely to do so. This should be a deal breaker for anyone who has real confidential material to protect. To make matters more egregious, they charge for “forward secrecy”, meaning that Virtru promises to no longer give the decryption key to anyone except you (and, possibly, government agencies).

If you don’t want the paid features, Virtru is free to use, though making an account is a must. A Pro account with the extra features will normally set you back $4 a month.

Proton Mail

Proton Mail is Enlocked with an email server thrown in. When you sign up for Proton Mail, you sign up for the whole thing, and you get a username@protonmail.ch email address. No way to keep using your old address except by forwarding. Proton Mail requires the user to memorize two keys: one is for logging into the email server and getting your emails, plus obtaining the PGP public keys of other users automatically; the other is for encrypting your PGP private key, which is stored in their server so you can use different machines. Since they must know your login key in order to give you access, they’d also be able to read your encrypted mails if both keys were the same, hence the need for two separate keys.

Proton mail is accessed strictly as a website, so no plugins or mobile apps are involved. Interestingly, this approach makes it accessible from any device, running any operating system.

Proton Mail just finished beta and is available for signups, everything is free, though not open source. I believe that Google’s and Yahoo’s E2E solutions, when they come, will end up looking a lot like Proton Mail.

Mailvelope

If Proton Mail was Enlocked plus a mail server, Mailvelope is Enlocked minus a key server. It uses PGP like the other two, but key generation is kept strictly to your machine. The user is responsible for distributing his/her public key to others, and for safeguarding his/her private key, which is locally stored encrypted by a password. Mailvelope is only available as a Chrome extension and off the box it is limited to Gmail, Yahoo mail and a couple more, though apparently you can configure other clients manually (I didn’t try). Integration with those is quite slick, however, as Mailvelope detects encrypted incoming emails and offers to decrypt them if only you supply the password.

This extension may be all that many people will ever need, so long as they don’t use encrypted email with a lot of people (public key entry and selection is a bit involved) and don’t need portability (settings don’t sync across machines).

PassLok

Obviously it was a foregone conclusion that PassLok was going to be the winner in a comparison made by its own developer. I won’t dispute that, but the fact remains that PassLok has all the desirable features on the list. You can use it with your existing email (in fact, with any program at all). It doesn’t store your content or even anything secret. It doesn’t talk to servers so you’re not making any account anywhere. It handles files as well as text. It runs as a Chrome plugin, iOS/Android app, or just as a webpage that gets completely cached so you don’t even need an Internet connection after the first time. It includes a full complement of text and image steganography tools so your encrypted material can slip undetected. In its Chrome app incarnation, it even syncs all your stored public keys (which are not secret, but may be hard to obtain again) using Google’s servers. It is possibly the only web app available today capable of making a self-destructing message, where the key needed to decrypt it disappears from the face of the earth as soon as it is read once.

But it must have some defects, right? C’mon!

A lot of PassLok’s security lies in the fact that it is self-contained code, and precisely this is why some things are harder to do than in other systems. PassLok does not interact with email clients, and so the user must manually copy and paste the encrypted material between PassLok and whatever email client you are using. This is a hassle, but it has the advantage that you know without a doubt that your data is encrypted before it gets to your email. Some email providers, like Google, log every keystroke you type into the compose window, so it is important to encrypt your messages before the email program sees them.

PassLok does run a server to help users obtain other users’ public keys. It is called General Directory, and currently it is manual rather than automatic so that the main PassLok code is isolated from contact with any server. A lot of things in PassLok are automatic, but nothing is forced on the user. If the user decides not to make public his public key, but rather send it to a selected few, that’s okay with PassLok. Most PassLok users actually do this. They are a paranoid but dedicated bunch.

PassLok for Email enters beta

logo v2-440x280 emailJohnny can’t encrypt. It’s no use. . . . This is what has been said repeatedly about mere mortal users and encryption, which forever has been the domain of black chambers and mathematical geniuses. Scores of companies have tried to get around this problem by hiding encryption in their servers, far away from users’ eyes.

And yet, studies have shown that this creates another problem: if I can’t see any of the encryption, how can I relax and be sure that this message where I’m risking my career, maybe my life, is truly away from prying eyes? Just because the software tells me to relax?

PassLok does not hide encryption from users, and it tries hard to make it accessible. This is why the next step in its development is so important. PassLok for Email is a new Chrome extension that adds PassLok encryption to regular web-based email apps. Its beta, which supports Gmail, Yahoo, and Outlook online, has just been released for public testing. Read More