Encryption in Libervia/XMPP

Libervia being an XMPP client, it handles encryption between client and server, then the message is encrypted between servers, and finally to deliver to target client(s).

This avoid the communication to be accessible from people having access to the network, but the communications are available to server administrators, or administrators of services that you may use (e.g. pubsub service).

To make your communications inaccessible to anybody but your recipient(s), end-to-end encryption (or e2ee) may be used. This page aims to explain roughly how it is done in Libervia and XMPP so end-user can understand and exploit it correctly.


this page is work in progress, it will be completed over time to explain the whole machanism. Is something is not clear, please contact the development team at the XMPP room libervia@chat.jabberfr.org to get details and help to improve this documentation.

Pubsub Encryption

By default, pubsub items are in plain text (i.e. not encrypted, beside the normal encryption between client and server, and between servers). This is often the desired behaviour as pubsub is often used for public matters (public blogs, events, or other kind of data).

However, pubsub may also be used for private matters, to keep safe some of your own data, or to uses all other kind of features privately (private blog, event organization, etc).

To make private pubsub node, in addition to the access model which restrict entities which can retrieve its item, it is possible to use end-to-end encryption.

Pubsub is not encrypted the same way as messages, because you generally need to access all items of a pubsub node, even if you get access to the node once items have already been published.

E2ee is currently done using OpenPGP (or OX for PubSub: OXPS). Each item is encrypted using a symmetric encryption, which mean that the same key (called “shared secret”) is used both to encrypt and decrypt an item, and is shared between all people who must access or publish to the pubsub node (i.e. blog, event calendar, etc). This is done this way to make it easy to add a new members, who can then access all archives of the node, but this also means that if the shared secret is compromised (i.e. somebody who should not has obtained a copy), all items made with this secret are accessible to the persons in possession of the secret.


OXPS specification is not currently an official XEP (XMPP Extension Protocol), it is about to be examinated by “XMPP council”. This documentation will be updated with the evolution of the situation. You can read current specification proposal at https://xmpp.org/extensions/inbox/pubsub-encryption.html (which is inaccessible due to a 404 error at the time of writting, this should be fixed hopefully when you read this documentation).

To make an encrypted pubsub node accessible to somebody, you need to share the secret with them.

You can see that as the key of a house: everybody who has a copy of the key can go inside the house, and bring something or take pictures. Sharing the secret is like making a copy of the key and giving it to the person.

If you think that your shared secret is compromised (obtained by somebody who shouldn’t), or if you want to remove access to somebody, you can “rotate” the secret, which means that every existing key is revoked (flagged as “you should not use it anymore to write something”, but you can still use it to read archives), and a new one is created (to write new items).

With the house analogy, it’s like changing the locks, and giving new keys to trusted people: people with the older keys can’t go inside the house anymore, but if they have taken pictures before the key has been changed, theirs pictures is still in their possession.


If you rotate the shared secret, new items are using the new secret, but all items which were existing before the secret rotation stay accessible to people who had access to former secrets (the pubsub node can refuse access to them though). If malicious people had access to items before, they could have made copy anytime, thus there is little point in reencrypting everything.

To handle encrypted pubsub node shared secrets from command line, you may use pubsub/secret: share, revoke or rotate node secrets.

Pubsub Targeted Encryption

It is also possible to encrypt a single pubsub item for a restricted set of users. This is different from the pubsub encryption explained above, as if you want to encrypt for a different set of users, you need to re-encrypt all concerned items, so this is more adapted for use cases when you only want to encrypt a few items in a pubsub node.

On the other hand, you have all the properties of the algorithm used (for now, only OMEMO 2 is supported), which means that you can have Perfect Forward Secrecy for algorithms supporting it (it’s the case for OMEMO.)


Pubsub Targeted Encryption(PTE) specification is not currently an official XEP (XMPP Extension Protocol), it is about to be examinated by “XMPP council”. This documentation will be updated with the evolution of the situation.

Pubsub Signature

By default, identity of the publisher of a pubsub item is difficult to authenticate: it may be specified by the pubsub service (using the “publisher” attribute), but this attribute is not set by all pubsub services, and it can be spoofed by the service or the XMPP server.

To strongly authenticate the publisher of a pubsub item, it is possible to cryptographically sign an item. This can work with any pubsub item, encrypted or not, and it can be done after the item has been published. The process use Pubsub Signing protoXEP


Pubsub Signing specification is not currently an official XEP (XMPP Extension Protocol), it is about to be examinated by “XMPP council”. This documentation will be updated with the evolution of the situation.


Signature only certifies that the signers strongly link themselves with this version of the item, not that the signers are the original authors of the item. In other words, it prevents somebody to say that somebody else has published something (the signature would be missing or invalid), but the published data may come from anywhere. Also keep in mind that a security breach (stolen encryption keys, major bug somewhere) is always possible.

To handle pubsub signatures from command line, you may use pubsub/signature: Sign and Check Items Signatures.