Unified Encrypted Payload Elements for XMPP

Requirements on encryption change from time to time. New technologies pop up and crypto protocols get replaced by new ones. There are also different use-cases that require different encryption techniques.

For that reason there is a number of encryption protocols specified for XMPP, amongst them OMEMO and OpenPGP for XMPP.

Most crypto protocols share in common, that they all aim at encrypting certain parts of the message that is being sent, so that only the recipient(s) can read the encrypted content.

OMEMO is currently only capable to encrypt the messages body. For that reason the body of the message is being encrypted and stored in a <payload/> element, which is added to the message. This is inconvenient, as it makes OMEMO quite inflexible. The protocol cannot be used to secure arbitrary extension elements, which might contain sensitive content as well.

<message to='juliet@capulet.lit' from='romeo@montague.lit' id='send1'>
  <encrypted xmlns='eu.siacs.conversations.axolotl'>
    <header>...</header>
    <!-- the payload contains the encrypted content of the body -->
    <payload>BASE64ENCODED</payload>
  </encrypted>
</message>

The modern OpenPGP for XMPP XEP also uses <payload/> elements, but to transport arbitrary extension elements. The difference is, that in OpenPGP, the payload elements contain the actual payload as plaintext. Those <payload/> elements are embedded in either a <crypt/> or <signcrypt/> element, depending on whether or not the message will be signed and then passed through OpenPGP encryption. The resulting ciphertext is then appended to the message element in form of a <openpgp/> element.

<signcrypt xmlns='urn:xmpp:openpgp:0'>
  <to jid='juliet@example.org'/>
  <time stamp='...'/>
  <rpad>...</rpad>
  <payload>
    <body xmlns='jabber:client'>
      This is a secret message.
    </body>
  </payload>
</signcrypt>

<!-- The above element is passed to OpenPGP and the resulting ciphertext is included in the actual message as an <openpgp/> element -->

<message to='juliet@example.org'>
  <openpgp xmlns='urn:xmpp:openpgp:0'>
    BASE64_OPENPGP_MESSAGE
  </openpgp>
</message>

Upon receiving a message containing an <openpgp/> element, the receiver decrypts the content of it, does some verity checks and then replaces the <openpgp/> element of the message with the extension elements contained in the <payload/> element. That way the original, unencrypted message is constructed.

The benefit of this technique is that the <payload/> element can in fact contain any number of arbitrary extension elements. This makes OpenPGP for XMPPs take on encrypting message content way more flexible.

A logical next step would be to take OpenPGP for XMPPs <payload/> elements and move them to a new XEP, which specifies their use in a unified way. This can then be used by OMEMO and any other encryption protocol as well.

The motivation behind this is, that it would broaden the scope of encryption to cover more parts of the message, like read markers and other metadata.

It could also become easier to implement end-to-end encryption in other scenarios such as Jingle file transfer. Even though there is Jingle Encrypted Transports, this protocol only protects the stream itself and leaves the metadata such as filename, size etc. in the clear. A unified <encrypted/> element would make it easier to encrypt such metadata and could be the better approach to the problem.

Join the Fediverse!

Federated Networks are AWESOME! When I first learned about the concept of federation when I started using Jabber/XMPP, I was blown away. I could set up my own private chat server on a Raspberry Pi and still be able to communicate with people from the internet. I did not rely on external service providers and instead could run my service on my own hardware.

About a year ago or so I learned about ActivityPub, another federated protocol, which allows users to share their thoughts, post links, videos and other content. Mastodon is probably the most prominent service that uses ActivityPub to create a Twitter-like microblogging platform.

But there are other examples like PeerTube, a YouTube-like video platform which allows users to upload, view and share videos with each other. Pleroma allows users to create longer posts than Mastodon and Plume can be used to create whole blogs. PixelFed aims to recreate the Instagram experience and Prismo is a federated Reddit alternative.

But the best thing about ActivityPub: All those services federate not only per service, but only across each other. For instance, you can follow PeerTube creators from your Mastodon account!

And now the icing on the cake: You can now also follow this particular blog! It is traveling the fediverse under the handle @vanitasvitae@blog.jabberhead.tk

