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?
This isn't really asynchronous in the sense that email is (stop-forwards-stop-forward). Nor does it appear to work for writing and encrypting an sms while on an air-plane (the message will only be encrypted when the pre-key can be retrieved).
It doesn't seem quite fair to claim (or rather imply) that the scheme does for email what pgp does.
It also carries more state around (on the "server" and on the "client") so it's not decentralized. It might be closer to pgp than classic otr, but it's not really a replacement for pgp as far as I can tell.
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.
Well, no. It's needed when you client has never talked to someone. If you have a pad, a phone and a laptop, they all need a pre-key to talk to the same person. If the person's server is down, the system breaks down (you can't have just anyone mirror the pre-keys).
> 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
Perhaps not. But there's a difference between being alerted that you can't reach the recipient securely before you type the message, and getting that message (no pre-key available) after you've taken the time to write the message.
Not to mention that hopefully the device has FDE, so there aren't any plain-text messages around for when you go through customs, or when someone steals your phone etc. But I'll concede that device security is probably outside the realm of what a message system should deal with.
Don't get me wrong, I welcome improvements like this -- I just don't think it's comparable to pgp (which is both good and bad).
There's maybe a case for a protocol that offers both (though in practice I've just seen people sign their OTR key fingerprints with their PGP key), but that goes against the simplicity that you're emphasising.