Procedural knowledge gap: public key encryption
post by Solvent · 2012-01-12T07:35:58.669Z · LW · GW · Legacy · 18 commentsContents
18 comments
In the spirit of uncovering procedural knowledge gaps, I'd like to know how to use public key encryption.
Is there some website which generates public and private keys, and lets you encode and decode according to those keys?
I'd love if there was some way I could send my encoded text via IM or email, and just decode it like we do with rot13. Is there some way of doing this?
Currently, I encrypt things using TrueCrypt, but there's no way that I can communicate with people with that without securely establishing a common key beforehand.
Does anyone know how to do this?
18 comments
Comments sorted by top scores.
comment by Viliam_Bur · 2012-01-12T09:20:32.623Z · LW(p) · GW(p)
I haven't used e-mail encryption for a while, I am not sure how exactly to set it up, but once it is installed, it's very easy to use. Here is what I know, though you will need more details; perhaps someone here can add them.
First, you need a mail client that supports encryption. I use Mozilla Thunderbird as an e-mail client, and there are some plugins that support encryption. I don't have recent experience with them, so I don't know which one to recommend. (After short googling, Enigmail seems to be a popular choice.)
Second, to send encrypted e-mails or digitally signed e-mails, you need a public/private key pair. There are some softwares that will generate such pair for you, and you will add them to your mail client. Additional layer of security is if you have a certificate confirming that this is your public key. (Such certificate protects you against a kind of attack where I would send your friends an e-mail pretending to be written by you, including my public key pretending that it is your public key -- or I could do the same thing by hacking your webpage, if your public key is published there.) Last time I tried this, there were some certificate companies that would give you a free certificate, but only for non-commercial use and with validity of one year. Another use of certificate authority is that if someone steals your private key, you can publish an information that people should not use the corresponding public key anymore.
Please note that encryption and digital signature are two sides of the same coin. Simply said, encryption (based on public/private keys) is "everyone can write, but only one can read", and digital signature is "everyone can read, but only one can write". Actually, there is no difference between private and public key -- they are just two numbers that together have some mathematical property, and their role in this property is symmetrical: if you encrypt something with public key, you can decrypt it with private key (this is called encryption), and if you encrypt something with your private key, you can descrypt it with public key (this is called digital signature verification).
This is the difficult part, but once it is done, using the system is the easy part.
If you receive a digitally signed message, it will have an icon (colored pen). By clicking on the icon you can add the person's public key to your database. (You should be pretty sure that the mail was really sent by that person, not someone pretending to be them.) If you have someone's public key in a database, when you write them an e-mail, you can select to send it encrypted. You can also select to digitally sign your e-mails (which will allow other people to send you encrypted messages). If you receive an encrypted message, it will be automatically decrypter for you.
It really is as simple as checking "sign this message" and "encrypt this message" when sending mail, and clicking "import this signature to my contact list" when receiving a signed mail. Otherwise it is like normal e-mail use.
comment by jhuffman · 2012-01-12T15:20:11.928Z · LW(p) · GW(p)
GPG seems to be gaining mindshare. It is an open-source set of libraries and command line tools that inherits a lot of the interface from PGP (which is proprietary).
I have used the Cryptophane interface on windows and it makes it pretty easy to generate keys and manage them in your local keystore as well as to sign, encrpyt and decrypt arbitrary text. This would get tedious if you did a lot of email though but based on what you described I think it would work well for you.
Here is a link to other front-end tools for GPG: http://www.gnupg.org/related_software/frontends.html
comment by roystgnr · 2012-01-12T16:33:40.029Z · LW(p) · GW(p)
I'd also recommend GPG, especially if you use (or could switch to) an email client with a decent plugin for it.
One note: you still need to securely establish common keys beforehand; public key encryption just makes "securely" easier. To attack a symmetric key encrypted communication, you just need to be able to eavesdrop on the key and the encrypted content. To attack a public key encrypted communication, you need to be able to eavesdrop on both public keys, block the true public key messages from reaching their recipients, inject false messages with your own public keys, and then eavesdrop on the encrypted content. None of the industrial-scale solutions for preventing this (certificates, web-of-trust, etc.) are very satisfying to me, but "call your buddy on the phone and spend 20 seconds reading key hashes out loud" is fine for personal security.
comment by geebee2 · 2012-01-12T23:05:01.154Z · LW(p) · GW(p)
For email, the main problem is the automating the public key management. There is some hope here in the deployment of secure DNS (DNSSEC), which has the potential to automate the process so that everyone, by default, has a public key without taking any special action.
However progress is extremely slow and the incentives weak, so I would be surprised to see significant progress any time soon for email.
If you use Skype (and probably other proprietary systems, even your mobile phone) encryption will probably come as standard. There may however be back-doors, possibly allowing the provider, governments and law enforcement access. But it's better than nothing. The architecture of Skype, where the traffic passes through completely untrusted super-nodes (for example my computer!) pretty much demands the use of encryption.
comment by DanielLC · 2012-01-12T18:47:55.120Z · LW(p) · GW(p)
While we're talking about this: does anyone know why encryption isn't standard? What advantage is there in communicating with someone without encryption?
Replies from: malthrin↑ comment by malthrin · 2012-01-12T18:51:20.375Z · LW(p) · GW(p)
The main reason is that it requires your recipient to take an extra step. If you send an encrypted email to someone else, and they haven't configured their mail client for encryption, then they won't be able to read it. For most people, that negative outweighs the privacy gain.
Replies from: khafra, Viliam_Bur, DanielLC↑ comment by khafra · 2012-01-12T21:39:23.559Z · LW(p) · GW(p)
Also, encryption is easy; key management is hard. If your workplace sets up a Public Key Infrastructure on your Exchange server, all you have to do is click "encrypt." But outside of an organization that uses it, you'll need some out-of-band way of exchanging keys with everyone you want to communicate with. And, as fun as key-signing parties are, they can be a little awkward for, say, someone you just met on reddit.
Replies from: malthrin↑ comment by malthrin · 2012-01-12T22:15:49.921Z · LW(p) · GW(p)
Right. Encryption is a lever; it permits you to use the secrecy of a small piece of data (the key) to secure a larger piece of data (the message). The security isn't in the encryption math. It's in the key storage and exchange mechanism.
*I stole this analogy from something I read recently, probably on HN.
↑ comment by Viliam_Bur · 2012-01-13T09:17:33.626Z · LW(p) · GW(p)
Before you send an encrypted (PGP-style) mail to someone, you need their public key. The recipient's public key is used to encrypt the message for them. So when you are able to send en encrypted e-mail to someone, they probably already have everything configured.
I guess most people don't care too much about their e-mail privacy; or at least don't have a clue that there is something that could be protected, but isn't. And if you use a free webmail, there is no point in encrypting your messages (and I don't know if it is even possible). If you are OK with Google company reading and archiving all your e-mails... yeah, Google would never do anything evil. ;-) And Google is probably better than Facebook, and many people don't mind sending their private data through Facebook messages.
For many people the costs of encryption would be not only configuring their e-mail client, but first installing it, and accepting that they cannot send e-mails from any place, but only from their own computer. Some people don't even know that it is possible to use e-mails without connecting to a website.
Replies from: SilasBarta↑ comment by SilasBarta · 2012-01-13T20:55:13.346Z · LW(p) · GW(p)
And if you use a free webmail, there is no point in encrypting your messages (and I don't know if it is even possible).
Of course it's possible: Compose the email in a different program, encrypt it in GPG with the recipient's public key, and paste the ciphertext in the webmail's message field.
It's just inconvenient.
↑ comment by DanielLC · 2012-01-12T22:54:06.113Z · LW(p) · GW(p)
You only have to configure it because it isn't standard. If it was, anyone who had a mail client would be able to read it.
I don't just mean email. I was referring to any kind of information transfer.
What's especially odd is with webpages. I've never seen a browser that can't handle https, and yet, if you're not sending something secure, they just use http.
Replies from: arundelo↑ comment by arundelo · 2012-01-13T00:50:14.686Z · LW(p) · GW(p)
I've never seen a browser that can't handle https
But an HTTP server that doesn't have a unique IP address cannot use HTTPS. There are extensions to the standard that fix this problem (e.g., Server Name Indication), but they are not widely supported. (The problem stems from SSL working on a lower level of abstraction than HTTP.)
comment by SilasBarta · 2012-01-12T17:37:01.536Z · LW(p) · GW(p)
Nothing to add at the moment that others haven't already. But I went through the same process myself (with GPG), and I have an interest in how to convey information like this, so please do not hesistate to say if any of the answers given are incomplete and I will try to fill in the gaps.
comment by FiftyTwo · 2012-01-15T18:48:52.918Z · LW(p) · GW(p)
Genuine question, what benefit is there to encrypting things in this way? Surely anyone really serious could decrypt it (security agencies etc) and you're already safe from non-specialists, so who is the protection aimed at?
Replies from: MBlume↑ comment by MBlume · 2012-01-15T19:00:40.035Z · LW(p) · GW(p)
Surely anyone really serious could decrypt it (security agencies etc) and you're already safe from non-specialists
Actually no. Unless the NSA has secret mathematical knowledge that a) they're not sharing and b) the worldwide mathematical community has otherwise failed to reproduce, no one can break the sort of bog-standard encryption your $200 laptop will do for you, without building a huge cluster of computers to manually try keys one by one. I think it's kind of cool that the math works out that way -- the world would be pretty different if it didn't.
ETA: and for each digit you add to your key, it will take them sixteen times longer to do this operation. And generating and using arbitrarily long keys is pretty much computationally trivial.
ETA 2: It was an honest question, don't think downvotes are called for.
Replies from: Anubhav, FiftyTwo↑ comment by FiftyTwo · 2012-01-15T19:20:57.435Z · LW(p) · GW(p)
Ah thank you. I was under the impression there were recognisable patterns from the programs, but I guess not enough to make it crackable. Thinking about it given the number of calculations a modern processor can make a second, plus the exponential nature of such things it shouldn't be that surprising.
However if various prominent pure mathematicians start disappearing in mysterious circumstances we may need to worry...