Matthias Pfefferle wrote a WordPress plugin, that teaches your WordPress blog to talk to other services using the ActivityPub protocol. That makes all my blog posts available in and a part of the fediverse. You can even comment on the posts from within Mastodon for example!

In my opinion, the internet is too heavily depending on centralized services. Having decentralized services that are united in federation is an awesome way to take back control.

Kuketz Blog about Blokada

Just a quick hint: Mike Kuketz released a blog post about how you can use Blokada to block ads and trackers on your android device. In his post, he explains how Blokada uses a private VPN to block DNS requests to known tracker/ad sites and recommends a set of rules to configure the app for best experience.

He also briefly mentions F-Droid and gives some arguments, why you should get your apps from there instead of the Play Store.

The blog post is written in German and is available on kuketz-blog.de.

On Independent Journalism

Greyscale image of newspapers on a stand.
Photo by Flipboard on Unsplash

I live in a fast-paced world. News from all over the planet reach me within minutes, even seconds. This creates a huge, violent stream of information, trying to get into my mind.

Meanwhile I have less and less time on my hands and can only hastily process all the information I consume. Too often I catch myself quickly scrolling through the news feed, only reading the headlines of articles, the excerpt at best.

I have to admit it: I depend on the news articles I read to be truthful, as I don’t have time to verify them on my own. I am at the mercy of journalists to tell me the stories the way they really happened.

At the same time journalists desperately try to get me to read their articles. They have to get clicks on their websites in order to survive, as printed newspapers are slowly dying.

As a result my news feed is flooded with sensational headlines and click-bait articles. Scandals are made to appear bigger than they really are or simply made up from thin air. Often the title of an article contradicts the content itself or is massively exaggerated.

Recent examples of this trend are the allegations around the YouTube creator PewDiePie, who is regularly accused by several news outlets to be a white supremacist, which – if you know his videos and understand his type of humor – is just absurd. Sure, there are some edgy jokes here and there, but they are exactly this: Jokes and satire. Any viewer knows and understands this.

I really hate the term fake news, as it’s often used as a lazy excuse to ignore inconvenient facts, but reading bad researched articles like those around PewDiePie make me question the credibility of some news organizations and it makes me sad to see, how shortsighted some trade away credibility for clicks.

Another example would be the case of Class Relotius, a journalist who wrote for Der Spiegel, a prominent German newspaper. Relotius deliberately made up a number of articles. This massively hurts the trustworthiness of the press, even though I think (and hope) that Der Spiegel itself is an otherwise reliable newspaper.

As I wrote earlier, I want to be able to depend and rely on the news.
I don’t want to live in a world where people screaming “Fake News” are those who speak the truth.

So what solutions are there to fix these issues?

Journalism needs financing.
Most sites greet you with popups that demand you to disable your ad-blocker to read their articles. I know that this is not an option for me.

Blocking advertisements is not – as often depicted by the advertising industry – simply a way to make my life more comfortable, it is actually a security measurement. Ads spy on the user and can even be used to execute malicious code. As a proponent of the free software movement I believe that its my right to decide which software is run on my machines. Therefore I am persuaded that it’s my right to decide to disable ads.

In Germany we have the “Rundfunkbeitrag”, a model for financing public service broadcasters in Germany. Some people say that it is unfair to be forced to pay for something that you don’t necessarily consume. While I see their point (some people don’t own a TV or radio, why should they pay?), I think that it is more important to have independent journalism. In the end that’s the whole reason behind this blog post.

I am not sure if subscribing to a news outlet in order to be able to read their articles is the right way to solve the issue. Sure, this is the way it has been in times prior to the internet (you bought the news paper), but things changed. My biggest issue with the subscription model is that I could only subscribe to a limited number of news sites at once. That however makes me dependent on those sources. If I’d want to read an article of another site I’d need to pay for that again.

One approach would be a unified subscription which would give you access to a variety of news sites. That way I wouldn’t be bound to a single source and the fee would ensure the editorial independence of the journalists. This idea is however not yet well thought out.

Maybe we need a Rundfunkbeitrag for newspapers. In the end the only difference between news on TV and newspapers is the medium that transports the content. Both are however created by journalists that are in need of financing to stay independent.

