“Luke, can you check the permissions again? It’s either that or the password you gave me does not work.” said the email. I rolled my eyes and started rummaging through the pile of papers on my desk searching for my notes. After a few minutes I found the scrap of paper where I hastily wrote down that password. It was something along the lines of: sp10ftzoln8.
I got the email guy on the phone and our conversation went something like this:
“Ok, can you give me the password again?”
Sure, it is S as in same…
“Wait, S as in Same or F as in Fame..”
No, Sam, Samantha, Salmonella. S.
“Got it. Next letter.”
P, one, Oh…
“T as in Thomas or..”
No, P as in Peter
Peter. Parker. You know, Spiderman…
“So wait, I’m confused. Is it Peter, Heater, or Spiderman”
P. Penelope. Pundit. Patricia.
“Got it. What was the next one?”
“Yes, next one”
Whose on first?
“Very funny… So number one, right?”
“I’m gonna write it down with the little serif… I never do serifs on my ones but then I always thing it is an L when it comes to passwords”
That’s actually a very good policy.
“Next was O, right? As in Olaf?”
Yes… I mean no! Zero. It’s a zero.
Ok, from now on I’m going to say ZERO when I mean numbers and Oh when I mean the letter.
“Got it. Next letter please.”
And so it went. Then we had to get on the phone again, because the L became a 1 in the general hand written serif confusion.
This made me think that there should be a better way of doing this. It’s not like this is a new problem either. We have already solved it long time ago using this little thing called encryption. If you want to send someone a password over an insecure network (such as the internet) all you need to do is to encrypt it. There are dozens of tools out there that will let you take a file, encrypt it and send it off to someone else. Most of them have one problem: they use symmetric encryption.
When you use symmetric encryption, you encrypt your message with a key (or a password if you will). This key must be known to both parties ahead of time. So at some point you will need to securely exchange it. How do you do that? Well, you definitely don’t want to email a key in plaintext. So you need to meet, get on the phone or devise some other way of passing the key along, which brings us back to our original problem.
Now, the key exchange issue was also solved a long time ago with the concept of asymmetric encryption. The idea is to use two keys, one public and one private. Public keys can (and should) be shared over insecure networks. They have a single purpose – they allow you to encrypt a message, that can later only be decrypted by a corresponding private key.
This is exactly what we need here. Instead of trying to play the spelling bee over the phone, I could simply request my recipients public key, encrypt the password and be good to go. The problem with this issue is implementation. The most popular assymetric encryption software is PGP. It has a great private/public key management software that integrates with Outlook as well as has dozens of solutions (like a web portal where you can create temporary email accounts for your recipients) but all of them cost money. All I really need is something quick and easy. GPG, the free, open source implementation of PGP is a step in the right direction but… Well, it is not very user friendly… I mean, there are several different clients for it, and some of them are actually pretty decent but I’m not talking about general usability right now. What I need is a stand alone client that someone could download, install and use in two minutes or less. GPG is a bit of an overkill here. It basically assumes you will be using it all the time. So you generate your key pair, you then set up a key ring where you collect public keys of the people you exchange emails with. It integrates with your email client and also allows you to cryptographically sign your emails to prove you sent it. But I don’t need anything like that.
What I really want is a stand alone app with two buttons: send and receive. If you click on Receive, you will be given a public key which you then paste into your email and send to your friend. If you click on Send, you get a text box where you paste the public key and a file chooser that lets you pick a file to be encrypted. Then you send that file over, and the recipient decrypts it. Once the whole process is done, you close the application and forget about it.
I don’t care about key management. I don’t care about signing, or identity verification. I just want an assymetric encryption app which lets me exchange a file or two with minimum fuss. I did some googling, and I could not find anything like it out there. So I decided to write my own.
Here is a screenshot of the prototype:
See, easy three buttons and some explanatory text. I called it “My Temporary Public Key” or “MyTPK” for short, because that is the idea behind it. You generate a key pair, you use it to exchange a message or two and then you discard it. We are not signing anything, we are not storing keys, we are not checking identity. It is all about simplicity.
As I mentioned before, the recipient gets a text box with a public key he can copy and paste into an email:
The application will preserve this key, until the user decides to generate a new one. Sender on the other hand will see this:
One thing I really did not want to do when working on this project, was to write the actual encryption back end. First off, there is no reason too. Second, there are hundreds of reasons not too. Chief of which is the fact that every single little bug, omission or design flaw in your code opens up a window for a potential attacker. I simply do not feel confident enough to just hack together a small tool, and then tell people it is safe to use without massive amount of testing by security minded people.
On the other hand I also did not want to create dependencies. I could of course create a nice tool that would hand off the encryption work to GPG but that would require more work for the potential user. I want something self contained. So in the end I decided to use built in encryption libraries.
Then I hit a few interesting snags in development, but I’m going to talk about them next time. Those perceptive enough probably noticed I’m using RSA keys, and can probably figure out the message size surprise I encountered. I will talk about how I got around it in the next post. I’m not releasing the code yet because it is sort of broken at this point. It works for me, but it is very rough. I want to tidy it up a bit, make sure it handles at least half the exceptions it is throwing, and then I will probably post it on Google Code or Github and let people rip it apart for security flaws.