5 ms·

OX (OpenPGP for XMPP): A New OpenPGP XEP

58 points by Flowdalic 11y ago

mkj 11y ago
Why would someone use this rather than OTR? (http://wiki.xmpp.org/web/OTR http://wiki.xmpp.org/web/OTR)
- Flowdalic 11y ago
  OTR [1], Axolotl [2] and OMEMO [3] all provide Perfect Forward Secrecy, which in turn means that you can't (or should not be able to) read your archived messages. And with OTR can't send messages to offline contacts. OpenPGP does not provide this property, which allows you to read your encrypted messages in the archive as long as you have access to your OpenPGP secret key and it allows you to send messages to offline contacts. 1: https://otr.cypherpunks.ca/ https://otr.cypherpunks.ca/ 2: https://github.com/WhisperSystems/Signal-Android/wiki/ProtocolV2 https://github.com/WhisperSystems/Signal-Android/wiki/Protoc... 3: http://conversations.im/omemo/ http://conversations.im/omemo/
  - mkj 11y ago
    If you're archiving at all then OTR won't encrypt them - it's not going to archive the ciphertext. I guess offline contacts is a use case against OTR, though whisper's certainly has that sorted out already. https://whispersystems.org/blog/advanced-ratcheting/ https://whispersystems.org/blog/advanced-ratcheting/
    - daturkel 11y ago
      Yeah I've never seen an implementation of OTR that blocked archival—in the journalistic sense, it's still on the record so to speak. (That being said, OTR's deniable authentication means I can use my plaintext archive to recall the conversation but I can't prove to a third party that it's from who I say it was—nor would I be able to if I was storing the encrypted conversation.) With the above considered, I'm curious to hear another argument for OpenPGP over XMPP rather than OTR. (Edit: Should say that there likely are OTR implementations that archive the ciphertext, or don't automatically archive at all. However, having used OTR in Jitsi and Adium, both I believe keep regular old plaintext logs.)
      - iheartmemcache 11y ago
        Even if it was blocked by the implementation, the second it hits your local machine is the second an end-user can capture it (either by recompiling the plugin, the base software, hooking DLLs, accessing the heap directly, with screenshots or even with a Polaroid). The only advantage of OpenPGP/GnuPG over XMPP I can think of is it supports multiple end-users via merged groups out of the box. With OTR it's harder to logistically organize multi-session key-sharing. And if one of your machines is compromised, you can do a PKI revoke via CRL (or whatever it's called in GPG, slipping my mind at the moment).
  - anc84 11y ago
    OMEMO lists offline delivery as a key feature. I would have been shocked if it did not support it because that would be a "useless and dead in the water" blocker for new technology in our mobile world.
    - Flowdalic 11y ago
      Right, shouldn't have thrown them all together. Corrected the comment.
  - infinity0 11y ago
    This is a bad security argument. With OTR / FS in general, you can re-encrypt the plaintext using a different local-only key after decrypting the forward-secure ciphertext. Then, the ciphertext that was sent over the wire is still forward-secure, and your adversary must seize your computer in order to try to decrypt the re-encrypted non-FS ciphertext you use for logs/archiving. There really is no reason to use non-FS encryption over FS encryption for ciphertext sent over the wire.
    - ultramancool 11y ago
      Yeah, what I always did was keep the logs on an encrypted file system... it's not like you're going to pcap your traffic to store your chat logs.
- ycmbntrthrwaway 11y ago
  One reason is that OpenPGP is already widespread and you may use known OpenPGP key to establish shared secret and switch to OTR then. Another reason is that OTR is not multi-party. mpOTR [1] was suggested by OTR authors (Ian Goldberg et al.), but I am not sure you can find at least one peer who has it installed, and it is not maintained. So for XMPP conferences you may still want to go with OpenPGP. [1] https://dx.doi.org/10.1145%2F1653662.1653705 https://dx.doi.org/10.1145%2F1653662.1653705
- lmm 11y ago
  Sometimes you want non-repudiable messaging.
daenney 11y ago
Though I understand why this is done and I'm glad there's a XEP now that's not broken like the previous one I'm not sure OpenPGP is viable. It might work for tech savvy users but frankly I don't think most people have it in them to correctly and securely manage the lifecycle (creation, access, storage, usage) of a key.
- daturkel 11y ago
  An implementation that hides key management from the user (or abstracts it in someway—I guess you still do want longterm, but revokable, key use) could be nice, but then you get closer and closer to mimicking what OTR does. That being said, hard to complain that such a thing exists as an option for those that want it (especially when those seeking it might come across the pre-existing, problematic standard).
legulere 11y ago
I think it's too late for it and this wouldn't solve that many problems: - public xmpp servers are shutting down one after the other - xmpp ties your identity to the server you register with, when there's technology to tie your identity to a cryptographic hash (you can use DHT to find people) - servers are not optional in xmpp, when in reality most of the time when you message people they're also online, so peer2peer would be fine there (especially for server outages like the server I used frequently had) - One usecase where you need servers is to save power on mobile devices. XMPP doesn't support push notification - end-to-end encryption is an total afterthought in xmpp - basic things like sending pictures, voice or videochat never work - xmpp is an laughably over complex standard created by a committee - pgp is totally unusable for normal users
- cos2pi 11y ago
  Given these points, what protocol(s) do you think is the best candidate for development?
- daturkel 11y ago
  Thanks for sharing. There are some good arguments here,* particularly re: servers holding your registration info and some of the downsides of requiring servers for xmpp (though it also has some advantages—it's nice to be able to message someone not online). *though I'm always a little anti-"pgp can't be used by normal users." If the situation requires the security that PGP provides, users can frequently be made to learn. (That being said, Glenn Greenwald couldn't be bothered to set up PGP to talk to Snowden until someone got him up to speed. [0]) [0]: https://theintercept.com/2014/10/28/smuggling-snowden-secrets/ https://theintercept.com/2014/10/28/smuggling-snowden-secret...
  - legulere 11y ago
    > though it also has some advantages—it's nice to be able to message someone not online Just because you don't require servers, doesn't mean that you can't have servers optionally as a relay. Your client tell would tell the clients of your contacts to send messages to a server specified by you when they can't reach you directly. For instance the server could be run by the company behind the messaging app you're using and could send you push notifications. You could still switch the server at will without loosing your identity.
snorge 11y ago
Does anyone have experience with Matrix? [0] I haven't tried it yet but the site looks interesting. 0: http://matrix.org/ http://matrix.org/
- heavenlyhash 11y ago
  Works great. Definitely check it out. (I found Matrix after trying to write an XMPP client and becoming a giggly/teary-eyed wreck trying to parse out how many incomplete extensions I would have to implement to get multi-device working. Previously: [1]) I now use matrix daily from all of my devices, mobile and desktop alike. They're also working on an Axolotl rachet implementation: https://matrix.org/git/olm/ https://matrix.org/git/olm/ It's not integrated yet, sadly, but I'm eagerly awaiting seeing it jump in as a first-class supported feature. --- [1]: https://news.ycombinator.com/item?id=9772968 https://news.ycombinator.com/item?id=9772968
  - iheartmemcache 11y ago
    I'm conflicted on Axolotl. For every layer of security you add, you increase the odds of someone doing something careless (this[1] is way more common than you'd think). Key-leak healing is an interesting function out-of-the-box, but if your priv key gets uploaded accidentally, odds are so did your DH Identity/Ratchet/Chain keys as well, effectively rendering you "fully compromised". It only offers protection in an instance where you keep your keys compartmentalized. Is there a general consensus within the crypto community as to whether a) this is conceptually sound, and b) if there's an audited implementation? It's so so easy to mess up and have that error be overlooked (i.e. the OpenSSL debacle), which makes me want to just stick with the tried and true GPG DH/ELG setup with PKI and revocation. Definitely a real interesting project to watch and a real interesting take on perfect-forward secrecy though! Thanks for your feedback. If you see this, read my other post in this thread and e-mail me, I'd love your feedback. [1]http://rdist.root.org/2008/02/05/tlsssl-predictable-iv-flaw/ http://rdist.root.org/2008/02/05/tlsssl-predictable-iv-flaw/
erikb 11y ago
Wasn't XMPP already encryptet? A friend always tried to convince me to switch from IRC to XMPP because XMPP can be encrypted. Is that incorrect?
- raimue 11y ago
  XMPP does not inherently support end-to-end encryption. He was probably referring to the transport security, from client to server. This is achieved by securing the connection with SSL/TLS. Most often, IRC does not even support that, although some IRC networks also allow clients to connect with SSL/TLS. This transport security from your client to the server only secures the first hop. It does not prevent eavesdropping on server-to-server connections, or on the connection of the receiving user if they do not also use SSL/TLS.

58 points by Flowdalic 11y ago

mkj 11y ago

Why would someone use this rather than OTR? (http://wiki.xmpp.org/web/OTR http://wiki.xmpp.org/web/OTR)

Flowdalic 11y ago
OTR [1], Axolotl [2] and OMEMO [3] all provide Perfect Forward Secrecy, which in turn means that you can't (or should not be able to) read your archived messages. And with OTR can't send messages to offline contacts. OpenPGP does not provide this property, which allows you to read your encrypted messages in the archive as long as you have access to your OpenPGP secret key and it allows you to send messages to offline contacts. 1: https://otr.cypherpunks.ca/ https://otr.cypherpunks.ca/ 2: https://github.com/WhisperSystems/Signal-Android/wiki/ProtocolV2 https://github.com/WhisperSystems/Signal-Android/wiki/Protoc... 3: http://conversations.im/omemo/ http://conversations.im/omemo/
- mkj 11y ago
  If you're archiving at all then OTR won't encrypt them - it's not going to archive the ciphertext. I guess offline contacts is a use case against OTR, though whisper's certainly has that sorted out already. https://whispersystems.org/blog/advanced-ratcheting/ https://whispersystems.org/blog/advanced-ratcheting/
  - daturkel 11y ago
    Yeah I've never seen an implementation of OTR that blocked archival—in the journalistic sense, it's still on the record so to speak. (That being said, OTR's deniable authentication means I can use my plaintext archive to recall the conversation but I can't prove to a third party that it's from who I say it was—nor would I be able to if I was storing the encrypted conversation.) With the above considered, I'm curious to hear another argument for OpenPGP over XMPP rather than OTR. (Edit: Should say that there likely are OTR implementations that archive the ciphertext, or don't automatically archive at all. However, having used OTR in Jitsi and Adium, both I believe keep regular old plaintext logs.)
    - iheartmemcache 11y ago
      Even if it was blocked by the implementation, the second it hits your local machine is the second an end-user can capture it (either by recompiling the plugin, the base software, hooking DLLs, accessing the heap directly, with screenshots or even with a Polaroid). The only advantage of OpenPGP/GnuPG over XMPP I can think of is it supports multiple end-users via merged groups out of the box. With OTR it's harder to logistically organize multi-session key-sharing. And if one of your machines is compromised, you can do a PKI revoke via CRL (or whatever it's called in GPG, slipping my mind at the moment).
- anc84 11y ago
  OMEMO lists offline delivery as a key feature. I would have been shocked if it did not support it because that would be a "useless and dead in the water" blocker for new technology in our mobile world.
  - Flowdalic 11y ago
    Right, shouldn't have thrown them all together. Corrected the comment.
- infinity0 11y ago
  This is a bad security argument. With OTR / FS in general, you can re-encrypt the plaintext using a different local-only key after decrypting the forward-secure ciphertext. Then, the ciphertext that was sent over the wire is still forward-secure, and your adversary must seize your computer in order to try to decrypt the re-encrypted non-FS ciphertext you use for logs/archiving. There really is no reason to use non-FS encryption over FS encryption for ciphertext sent over the wire.
  - ultramancool 11y ago
    Yeah, what I always did was keep the logs on an encrypted file system... it's not like you're going to pcap your traffic to store your chat logs.
ycmbntrthrwaway 11y ago
One reason is that OpenPGP is already widespread and you may use known OpenPGP key to establish shared secret and switch to OTR then. Another reason is that OTR is not multi-party. mpOTR [1] was suggested by OTR authors (Ian Goldberg et al.), but I am not sure you can find at least one peer who has it installed, and it is not maintained. So for XMPP conferences you may still want to go with OpenPGP. [1] https://dx.doi.org/10.1145%2F1653662.1653705 https://dx.doi.org/10.1145%2F1653662.1653705
lmm 11y ago
Sometimes you want non-repudiable messaging.

daenney 11y ago

Though I understand why this is done and I'm glad there's a XEP now that's not broken like the previous one I'm not sure OpenPGP is viable. It might work for tech savvy users but frankly I don't think most people have it in them to correctly and securely manage the lifecycle (creation, access, storage, usage) of a key.

daturkel 11y ago
An implementation that hides key management from the user (or abstracts it in someway—I guess you still do want longterm, but revokable, key use) could be nice, but then you get closer and closer to mimicking what OTR does. That being said, hard to complain that such a thing exists as an option for those that want it (especially when those seeking it might come across the pre-existing, problematic standard).

legulere 11y ago

I think it's too late for it and this wouldn't solve that many problems: - public xmpp servers are shutting down one after the other - xmpp ties your identity to the server you register with, when there's technology to tie your identity to a cryptographic hash (you can use DHT to find people) - servers are not optional in xmpp, when in reality most of the time when you message people they're also online, so peer2peer would be fine there (especially for server outages like the server I used frequently had) - One usecase where you need servers is to save power on mobile devices. XMPP doesn't support push notification - end-to-end encryption is an total afterthought in xmpp - basic things like sending pictures, voice or videochat never work - xmpp is an laughably over complex standard created by a committee - pgp is totally unusable for normal users

cos2pi 11y ago
Given these points, what protocol(s) do you think is the best candidate for development?
daturkel 11y ago
Thanks for sharing. There are some good arguments here,* particularly re: servers holding your registration info and some of the downsides of requiring servers for xmpp (though it also has some advantages—it's nice to be able to message someone not online). *though I'm always a little anti-"pgp can't be used by normal users." If the situation requires the security that PGP provides, users can frequently be made to learn. (That being said, Glenn Greenwald couldn't be bothered to set up PGP to talk to Snowden until someone got him up to speed. [0]) [0]: https://theintercept.com/2014/10/28/smuggling-snowden-secrets/ https://theintercept.com/2014/10/28/smuggling-snowden-secret...
- legulere 11y ago
  > though it also has some advantages—it's nice to be able to message someone not online Just because you don't require servers, doesn't mean that you can't have servers optionally as a relay. Your client tell would tell the clients of your contacts to send messages to a server specified by you when they can't reach you directly. For instance the server could be run by the company behind the messaging app you're using and could send you push notifications. You could still switch the server at will without loosing your identity.

snorge 11y ago

Does anyone have experience with Matrix? [0] I haven't tried it yet but the site looks interesting. 0: http://matrix.org/ http://matrix.org/

heavenlyhash 11y ago
Works great. Definitely check it out. (I found Matrix after trying to write an XMPP client and becoming a giggly/teary-eyed wreck trying to parse out how many incomplete extensions I would have to implement to get multi-device working. Previously: [1]) I now use matrix daily from all of my devices, mobile and desktop alike. They're also working on an Axolotl rachet implementation: https://matrix.org/git/olm/ https://matrix.org/git/olm/ It's not integrated yet, sadly, but I'm eagerly awaiting seeing it jump in as a first-class supported feature. --- [1]: https://news.ycombinator.com/item?id=9772968 https://news.ycombinator.com/item?id=9772968
- iheartmemcache 11y ago
  I'm conflicted on Axolotl. For every layer of security you add, you increase the odds of someone doing something careless (this[1] is way more common than you'd think). Key-leak healing is an interesting function out-of-the-box, but if your priv key gets uploaded accidentally, odds are so did your DH Identity/Ratchet/Chain keys as well, effectively rendering you "fully compromised". It only offers protection in an instance where you keep your keys compartmentalized. Is there a general consensus within the crypto community as to whether a) this is conceptually sound, and b) if there's an audited implementation? It's so so easy to mess up and have that error be overlooked (i.e. the OpenSSL debacle), which makes me want to just stick with the tried and true GPG DH/ELG setup with PKI and revocation. Definitely a real interesting project to watch and a real interesting take on perfect-forward secrecy though! Thanks for your feedback. If you see this, read my other post in this thread and e-mail me, I'd love your feedback. [1]http://rdist.root.org/2008/02/05/tlsssl-predictable-iv-flaw/ http://rdist.root.org/2008/02/05/tlsssl-predictable-iv-flaw/

erikb 11y ago

Wasn't XMPP already encryptet? A friend always tried to convince me to switch from IRC to XMPP because XMPP can be encrypted. Is that incorrect?

raimue 11y ago
XMPP does not inherently support end-to-end encryption. He was probably referring to the transport security, from client to server. This is achieved by securing the connection with SSL/TLS. Most often, IRC does not even support that, although some IRC networks also allow clients to connect with SSL/TLS. This transport security from your client to the server only secures the first hop. It does not prevent eavesdropping on server-to-server connections, or on the connection of the receiving user if they do not also use SSL/TLS.