In the meantime I will consider, whether I can afford to subscribe to a news site and if so, which would be the right choice for me. Possible candidates are Der Spiegel (yes, I’d give them another chance and yes, no https :/) and Netzpolitik.org who solely rely on donations at the moment.

Setting up a Planet

Planets are a thing of the 90s, but still they are quite cool as they can bring a community closer together by helping users to exchange ideas. I hope this will also work out for the F-Droid community 🙂

For that reason I proposed to set up a planet for F-Droid / FOSS Android development in the F-Droid forum. After explaining my idea, Hans suggested that I should give it a try and go serverless by basing the setup on GitLab Pages.

Up to that point I didn’t even know, that GitLab Pages was a thing, as I only ever came in touch with Github Pages (shame on me). However, setting everything up was pretty straight forward and I’m quite happy with the outcome.

I chose the planet software Venus for the job, as it was one of the only search results I found while researching the topic. It was also the one used by some planets I already personally followed. Venus is a python program, which fetches the list of registered blogs and creates a directory with static HTML/CSS files which contain all the blog posts. That HTML can then be deployed somewhere (in our case GitLab Pages).

I configured GitLab CI to run Venus every 30 minutes. I might increase the interval at some point, as 30 minutes might be overkill.

Screenshot of the Planet F-Droid website
Screenshot Planet F-Droid

Design-wise I tried to mimic the style of the F-Droid website as close as possible, but I’m not a web designer and haven’t got in touch with HTML + CSS so far, so there are still a lot of things that can be improved. However, it was a lot of fun to experiment and do trial and error to come up with the current design. If you want to jump in and help me with the CSS/HTML, feel free to contact me!

The only thing missing now are blogs! If you run a cool FOSS, Android development related project and/or blog about your adventures in the FOSS world, please apply to be included 🙂

For now the planet can be found here, but I hope that it can at some point migrate to a F-Droid subdomain.

I hate paperwork. That’s why I love Paperwork!

Until very recently, my handling of paperwork was rather poorly. I keep all my letters and invoices in a big binder. Unfortunately at some point that binder got unsorted and I lost all motivation to sort new letters into it, so I started to insert fresh letters randomly. Eventually I lost even more motivation and began to just toss new letters into the compartment where I store the binder. It’s a big mess.

Then I discovered paperwork.

Paperwork – Image taken from https://openpaper.work

Paperwork massively simplifies the management of letters and other documents. Whenever I receive a new letter, I put it on my scanner, start paperwork and digitalize it. Paperwork automatically optimizes the scanned image and runs some OCR on it. All I have to type in manually, is the date of the letter. Paperwork automatically tries to detect the sender and tags the document based on that. All letters from my bank are labeled accordingly, while letters from my power company are given another label.

At first I missed the feature to create separate collections for different types of letters, but I quickly realized, that paperwork’s approach to order letters just by date and tags is way superior. Just scan, enter a date and you are done.

If I need a certain document, I can (thanks to OCR) do a full text search. Yay!

Unfortunately there are some bugs. When I move my mouse over some documents, the image viewer gets plain white with some massive letters on it. I suspect its a bug in the OCR display. However, I can work around that by literally just moving my mouse around the document 😀
Also, sometimes all my documents disappear from the overview, but a quick restart brings them back.

I’m so glad that I found paperwork. Finally I can get rid of a lot of useless letters 🙂 Now I’d like to know: How are you digitalizing your documents?

Happy Hacking!

QR-Code Generator for OMEMO

OMEMO is, like any other encryption protocol based on trust. The user has to make sure, that the keys they are trusting belong to the right users. Otherwise a so called Man-in-the-Middle attack is possible. An attacker might pretend to be your contact and secretly steal all the messages you thought were encrypted. They are, just to the wrong recipient.

To counteract such attacks, OMEMO encourages the user to verify their contacts fingerprints. A fingerprint can be considered the name of a contacts key. The user has to make sure, that the key A he is presented with really belongs to contact C by checking, if the fingerprints match. As those fingerprints are usually long, random series of characters, this is a tedious task. Luckily there are techniques like QR codes, which make our lifes easier. Instead of comparing two long strings character by character, you just scan a code and are done.

