• Be chevron_right

    Berlin Online XMPP Sprint 2020

    debacle · / berlin-xmpp-meetup · Sunday, 22 March - 00:47 edit

Berlin Online XMPP Sprint 2020

The planned XMPP sprint in Berlin from Thursday, 2020-03-26 to Sunday, 2020-03-29, will take place despite the current crisis. But instead of an in-person meeting, it will be an online event!

We will mainly use the XMPP group chat for all coordination, and multiple Jitsi instances for audio/video conferencing, maybe also mumble for voice chat.

Please find all details in the wiki and consider participation! This time, there are neither travel nor hotel costs!

See you at the Berlin Online XMPP Sprint! Berlin is whereever you are!

#xmpp #sprint #event #community #hacking #freesoftware #uwpx #beagleim #siskinim #xmppjs #omemo #kaidan #smack #dino #omemo #prosody #xmpprs #salutatoi #debian #jitsi

  • favorite

    1 Like


  • Mo chevron_right

    Movim 0.16.1 – Cesco

    Timothée Jaussoin · / Movim · Friday, 6 December - 09:50 · 1 minute

Only a few weeks after the 0.16 release here is the 0.16.1 one!

This release includes several fixes and a few new features.


You can now share posts to your connected chatrooms :)

Chatroom post sharing

Communities layout were a bit redesigned, publication rules are now displayed clearly in the right column and the header shows more information on mobile.

Communities redesigned

All the messages that you sent in the one to one discussions can now be edited.

Message edition for the whole history

The videoconferencing feature was heavily refactored and several issues were fixed during this process. A new XEP was also used partially to improve the call negociation flow, XEP-0353: Jingle Message Initiation.


In the database an index was added on the key that was tracking contacts avatars. This sounds maybe a bit technical to you but this small fix boost quite a lot the performances during the login process, when you join a chatroom (especially that one) or when a contact updates his/her avatar. Because it's a database change you should run the database migrations when updating from 0.16 to 0.16.1.

All the entities that are on the XMPP network needs to declare what they are capable of to the others. This allows feature discovery and negociation and is specified in the #XMPP extension XEP-0115: Entity Capabilities. After the big code refactor of the handling of those #capabilities within the Movim codebase some other small improvements and fixes were done to wrap up properly this feature.

Presences sent to MUC are now generated the same way than those sent to contacts, this fixes #711.

