5 ms·

https://whispersystems.org/blog/asynchronous-security/ https://whispersystems.org/blog/asynchronous-security/ https://whispersystems.org/blog/advanced-ratchetin

• e12e 12y ago
  > With the initial key exchange out of the way, both parties can then continue communicating with an OTR-style protocol as usual. Since the server never hands out the same prekey twice (and the client would never accept the same prekey twice), we are able to provide forward secrecy in a fully asynchronous environment. 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.
  • rakoo 12y ago
    > (the message will only be encrypted when the pre-key can be retrieved). 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 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.
    • e12e 12y ago
      > 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. 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).
• lmm 12y ago
  So yeah, you're relying on a central authority to maintain the prekeys and only give out each one once. The within-session ratchet is cool but I'm not sure if it's relevant to an async use case like email where messages can be sent months apart (would you ever even use a session for more than 1 message?) and the user /wants/ to retain the ability to read their old messages. Likewise the non-repudiation aspect of PGP is by design: it's meant for a use case where you want to "get something in writing", it's supposed to behave like a signature on a letter. (And by the same token it's very much an inappropriate protocol for e.g. IMs, which is why even big fans of GPG will use OTR or some such for those instead). 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.