“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..”
It’s S
“F?”
No, Sam, Samantha, Salmonella. S.
“Got it. Next letter.”
P, one, Oh…
“T as in Thomas or..”
No, P as in Peter
“Heater?”
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?”
One
“Yes, next one”
Whose on first?
“Very funny… So number one, right?”
Yes.
“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.
“Oh!”
Stop it!
“No.”
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:
MyTPK Main Window
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:
Recipient window
The application will preserve this key, until the user decides to generate a new one. Sender on the other hand will see this:
Sender window
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.
You wrote down a password? Heresy! :D
That app seems very useful, although I would probably try to “hide” the key from the user, by letting him/her send it directly to a email address from the app itself as an attachment, and then the recipient would load the file.
One thing that always bothered me is why don’t the major instant messengers already encrypt connections? It would be so much easier to simply copy-paste or send a file over IM, especially since most people already use them; but installing and teaching to use Pidgin or other client just for that is too cumbersome.
@ IceBrain:
I think the encryption should come from a third party. So you can be sure that the private date can’t be tapped into by the transportation provider.
IceBrain wrote:
Yes, I know… I figure it’s ok for temporary passwords that will get discarded/changed in a day or two. This one was a password for a temporary test user on one of the machines.
IceBrain wrote:
Sounds like a good idea. On the other hand I’m a bit concerned it will involve too many extra steps… Like save the file to disk, load the key, load the file, etc…
I’m figuring that copying and pasting is fairly easy and if I remember to trim the leading and trailing whitespace most users should be able to do it without messing up. I guess I will have to test this on some users and see which method tracks better with the clueless.
@ Eric:
I was about to say the same thing. It would be trivial for them to envelop your data in SSL but you still could not be sure that your data can’t be intercepted or logged by someone with access to your IM providers servers. I mean, you can trust your IM provider but if you are a company, this is a bit more complicated.
This is also the reason why we are not allowed to roll out Mozy on the laptops for remote workers even though it would make backups so easy. I pitched it to the powers that be and they shot me down as soon as I said “the data would be encrypted and stored on their servers”.
I vaguely recall trying to set up a encryption cert for AIM back in the day, so I’m thinking it used to support some third party encryption. Maybe I was using Pidgin though. But yeah – it involved work up front to set it up.
This is an interesting problem. I think it’s related, or at least similar, to the problem of file transfer across the Internet (I think you wrote about this once, but I can’t find it right now). The layman’s computer setup isn’t configured for easily sending data directly to another party across the Internet. Windows doesn’t come with HTTP, FTP, or SSH servers. In the same way, it doesn’t come equipped with any encryption software, so the use of encryption involves the large overhead of obtaining, installing, and operating some additional piece of software.
This isn’t a problem I run into personally anymore. Ever since I did some convincing of family members and friends a couple years ago, 99% of my IM conversations are encrypted with Off-the-record (OTR), so any sort of password sharing, or other confidential info, can be handled over that existing channel. Also, half of the people I would call my friends know how to make use of GPG and maintain their own public keys — not that they get used much, because OTR has proven to be so useful.
In fact, just over this last weekend I wanted to give a friend SSH access to one of my servers. Passwords weren’t mentioned at all: he sent me his public SSH key (id_rsa.pub), I made a new unix account, dropped the key in ~/.ssh, and told him to go ahead and log in.
At work some of us make pretty heavy use of our public key infrastructure. They’ve implemented it fairly well, too. Everyone has a public/private keypair. Before the certificate authority will sign off on a new keypair, the owner of the key has to arrive in person at the IT office to attest the identity of the key. I personally go the extra step and sign all my outgoing e-mail. I do this both because it’s fun and because it makes people less likely to reply to my email (replying usually means more work for me!). Why is that? Outlook tries to force the reply to be signed, refusing to send otherwise. This means the sender has to type in their long passphrase, which may have even expired from disuse. That’s just enough to discourage many replies. :-D You can tell Outlook to not sign the e-mail, but few know how to do this, especially the ones that already struggle with key management.
Your project is an interesting idea, and I think it could see it being useful in certain situations, like the one you described. Seeing your screenshots makes me want to try my own hand at making one! One suggestion I’d make, since you’re really trying to create this for the most novice of users, is to cut down on the wordiness even more. If it’s more than about five words, no one will read any of it.
For example, in “Step 2” on the send screen, you have, “Pick a file to send to your friend. You can only pick one at a time.” I’d make one single bold sentence with something like, “Pick one file to send.” More information can be added in a non-bold in case it’s needed, but it will be unemphasized as to be non-distracting.
But for all the emphasis on security, asking the user to go download this new program and execute it sounds out of place! :-) How much does this other user trust you? In your phone conversation it seemed you know each other fairly well. But do you want this person to so unquestioningly execute some strange software just because someone told them to over the phone?
I wonder how hard it would be to implement this as a JavaScript web application that runs client-side-only inside the browser. Then the user wouldn’t have to execute potentially untrusted code with normal permissions. But it seems it would put a limit on the size of the file being encrypted — whatever amount of memory the browser supplies to JavaScript — and there would also be clipboard interaction problems: you couldn’t make a convenient “Copy to Clipboard” button like your program currently has.
Anyway, I look forward to your follow-up post.
pilots also solved this problem a long time ago:
http://www.aopa.org/letsgoflying/dream/takeflight/0901alphabet.html
Or you jst send it in plain text, i mean what are the chances? This is not Volkswagen
Hrhr, “MyTPK” made me smile.
The idea is nice and the way you created the program is really great!
Simple, elegant, easy enough to understand that there shouldn’t be many problems.
But the name -for me as a long-term-roleplayer- is just the best.
TPK is roleplayerish short for Total Party Kill :)
Chris Wellons wrote:
Yes. Good point. Brevity is king. I often forget that. :)Chris Wellons wrote:
Well, I didn’t really think about that. My approach was more along the lines of: here is a problem, let me throw some code at it. :)
Chris Wellons wrote:
Ah, but then there is another problem: do you trust the server where the script is hosted. It could always be uploading your file silently to the server while it is encrypting and a regular user would be none the wiser.
I guess with any encryption scenario you will always have a trust issue coming into play.
Oh, and thank you for the OTR link!!
@ road:
Yes… But this is still slow, error prone and requires synchronous communication over the phone. Not to mention that the phone conversation could be intercepted too – although at this point we are entering a tin-foil hat territory. Public key solution however is completely asynchronous, and is not vulnerable to eavesdropping.
@ MrJones2015:
You could. It depends on the circumstances. Some companies have very strict rules about this and you can get in trouble for sending passwords and/or confidential data in plaintext.
@ MrPete:
That’s actually exactly why I chose it. :) Not to hijack the thread, but what do you play?
I used to do a lot of Warhammer FRP and Star Wars D6. I also did some Mutant Chronicles, Vampire Masquerade and Space Master. :)
You could also provide a very simple way to keep the already used public keys for encryption in memory/a file, with the ability to give it a name (kinda like a key store, or an address book…), so that the user can reuse a public key he already used without shuffling through his emails.
@ xgbi:
I definitely could but… Well, we get back to the key management issue. I really like the idea of “TEMPORARY” public keys. You generate them as needed, and discard them just as fast. That’s why the app has a huge button that allows the user to do just that – generate a new key. I want them to hit it every once in a while. I would prefer users to think of these keys as “random passwords” tied to specific email/file rather than an encryption key associated with a person. People already know how to use passwords fairly well.
I have worked with end users in the past and I noticed that the file system is scary for many people. I had many users who would live in Outlook. They use it like a version control repository / filing cabinet. Shuffling through email is not an issue to them – getting out of the email and into the file system is an inconvenience. Which is why I actually want to implement drag/drop functionality for the encryption/decryption part. It would be nice if they could just drag the outlook attachment onto this tool.
I could add a key management feature, but by design the keys will become stale and out of date quickly. Not to mention the additional hassle of naming the keys properly.
@ Luke Maciak: Sure, I get your point and I agree.
Then maybe another thing as an improvement: handle the paper clip, so that if you have a key into your clipboard, it can extract it automatically and use it as the pre-filled public key :-)