3 ms·
> why not just run OTR on top of Jabber? Indeed, on the face of it hemlis looks like a step backwards. There's a chance it might not be, though. The most stra
by sigil 13y ago
> why not just run OTR on top of Jabber?
Indeed, on the face of it hemlis looks like a step backwards. There's a chance it might not be, though.
The most straightforward way for them to combine PGP + XMPP would be to encrypt and sign every message with the parties' static PGP keys. If you do that, you lose both the perfect forward secrecy and repudiability you get with OTR. [0] Those are important properties.
However, if they're planning to derive ephemeral keys for each conversation, as suggested by tptacek [1] and others, then things get more interesting.
OTR + Jabber still seems weak to me in two areas:
1. OTR's solution to the authentication problem is for the two parties to agree, out-of-band, on a shared secret [2]. I don't think normal users are going to do a good (secure) job of this. Key introduction through a web of trust, aka PGP, would make for a better and more secure user experience.
2. The reliance on a central server brokering messages is a problem. In fact the authentication in OTR version 1 was so broken that a jabber server plugin existed for MITM'ing OTR conversations [3]. Also, as another commenter points out, with a central server an agency might still be able to collect Verizon-style conversation metadata. I'd rather see something p2p along the lines of freenet or i2p.
Finally, I'm not sure what their plans are for hemlis, but there's no way I'd use a closed-source app for secure messaging. And I don't think it solves the world's problems -- we need to be able to trust this thing. That's the whole point.
[0] http://www.cypherpunks.ca/otr/otr-wpes.pdf http://www.cypherpunks.ca/otr/otr-wpes.pdf
[1] https://news.ycombinator.com/item?id=6004510 https://news.ycombinator.com/item?id=6004510
[2] http://www.cypherpunks.ca/~iang/pubs/impauth.pdf http://www.cypherpunks.ca/~iang/pubs/impauth.pdf
[3] http://www.ejabberd.im/mod_otr http://www.ejabberd.im/mod_otr
- mtgx 13y agoBut the channel has to be OpenSSL, right? Can't they at least enable forward secrecy in OpenSSL for the chat "sessions"?
- sigil 13y agoThey could, but with an OpenSSL channel comes SSL PKI, and CA certs we may not want to trust. It is possible to use OpenPGP certs with TLS, although I've never seen this done myself. http://tools.ietf.org/html/rfc6091 http://tools.ietf.org/html/rfc6091
- XorNot 13y agoIf the problem in OTR is we can't rely on users to verify who each other are, then any solution is going to inherit exactly the same problem because the only solution to it is external trusted parties. On top of that, PGP is exactly a step backwards if you're worried about just observation of metadata because PGP with web-of-trust cryptographically ties every message you send forever back to the key which sent it. OTR on the other hand treat the keys as inherently disposable and relies on the only correct verification protocol which is user knowledge of each other. You have to choose which problem you find more important: either you can be very anonymous, or very sure of who you're talking to but never both.
- sigil 13y ago> If the problem in OTR is we can't rely on users to verify who each other are... Not what I'm saying here. I think the specific way they've chosen to verify a new party in OTR -- by agreeing on a shared secret through some other channel -- is a bad user experience with security implications. Normal people will choose dumb, guessable secrets. Or send them over insecure channels. I think the equivalent of an in-person PGP key signing has a better chance of succeeding. If we're talking about an app, one person's phone could display a QR code of their pubkey, and the other could scan that in to import it. As with PGP, once the web of trust has a backbone (composed of hardcore early adopters like us here on HN), you can skip the in-person step, and trust keys that enough of your contacts trust. OTR doesn't have this network effect. > The only solution to it is external trusted parties. Sure. But who those external trusted parties are is the crux of the issue. Is it a browser maker and a couple companies you don't get to choose? Who are perhaps cooperating with some government (hey, it's happened)? Or is it people you actually choose and choose to trust? > On top of that, PGP is exactly a step backwards if you're worried about just observation of metadata because PGP with web-of-trust cryptographically ties every message you send forever back to the key which sent it. I mentioned this in the grandparent: with PGP, you could also derive ephemeral keys for the conversation, as OTR does. > You have to choose which problem you find more important: either you can be very anonymous, or very sure of who you're talking to but never both. Not so. You can both be anonymous from the man-in-the-middle's perspective, but can also verify each other. Look at how OTR does it. The "Socialist Millionaire's Protocol." http://en.wikipedia.org/wiki/Socialist_millionaire http://en.wikipedia.org/wiki/Socialist_millionaire