PGP: There’s Life in the Old Dog Yet

It's pretty straightforward if you already have a key pair / GPG installed. There's no Keybase software to run, and the site basically acts like a todo list / tutorial.

The pre-key is needed when you have never talked to someone (I guess it's also needed when the last conversation is really old, I haven't dug throuh the code); it's a necessary bootstrap step. After that all you need is inside your client.

> So, my laptop is off-line, and I have access to a recipients public key. How do I encrypt my message, before moving it to a machine that's on-line for sending via smtp?

You encrypt it on your laptop, transfer the encrypted blob to your online machine and send the blob through it. All state is managed by your laptop, intermediary machines are just forwarding the message (which is merely an opaque blob at this point, possibly with a "destination" to ease routing to the recipient(s)).

> Nor does it appear to work for writing and encrypting an sms while on an air-plane

From a user pov, there is no difference between:

- I type the message and hit send, the message is encrypted now and sent when I have connectivity

- I type the message and hit send, the message is encrypted and sent when I have connectivity

The problem here will not be technical but purely UX (the software has to allow deferring encryption and sending when resources are available)

> It also carries more state around (on the "server" and on the "client") so it's not decentralized.

The little state there is on the server really doesn't sound centralized to me in that it is really simple (the server must be able to store a given list of blobs sent by the client, and the server must not send twice the same blob, ever) and a client can choose any server (there is no concept of "registration", but the client has to trust the server it will not misbehave).

The state on the client is really client-specific, it wouldn't make sense to share a client's ratchet state: as a comparison you wouldn't share the current bucket list of your DHT client with other machines because it doesn't make sense, you would rebuild it from scratch on another machine. Effectively this means every device of yours is considered another independent "peer".

I think it's important at this point to say that this mechanism is the Axolotl ratchet (more details here: https://github.com/trevp/axolotl/wiki). It only describes how to exchange encrypted messages between two DH keys, asynchronously, and with forward secrecy. It doesn't care about :

- what is the relationship between DH keys ("should I encrypt to 2 DH keys because they belong to the same user ?")

- how do get someone's key, and is it the good one (the key distribution management)

- how can I have a coherent message history between my phone and my computer

These are all real problems that TextSecure aims to solve, but they're a whole another thing.

People who say that security is meant to be hard are missing the point, OTR has been around for a long time and is not only much more secure than PGP but more useable. If you want truly secure asynchronous messaging you should checkout Pond by Adam Langley, which is arguably the only traffic analysis and metadata resistant messaging protocol on the planet. Unfortunately PGP has been designed in a way that careful key management is pretty much a requirement if you want. PGP key verification is extremely painful on every implementation I've ever seen, and unless you do it you are vulnerable to extremely potent attacks which are the result of plaintext key sharing algorithms like HKP and LDAP.

I'm with moxie on this one, I get sad that people are still trying to build modern 'secure' architecture based on a ~20 year old cryptosystem. It sets everyone who cares about useable security back because you are continually encouraging people to cling on to the old paradigm. Unfortunately there is no clear, universal successor to the PGP kingdom... yet.