Year of the OX

# 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*) ![Buffalo Bull Ruminant](https://cdn.pixabay.com/photo/2021/01/11/17/55/buffalo-5909134_1280.png) ## 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)

Example	Syntax
Header	# Header
Unordered List	- Unordered List
Ordered List	1. Ordered List
Todo List	- [ ] Todo List
Blockquote	> Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th	19^th^
H₂O	H~2~O
Inserted text	++Inserted text++
Marked text	==Marked text==
Link	[link text](https:// "title")
Image	![image alt](https:// "title")
`Code`	`Code`
`var i = 0;`	```javascript var i = 0; ```
	:smile:
Externals	{%youtube youtube_id %}
L^aT_eX	$L^aT_eX$
This is a alert area.	:::info This is a alert area. :::