DNS resolution errors an timeout are now handled properly displayed during the authentication flow (#368).

The SQL_DATE constant was renamed to MOVIM_SQL_DATE to prevent some naming conflicts (#820).

What's next?

PHP 7.4 was released a few days ago, so the upcoming version will focus on fixing issues to make Movim fully compatible with that version.

This new PHP release also includes an exciting feature that allows #PHP developpers to call directly C libraries in their codes. This could allow #Movim to directly use the libsignal C library and therefore (finally) allow OMEMO end-to-end-encryption to be implemented. This will be a lot of work and verifications so we're not promissing anything anytime soon. Stay calm please!

That's all folks!

#omemo #videoconference #jingle #release

  • movim/movim

    Movim - Decentralized social platform. Contribute to movim/movim development by creating an account on GitHub.

  • image
  • favorite

    4 Like

    togart , eyome , CNT 31 , Marzanna

  • chevron_right

    Things I don't like with OMEMO as it is today

    debacle · Tuesday, 13 November, 2018 - 19:21 edit · 2 minutes

I use OMEMO every day, because I prefer end-to-end encrypted messaging for many purposes. OMEMO is much better than OTR, and it works well enough to be useful. But OMEMO has a number of usability issues, that should be addressed by the IM and XMPP community at some point.

  1. It relates to devices instead of users. I don't want to know, whether my contacts own a new device, nor should they care when I do.
  2. Forward secrecy is a good thing for TLS. But when used for messaging, I cannot decrypt my old messages stored on the server in all cases. Also, it makes key escrow impossible, which is a killer for using it in business.
  3. Deniability. I want verifiable signatures instead. Maybe I want to conclude a contract via XMPP? For deniability I would use an anonymous account in the first place.
  4. OMEMO does not encrypt the complete stanza, but only the textual part of a message.
  5. It does not work with local, serverless messaging. I don't use this feature a lot, but still, encryption should work with it, too.
  6. OMEMO seems to be pretty complex, which makes implementation relatively hard. In fact, bugs related to OMEMO are still frequent in some clients.
  7. I already have an OpenPGP key, that is trusted (and occasionally signed) by many. Why not re-use it for IM purposes?
  8. (added 2019-02-15) This is an amendment to the first point: If we accept the concept of keys per device, at least improve the management. The keys should have a label, e.g. "mobile" or "PC at work", to be less confusing. Or why not automatically cross-sign keys from all devices?

Some of the points can be addressed in later OMEMO versions, but some points seem to be woven into the fabric. Fortunately, I see the light at the end of the tunnel (and I hope it is not the oncoming train): OX or "OpenPGP for XMPP". I hope, that it will heal all my OMEMO aches:

The only thing, I do not like is synchronising of encrypted private keys using PEP, which involves storing it on the server, only secured by the PGP passphrase and the "backup code", generated by the device. But nobody forces me to use the backup feature and I assume, that it can be blocked by admins who feel uneasy about it. Also, OpenPGP seems to have a higher per message overhead than OMEMO. This is probably unavoidable.

Edit: Correction about OX private key encryption, thanks to lovetox!

Edit: Add point about OMEMO complexity and errors, thanks to Holger!

#omemo #xmpp #im #ox #openpgp #e2ee

  • chevron_right

    Cryptocat, ou le piège du client magique

    Timothée Jaussoin · Wednesday, 6 April, 2016 - 19:35 edit · 6 minutes

Il y a quelques jours je suis tombé sur un article annonçant la sortie de la nouvelle mouture du client de messagerie sécurisé Cryptocat. Je ne m'étais jamais réellement penché sur ce client car il faisait, selon moi, partie des dizaines d'autres clients surfant sur la vague des messageries instantanées chiffrées sorties suite aux révélations d'E.Snowden. J'ai donc voulu creuser un peu et voir de quoi il était composé.

Comme vous le savez peut-être, je travaille moi-même sur un client de messagerie "sociale" appelée Movim exploitant le protocole XMPP. J'essaye, au travers de ce projet, de montrer aux gens qu'il est parfaitement possible de créer une solution à la fois sécurisée, standard et décentralisée tout en offrant une interface agréable et simple à comprendre. Petite précision toutefois: Movim ne possède pas (encore, mais j'y travaille) de fonctionnalité de chiffrement de bout en bout. Néanmoins il est possible de faire ce genre de chiffrement sur XMPP de façon standard et compatible avec des technologies standardisées comme OTR et le récent OMEMO (c'est d'ailleurs cette norme que j'ai décidé d'implémenter dans Movim).

La chose que je trouve dommage avec tous ces services et clients c'est qu'ils ne sont pas compatibles entre eux. Pourtant il existe aujourd'hui plusieurs clients XMPP proposant la norme OTR et OMEMO mais qui ne sont malheureusement pas si connus et médiatisés que les autres. Je mentionnerais en particulier l'excellent Conversations (sur Android) dont l'équipe est à l'origine de la norme OMEMO (qui est elle-même une implémentation de la norme Axolotl dans XMPP, notamment utilisée sur le client Signal).

Étant un peu curieux par nature je me suis plongé dans le code source de la nouvelle version de ce cher Cryptocat pour regarder un peu ce qu'il a dans le ventre.

Ni une, ni deux, je clone le dépôt sur ma machine et je commence à explorer le code.

Première surprise !

Avant même d'ouvrir le moindre fichier j'avais déjà un petit sourire en coin en voyant le nom de certains d'entre eux dans le répertoire src/js/.


Tiens, tiens, tiens. Un petit tour sur la page Security du site me confirme bien ça. Cryptocat utilise XMPP comme transport et OMEMO comme méthode de chiffrement. Le reste du blabla n'est rien d'autre qu'une réexplication de la norme Axolotl sans pour autant la mentionner.

Donc Cryptocat est un client XMPP, en Javascript, avec la norme OMEMO par dessus.


Je ne me suis pas particulièrement penché sur la partie chiffrement du projet, j'avoue ne pas avoir assez de compétences en cryptographie pour offrir une critique constructive et je pense que l'auteur du projet est bien plus expérimenté que moi là dessus. Je salue par ailleurs sa volonté de transparence à ce propos. Néanmoins je commence à bien connaitre le protocole XMPP et je sais que son point fort est la possibilité d'interconnecter les serveurs entre eux et de laisser le choix du serveur à utiliser aux utilisateurs.

L'interconnexion est une fonctionnalité que j'estime nécessaire car d'une part, elle permet aux utilisateurs d'avoir le choix du serveur sur lequel ils iront déposer leurs données et d'autre part, elle décentralise les points d'échange du réseau (et rend ainsi plus difficile la censure et l'écoute du réseau).

Après avoir regardé plus en détails le fichier xmpp.js j'ai enfin la confirmation de ce dont je me doutais jusque là.

jid: username + '',
server: '',

Oui, il y a bien un serveur XMPP écrit en dur dans le code source du projet.

Explorons un petit peu le serveur

Le site XMPP IM Observatory nous retourne une note de A pour la sécurité du serveur, ici rien à dire. Par contre je découvre que l'interconnexion avec les autres serveurs du réseau n'est pas autorisée. La connexion entre le client Javascript et le serveur se fait au moyen d'un Websocket et le serveur XMPP est un serveur Prosody tout bête.

Cryptocat n'est donc pas qu'une application de chat offerte par Nadim Kobeissi, mais aussi un service centralisé auquel les utilisateurs sont contraints de se connecter (sauf s'ils changent le code source du client, ce qui est possible, mais combien le feront ?).

Précisions sur le chiffrement de bout en bout dans XMPP

Le chiffrement de bout en bout est une très grande avancée dans l'anonymisation des données échangées. Néanmoins il ne permet pas tout. Sur XMPP par exemple il faut savoir que OTR et OMEMO ne chiffrent que le contenu des messages et pas la signalisation qui les accompagne (certains diront les métadonnées). Mais que pouvons nous trouver dans ces métadonnées ? Et bien l'identifiant de l'émetteur et du destinataire du message mais aussi beaucoup d'autres choses pouvant êtres sensibles. Une page sur le Wiki de Reporters Sans Frontieres résume plutôt bien tout ça. Ces informations peuvent être conservées dans des historiques et journaux sur les serveurs XMPP.

En choisissant de centraliser son service sur un seul et unique serveur (qui semble être hébergé dans le datacenter d'OVH à Roubaix) l'auteur de Cryptocat a aussi fait le choix de concentrer l'intégralité du trafic de sa plateforme sur un seul et unique point du réseau Internet.

Cela me serait égal si toutes ces informations étaient précisées sur le site du projet, au moins de façon temporaire si l'objectif à terme était de permettre la connexion à d'autres serveurs XMPP. Mais je trouve vraiment dommage qu'il ait tu ces informations.

Petit bonus, qu'en est-il de la v1 de Cryptocat ?

Même si je salue le fait d'utiliser des normes comme XMPP et OMEMO dans Cryptocat, j'ai quand même jeté un œil à la première version du projet pour voir sur quelle architecture il s'était basé.

Sans grande surprise la première version se base également sur XMPP et OTR. Néanmoins elle permettait de changer le serveur XMPP sur lequel le client se connectait. J'espère donc qu'il sera également possible de faire la même chose sur la seconde version.

Pas de quoi s'inquiéter donc ?

Oui, pour le moment pas de quoi crier au scandale mais je souhaiterais que Nadim soit aussi transparent sur l'architecture de son projet que sur les méthodes de chiffrement qu'il utilise au sein de son application.

Je pense qu'il est aussi important d'informer les utilisateurs de comment sont protégées leurs messages mais aussi par où et comment ceux-ci sont acheminés.

Dernière petite question, pourquoi vouloir à tout prix fermer la plateforme alors que XMPP permet nativement l'interconnexion avec les autres réseaux ?

En bref, si vous voulez avoir les mêmes fonctionnalités que Cryptocat, plus tous les avantages de XMPP (interconnexion, gestion de l'historique, profiles, notifications, accusés de réception…) tournez vous vers des clients comme Conversations ou Gajim (et bientôt Movim concernant le chiffrement je vous promet !).

That's all folks !