Alice and Bob and PGP Keys

Last week Alice and Bob showed how to cryptographically sign messages so that the recipient can be sure that the message came from the purported sender and hasn’t been forged by a third party. They can only do that if they can securely retrieve the senders public key – which means they need to retrieve it from the actual sender, rather than an impostor, and be sure it’s not tampered with en route. How does this work in practice?
If I want to send someone an encrypted email, or I want to verify that a signed email I received from them is valid, I need a copy of their public key (almost certainly their PGP key, in practice). Perhaps I retrieve it from their website, or from a copy they’ve sent me in the past, or even from a public keyserver. Depending on how I retrieved the key, and how confident I need to be about the key ownership, I might want to double check that the key belongs to who I think it does. I can check that using the fingerprint of the key.
A key fingerprint looks like this:

pub 4096R/856DCBBC 2014-09-22 [expires: 2024-09-19] Key fingerprint = 7393 3400 738B ABFD 3C7A 4F31 B3E7 BD58 856D CBBC
uid Steve Atkins <steve@wordtothewise.com>

I can call my correspondent on the ‘phone to check that the fingerprint of the key I have matches their key, or check the fingerprint against somewhere they’ve published it, maybe a public blog post, or on their business card:
front_jpg_1_137×632_pixels
Another option is to use a service like keybase.io, which allow people to connect their keys to their online or social media presence, and provides some tools to make using PGP less user-hostile.
If this all seems a bit ad hoc to you, you’re right. The original approach PGP used was a web-of-trust, where you’d nominate people whose public keys you had, and you knew, as trusted or partially trusted. If someone was introduced to you, and their public key was vouched for by some configurable number of people you trusted then you’d believe that the key belonged to them. Combine that with key-signing-parties (which aren’t as exciting as they sound, just a bunch of people getting together to vouch for each others PGP keys), and you end up with a decentralized approach that sounds wonderful to an introverted crypto-nerd, and works well enough within small groups, but isn’t attractive to enough people to be able to take advantage of the network effect to break out beyond those small cliques. Web-of-trust requires far too much work and advance planning to be convenient for casual use of encrypted email other than amongst small groups of crypto-nerd friends, yet isn’t really secure enough to rely on where it’s important.
responsible_behavior_small

Related Posts

Useful bits of Cryptography – Hashes

More than just PGP

Cryptography is the science of securing communication from adversaries. In the email world it’s most obvious use is tools like PGP or S/MIME that are used to encrypt a message so that it can only be read by the intended recipient, or to sign a message so that the recipient can be sure of who it came from. There are quite a few other aspects of sending email where a little cryptography is useful or essential, though – bounce management, suppression lists, unsubscription handling, DKIM and DMARC, amongst others.

Read More

Alice and Bob Sign Messages

Alice and Bob can send messages privately via a nosy postman, but how does Bob know that a message he receives is really from Alice, rather than from the postman pretending to be Alice?
If they’re using symmetric-key encryption, and Bob is sure that he was talking to Alice when they exchanged keys, then he already knows that the mail is from Alice – as only he and Alice have the keys that are used to encrypt and decrypt messages, so if Bob can decrypt the message, he knows that either he or Alice encrypted it. But that’s not always possible, especially if Alice and Bob haven’t met.
Alice’s shopping list is longer for signing messages than for encrypting them (and the cryptography to real world metaphors more strained). She buys some identical keys, and matching padlocks, some glue and a camera. The camera isn’t a great camera – funhouse mirror lens, bad instagram filters, 1970s era polaroid film – so if you take a photo of a message you can’t read the message from the photo. Bob also buys an identical camera.
sign1
Alice takes a photo of the message.
sign2
Then Alice glues the photo to one of her padlocks.
sign3
Alice sends the message, and the padlock-glued-to-photo to Bob.
sign4
Bob sees that the message claims to come from Alice, so he asks Alice for her key.
sign5
(If you’re paying attention, you’ll see a problem with this step…)
Bob uses Alice’s key to open the padlock. It opens (and, to keep things simple, breaks).
Bob then takes a photo of the message with his camera, and compares it with the one glued to the padlock. It’s identical.
sign6
Because Alice’s key opens the padlock, Bob knows that the padlock came from Alice. Because the photo is attached to the padlock, he knows that the attached photo came from Alice. And because the photo Bob took of the message is identical to the attached photo, Bob knows that the message came from Alice.
This is how real world public-key authentication is often done.

Read More

Clicktracking link abuse

If you use redirection links in the emails you send out, where a click on the link goes to your server – so you can record that someone clicked – before redirecting to the real destination, then you’ve probably already thought about how they can be abused.
Redirection links are simple in concept – you include a link that points to your webserver in email that you send out, then when recipients click on it they end up at your webserver. Instead of displaying a page, though, your webserver sends what’s called a “302 redirect” to send the recipients web browser on to the real destination. How does your webserver know where to redirect to? There are several different ways, with different tradeoffs:

Read More