The QR-Code contains the Jabber-ID of the owner, as well as all of their fingerprints. So by scanning your code, a friend might automatically add you to their contact list and mark your devices as trusted. You can also put the QR-Code on your personal website, so people who want to reach out to you can easily establish a secure connection to you.

I spent the last few days looking into JavaFX (I have no real UI designing experience in Java, apart from Android), designing a small tool that can generate OMEMO fingerprint QR-Codes. This is what I came up with:

QR-Code generator with selectable fingerprints

The tool logs into your XMPP account and fetches all your published keys. Then it presents you with a list in which you can select, which fingerprints you want to include in the QR-Code.

There are still a lot of features missing and I consider the tool in no means as completed. My plans are to add the possibility to export QR-Codes to file, as well as to copy the text content of the code to clipboard. You see, there is a lot of work left to do, however I wanted to share my thoughts with you, so maybe client developers can adopt my idea.

Future of OMEMO

OMEMO is an XMPP extension protocol, which specifies end-to-end encryption for XMPP clients using the double ratchet algorithm of the Signal protocol. Introduced back in 2015 by GSoC student Andreas Straub in the Conversations client, OMEMO had a lot of press coverage and many privacy and security oriented websites praise XMPP clients that do support it. Its beyond debate, that OMEMO brought many new faces to XMPP. For many users, having end-to-end encryption built into their chat client is a must. Today OMEMO is implemented in a range of clients on different platforms. While Conversations, ChatSecure and Dino support it out of the box, there is a series of plugins that teach OMEMO to other clients such as Gajim, Pidgin and Miranda NG.

However, there is quite a lot of controversy around OMEMO. Part of it are technical discussions, others are more or less of a political nature. Let me list some of them for you.

Some users and client developers see no value in OMEMOs forward secrecy (the fact, that messages can only be decrypted once per device, so new devices do not have access to the chat history of the user). That is a fair point. Especially webclients have a hard time implementing OMEMO in a sensible way. Also the average user is probably having a hard time understanding what exactly forward secrecy is and what the consequences are. Communicating to the user, that not having access to past messages is actually a feature might be a hard task for a client developer.

OMEMOs trust management (still) sucks. One architectural key feature of OMEMO is, that every device does have its own identity key. If a user wants to send a message to one of their contacts, they’re presented with a list of all of their identity keys. Now they have to decide, which keys to trust and which not by comparing fingerprints (seamingly arbitrary strings of 64 characters). This is not a very comfortable thing to do. Some clients encourage the user to verify your contacts devices by scanning QR-Codes, which is way more comfortable, users do however have to meet up in person or share the QR code on another channel.
But what if you get a new device or just reinstall your chat application? Suddenly all your contacts have to decide whether to trust your new fingerprint or not. In the long run this will lead to the user just being annoyed and blindly accepting new fingerprints, ruining the concept of end-to-end encryption.

Daniel Gultsch introduced the concept of BTBV (Blind Trust Before Verification) which can be summed up as “do not bother the user with encryption and hope everything goes well until the user explicitly states that they are interested in having good security”. The principle is, that clients blindly trust any OMEMO identity keys until the user commits to verifying them manually. This makes OMEMO easy to use for those who don’t really care about it, while offering serious users who depend on it the needed security.

But what do you do, if suddenly a rogue fingerprint appears? Do you panic and message all your contacts not to trust the stranger key? In theory any device which has access to the users account (the users server too) can just add another OMEMO identity key to the users list of devices and there is not really anything the user can do about it. OMEMO does not have a “blacklist”-feature or a signed list of trusted keys. It would however be possible to implement such thing in the future by combining OMEMO with OpenPGP for example. Of course, if some stranger has access to your account, it is time to change the password/server anyways.

Another weakness of OMEMO is, that it is currently only usable for encrypting the messages body. Since XMPP is an extensible protocol with other use cases than messaging, it would be nice to have support for arbitrary extension element encryption. There is however the extension protocol “OX” (XEP-0373: OpenPGP for XMPP), which has such capabilities. This feature can be extracted from OX and reused in OMEMO relatively easy.

Lets now focus on the “political” controversies around OMEMO.

