# Year of the OX

**XMPP-Meetup Berlin**, 10.2.2021, 18:00 CET
Online - https://meet.in-berlin.de/YearOfTheOX (Please don't post on public social media - *save us from jitsi bombing*)


## Topic: OpenPGP for XMPP (OX)

### Agenda

* 18:00 - Welcome chat
* 18:15 - Talk: OpenPGP for XMPP [[slides](https://jabber.fu-berlin.de/share/holger/KE7hVLNV1R4OR2xc/ox-intro.pdf)] (**Holger**)
* 18:30 - Panel: Introduction of panelists, comments and additions
* 18:45 - Panel: Initial questions
* 19:00 - Panel: Questions from the audience
* 19:30 - Open discussion

### Panelists

* **DebXWoody** - implementor of OX in Profanity
* **defanor** - implementor of OX in rexmpp
* **Florian** - co-author of the OX standards
* **lovetox** - implementor of OX for Gajim
* **Paul** - implementor of OX in Smack

## Questions

### Initial questions (moderator)

* Please introduce yourself and tell us about your relationship with XMPP.
* Do you have any comments or additions to Holger's talk?
* Why did you implement OX and what is your use case?
* What makes OX interesting for you compared to other encryption protocols, like [OMEMO](https://conversations.im/omemo/)?
* Do you have any security concerns related to this specification?

### Questions from the audience

* OX uses only one key pair per account not per device: Will it be easier to access old messages from archive on a new device? (debacle)
* Answer: Yes.
* In company context or similar, will a key escrow scheme is probably easier to implement than with OMEMO? (debacle)
* Answer: It is probably easy, esp. by just storing the primary key somewhere.
* Depending on implementation it might be possible to use a crypto token, such as Nitrokey or Yubikey? (debacle)
* Answer: Possible, _but_ very difficult for client design (lovetox), i.e. how should the client behave when the key is not available. Also not well usable with mobile phones (DebXWoody).
* With the evolution of computers, especially quantum computers these days, do you think OpenPGP and OX is the way to go and a solid solution for end-to-end encryption in the future? (Jeybe)
* if quantum computers become a thing, we have bigger problems -> rabbit hole
* quantum computing can solve specific currently unsolvable problems, but not all
* there is ongoing research for algorithms that are resistant to quantum computer attacks, also encryption algorithms based on quantum computing
* OpenPGP is agnostic to the algorithms it uses: new algorithms added to OpenPGP may mitigate the problem and can be added without reimplemeting everything
* both clients need to support the new algorithm
* elliptic curves are not resistant to quantum computing [wiki](https://en.wikipedia.org/wiki/Elliptic_curve_cryptography#Quantum_computing_attacks) [pdf](https://cryptome.org/2016/01/CNSA-Suite-and-Quantum-Computing-FAQ.pdf)
* potential (minimal) advantage of OX: symmetric encryption might be less affected by quantum computers; while OMEMO and asymmetric encryption is f** anyway
* What has to be done to implement group encryption? (marek)
* needs to be specified and implemented - ideally by the same person/group
* smaller group chats are easier to implement
* [MLS (message layer security) IETF standard](https://datatracker.ietf.org/wg/mls/about/) seems better for bigger group chats
* for bigger groups message encryption is most likely not as important as for smaller groups
* What is the primary goal of OX: To be an E2EE solution for those who prefer it for whatever reason (Nerds ;-)) or is the intention to actually bring OpenPGP for instant messaging to the masses? (Jeybe)
* Multiple goals: IoT as well as bridge between nerds and normal users
* Also: To be compatible to the different clients
* one fingerprint is an advantage over multiple - easier for the masses
* why divide the user base into nerds and normal users? You can use your own key if you want or a generated one if you don't care
* OX can be even easier than OMEMO for the user (in theory)
* OpenPGP/OX may be used in conjunction with OMEMO to enable easier fingerprint verification on the latter? -> See [Keyoxide](https://keyoxide.org/9f0048ac0b23301e1f77e994909f6bd6f80f485d), with which you can sign your JID and the corresponding OMEMO fingerprints (paul)
* Maybe OX can be used to sign public messages or posts in Movim or Libervia or other XMPP based social networks? (debacle)
* https://keyoxide.org/guides/xmpp
* Might be tricky (Flow), because of XML normalization or lack thereof. But there is a middle ground: if the use case is known, specify how the to-be-signed bytes are calculated
* If you know the structure of the data, you can know what parts to sign
* Many social networks are web-based so you basically have to trust the application server, too; so another option would be to leave the verfication up to the provider
* Anyone knows any good GPG Python libraries? (lovetox)
* https://sequoia-pgp.org/projects/
* GPGME has a Python binding
* Daniel, are you (already) considering to add OX to Conversations? (felix)
* Yes, but no high priority at the moment
* Autocrypt for lttrs is similar to OX - maybe it is going to be implemented as a library reusable for Conversations
* OX is not considered as a replacement for OMEMO but for [XEP-0027](https://xmpp.org/extensions/xep-0027.html)
* There is usage/need for forward secrecy
* OpenKeychain as a manager for keys might not be needed once Autocrypt is implemented (Daniel)
* centralized manager might be handy though
* PEP is like a Web Key Directory for uploading the keys (DebXwoody)
* If I understand OMEMO correctly, then the keys are changed whereas OpenPGP keys are static. So, it would be possible to keep OpenPGP keys in a TPM, but it is not possible to store OMEMO keys there. Is that correct? That seems like a significant security advantage (neal)
* OMEMO messages are en- and decrypted using the ratchet, which always changes. Identity key is not needed for every rachet move and *might* be placed in TPM, but not sure what that brings to the table - so OX is more suitable for TPM
* How can a normal user transfer a private (generated) key from one device (device lost or broken) to another device? (Holger)
* if PEP is used - key should not be stored there for a long time (DebXwoody)
* Either you trust or don't trust the backup password (Paul)
* Maybe ask the Delta Chat developers [how they do it](https://delta.chat/en/help#can-i-reuse-my-existing-private-key)

## Minutes

* 30 people (this is crazy!) :-)
* end-to-end-encryption (E2EE) is not a feature of "core" XMPP
* there were multiple attempts to add it as an extension (XMPP is all about extensions)
* modern: OMEMO, OX (our topic today)
* PGP is from the 90s
* used to be used extensively in e-mail communication
* sign and encrypt
* OMEMO is more modern, includes forward secrecy
* trade-off: usability vs secrecy
* legacy PGP doesn't do everything ~~you~~ Holger wants
* OX solves (many or all of) these problems
* key exchange via PEP (publish and subscribe technology in XMPP)
* encryption + signing
* operates on all kinds of XML elements
* mitigates replay attacks by using address/timestamp
* ...
* https://wiki.xmpp.org/web/XMPP_E2E_Security
* https://conversations.im/omemo
* DebXWoody: PGP has advantages over OMEMO; you don't have tons of keys all over the place; using a device like a Nitrokey, you can quickly and effortlessly encrypt everywhere in a secure manner
* defanor: (sorry, I had bad audio, add a sentence here...)
* Flow: there was a gap between E2E encryption with forward secrecy and "no encryption at all"
* old XEP horrible ;-)
* we need to raise the floor for end-to-end encryption
* (some) encryption is better than *no* encryption
* Paul: works on [Smack](https://github.com/igniterealtime/Smack)
* Google summer of code OMEMO + OX
* OX is like "the older brother" of OMEMO
* OMEMO vs OX
* Message history: with OMEMO it needs to be decrypted on the device, with PGP you can choose to have it either way
* OX allows for revocation
* OX allows for multiple algorithms
* the identity a key is assigned to can be within the key with OX
* lovetox: current maintainer of Gajim
* OX has full stanza encryption (we need that)
* full archive on the server is possible
* OX is more complex
* people bring their existing PGP keys, you need to "pick them up" somehow
* application (?!)...
* OX specification was build to serve many use cases
* not every possibility needs to be exposed to the user/application
* it is probably a good idea to make things (as) simple (as you can) for the user
* possible solution for applications (like Gajim): let the "pros" upload/insert their key into the application, otherwise just generate a key out of thin air
* keys can also be unencrypted PGP subkeys
* on a compromised machine the unencrypted PGP key is easy to be stolen - nothing new
* OpenPGP key ID cannot be extracted from an encrypted key
* [XEP 0373](https://xmpp.org/extensions/xep-0373.html#backup-encryption)
* if you use more than one key, you cannot distinguish them
* Why is the Symmetric Key Encrypted Session Key Packet to backup the secret key chosen over the OpenPGP packet specified for this purpose?
* More information about OX and further discussion in the XMPP wiki [tech page](https://wiki.xmpp.org/web/Tech_pages/OX)
* There's also a [XEP remarks page](https://wiki.xmpp.org/web/XEP-Remarks/XEP-0373:_OpenPGP_for_XMPP)
* Flow: Experiences from implementation should flow back into the specifications. This is currently a problem with the XMPP community

In other news
* cognitive project about communication with services to get answers to a search term. Answers might take a long time. (eevvoor)