
OX (OpenPGP for XMPP): A New OpenPGP XEP - Flowdalic
http://mail.jabber.org/pipermail/standards/2016-January/030755.html
======
legulere
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

~~~
daturkel
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-
secret...](https://theintercept.com/2014/10/28/smuggling-snowden-secrets/)

~~~
legulere
> 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.

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

~~~
Flowdalic
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/Protoc...](https://github.com/WhisperSystems/Signal-
Android/wiki/ProtocolV2) 3:
[http://conversations.im/omemo/](http://conversations.im/omemo/)

~~~
infinity0
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
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.

------
snorge
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
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
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/)

------
daenney
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
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).

------
erikb
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
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.