In 2016/2017 there has been a lot of discussions, whether or not OMEMO should become a standard in the first place. The problem is, that in it’s current form (which has not really changes since its introduction), OMEMO depends on the wire format used by libsignal (the Signal protocol library used by conversations). That library however is licensed under the GPLv3 license, preventing permissively licensed and closed source applications from implementing OMEMO. While the Signal protocol itself is openly documented, the wire format used by libsignal is not, so any implementations which want to be compatible to current OMEMO clients must implement the same wire format by looking into the libsignal source code, which in turn makes the implementation a derivative of libsignal, which must be licensed under the GPL as well. There has been a pull request against the OMEMO XEP which addressed this issue by specifying an independent wire format for OMEMO, however that pull request was more or less rejected due to inactivity of the author.

During the phases of hot debates around OMEMO, it was discussed to base the protocol on Olm instead of the Signal protocol. Olm is the encryption protocol used by matrix.org. However, up to this point there is no Olm based OMEMO implementation, that I know of, neither have there been any experiments in that direction from people that proposed the idea (again – not that I know of).

Another idea was to completely redesign OMEMOs double ratchet specification as OMEMO-NEXT from ground up without even mentioning a specific library as the foundation. This would obviously be a way more complex XEP, as all the cryptographic operations and primitives which are currently abstracted and hidden away behind the Signal protocol, would have to be written down in that XEP. However, recently the IETF announced that work is done to create MLS (Message Layer Security), which does exactly that. It specifies a completely open version of the double ratchet algorithm along with infrastructure to share key material and so on. I’m not sure whether this is a coincidence, or if some of those who proposed OMEMO-NEXT are directly involved with the development of MLS. We’ll see, when MLS is ready and whether it will compete against OMEMO. I’d really love to see a cross-protocol encryption algorithm btw 😉 #bridges #federateEverything

Now lets talk about the biggest problem of OMEMO. Currently the XEP does not have an active “legal guardian”. The author has been inactive for an extended period of time, ignoring requests for comments, causing a total halt in the development of the standard (making changes to the XEP needs the authors approval). Things like specifying a new wire protocol are possible and reasonably easy to do. However not having changes written down in the XEP makes it nearly impossible to make coordinated changes. I’m sure there is a ton of potential for OMEMO and it is sad to see its (protocol-) development having come to a halt.

I’m sure that many of its current issues can be addressed by changes to the XEP. This is what I think needs to be done to OMEMO to make it more usable:

  • Specify a new wire protocol: This could make OMEMO accesible for commercial applications and allow independent implementations -> broader deployment
  • Specify a general payload encryption scheme: This could benefit other encryption protocols as well and would make it possible to apply end-to-end encryption to a wider variety of use cases.
  • Reuse the payload encryption scheme in OMEMO: Utilize OMEMO for things besides body encryption.
  • Specify a way to sign device lists with “persistent key” algorithms like OpenPGP: This could simplify trust management.
  • Specify a way to backup the identity key: This could reduce the identity key chaos, since the key could be reused on new devices/installations. However clients would have to make it clear to the user, not to use the same key on multiple devices.

This have been my thoughts about OMEMOs current state. What do you think about it?

Happy Hacking!

Summer of Code: Smack has OpenPGP Support!

I am very proud to announce, that Smack got support for OpenPGP for XMPP!

Today the Pull Request I worked on during my GSoC project was merged into Smacks master branch. Admittedly it will take a few months until smack-openpgp will be included in a Smack release, but that gives me time to further finalize the code and iron out any bugs that may be in there. If you want to try smack-openpgp for yourself, let me know of any issues you encounter 🙂

(Edit: There are snapshot releases of Smack available for testing)

Now Smack does support two end-to-end encryption methods, which complement each other perfectly. OMEMO is best for people that want to be safe from future attacks, while OpenPGP is more suited for users who appreciate being able to access their chat history at any given time. OpenPGP is therefore the better choice for web based applications, although it is perfectly possible to implement web based clients that do OMEMO (see for example the Wire web app, which does ratcheting similar to OMEMO).

What’s left to do now is updating smack-openpgp due to updates made to XEP-0373 and extensive testing against other implementations.

Happy Hacking!