Search
1000 results for “xmpp_providers”
-
XMPP Providers is featured in the DI.DAY initiative handout created by the XMPP Community!
Come by to the XMPP/Jabber #Realtime Lounge at #FOSDEM! #ULB, AW building, Level 1
#chat #messaging #xmpp #jabber #standards #diday #interoperability
#decentralization #operators #service #EU #europa #opensource #EuropeanUnion #europe #FOSDEM
#Brussels -
Find Your XMPP Chat Provider!
Come by to the XMPP/Jabber #Realtime Lounge at #FOSDEM! #ULB, AW building, Level 1
#chat #messaging #xmpp #jabber #standards #interoperability
#decentralization #operators #service #EU #europa #opensource #EuropeanUnion #europe #FOSDEM
#Brussels -
Find Your XMPP Chat Provider!
Come by to the XMPP/Jabber #Realtime Lounge at #FOSDEM! ULB, AW building, Level 1
#chat #messaging #xmpp #jabber #standards #interoperability
#decentralization #operators #service #EU #europa #opensource #EuropeanUnion #europe #FOSDEM
#Brussels -
Add your provider to XMPP Providers!
Follow our new guide: https://providers.xmpp.net/add-provider/
Meet us at FOSDEM!
ULB, AW building, Level 1#chat #messaging #xmpp #jabber #standards #interoperability
#decentralization #operators #service
#opensource #FOSDEM #ULB -
Find Your European Union XMPP Chat Provider!
You can now easily find an XMPP provider based in the European Union:
https://providers.xmpp.net/blog/2026-01-18-eu-providers/See you at FOSDEM! AW building, Level 1
#chat #messaging #xmpp #jabber #standards #interoperability #decentralization #operators #service #EU #europa #opensource #EuropeanUnion #europe #FOSDEM #Brussels
-
New table functions in Overview
On the #XMPP #Providers Overview page the table received new functions. Here you can see all available information across the #operators in a tabular view.
Search now each column for specific information. If you are actively looking for custom properties, easily start breaking down the table to your needs.
#chat #messaging #jabber #standards
#interoperability #decentralization #operators #service -
#XMPP has proven to last in the toughest environments!
#chat #messaging #jabber #standards #opensource
#interoperability #decentralization #operators #service -
Cierra https://blah.im así que si tienes cuenta en esta instancia busca crear otra: https://providers.xmpp.net/
#xmpp #tuba #mastodon #profanity -
WHY do you have to convince somebody to change?
As user, I expect, when using some kind of communication, I can communicate to everybody, using same kind communication.
Let's say I send a letter - it goes around the world! Transported by many different providers.
Let's say I use landline provider "A" - why shouldn't I be able to call a frind using provider "B" or "H"??
So WHY change to Signal?
Basically it's the same as Whatsapp but
- blue instead of green.
- it's a walled garden, too (only signal can talk to signal)
- it's not free software in means of you can use/modify AND paritcipate
- you need to have phone number & a smart phone, at least to register
- it's driven by servers you mybe don't trust or would ever use? oil driven? nuclear energy driven?
- it's very easy to loose chat history, when changing deivces - we'll - a new chat history will be available soon
- [...]I like to use, what I WANT to and am still be able to communicate with everybody.
That's why I prefer using an open system. I can choose from several clients and lots of providers (or be my own one). I prefer Matrix - it's that open, that by using bridges I only have one single client for signal, rarely used whatsapp (a shared account), some email and, offcourse, matrix.
-
🚨 Fixing the PKI Mess: CAA + Your Own CA via DNS 🚨
Right now, any CA can issue a certificate for your domain. Even if you set a CAA record (`issue "letsencrypt.org"`), it only controls *who* can issue, not what cert is valid. This is broken.
🔐 What if we could fix this using DNS?
#Introducing CAA+CA Fingerprint: Self-Sovereign Certificate Authority
Instead of just saying *which CA can issue*, you publish your own CA's fingerprint in DNS. If your CA issues a cert for `awesomecars.com`, browsers should validate it against the DNS-published CA key.🔥 How It Works
You run your own CA (because why trust the cartel?). You then publish:
1️⃣ A CAA record specifying your own CA (with a fingerprint! 🔥)
2️⃣ A DNS record with your CA’s public key (like DKIM but for TLS!)🔹 Example DNS Setup for `awesomecars.com`:
```
awesomecars.com. IN CAA 0 issue "pki.awesomecars.com; sha256=abcd1234..."
pki.awesomecars.com. IN CERT 6 0 0 (--BEGIN CERTIFICATE-- ....)
```
Now, only certs signed by your CA are valid for `awesomecars.com`, even if another CA is tricked into issuing a rogue cert. No more CA hijacking!🚀 Why Is This Better Than the Current CA Model?
✅ Self-Sovereign Identity: If you own the domain, you should own its PKI.
✅ Prevents Rogue Certs: No government or rogue CA can fake a cert for your domain.
✅ Works Like DKIM for Email: Your CA’s public key is stored in DNSSEC-protected records, just like DKIM keys for email signing.
✅ No More External Trust Issues: You control your CA entirely, instead of relying on Google’s CA store.
✅ Perfect for Self-Hosting & Internal Networks: No need for external CA trust—your DNS is your trust model.🔥 Why Isn’t This a Thing Already?
Big Tech hates this idea because it removes their control:
❌ Google wants Certificate Transparency (CT), where they control which certs are logged.
❌ Commercial CAs make $$$ selling certs. This kills their business.
❌ DNSSEC adoption is intentionally kept low by the same companies who don’t want this to succeed.Browsers refuse to support TLSA for the same reason—they want centralized CA trust, not self-hosted PKI.
🔗 Who Needs to Implement This?
🚀 Self-hosters & Homelabs: Use this for your own infrastructure.
🚀 Email providers: Stop relying on public CAs!
🚀 Privacy-focused projects (Tor, Matrix, XMPP, Fediverse, etc.): A true decentralized PKI alternative.
🚀 Fediverse devs: Let’s push for DNS-based CA validation!What do you think? Would you trust your own CA in DNS over some random commercial CA?
🔁 Boost this if you want a decentralized PKI revolution!
🔥 This keeps the focus on self-hosting your own CA, highlights the security flaws of current PKI, and calls out Big Tech’s resistance to decentralized trust.
#PKI #Security #DNSSEC #DANE #TLSA #CAA #SelfHosting #Fediverse #Privacy #Decentralization #dns #linux
-
Emergence of governance in open communities
How the Fediverse is growing to meet its challenges
[German language version of this text will be published in FIfF-Kommunikation, the journal of the Forum InformatikerInnen für Frieden und gesellschaftliche Verantwortung (FIfF e.V.)]
ToC
The dead live longer
Multi-layered self-regulation
Gab: the Nazis are coming
Threads and Bluesky: Federation Washing?
Conclusio: Small is Beautiful
LiteraturThe social media landscape has been undergoing a tectonic shift since Elon Musk took over Twitter and Donald Trump took over the USA. The Fediverse emerged at a time when the previous phase of decentralised social networks – the blogosphere – was being supplanted by globally centralised platforms such as Facebook (2004), YouTube (2005) and Twitter (2006). With them came the problems: surveillance-based advertising, election manipulation by Cambridge Analytica, addictive design, enshittification of previously useful services (Cory Doctorow), techno-feudalism (Yanis Varoufakis).
In contrast, a counter-movement for the recentralisation of the Internet (Kahle 2016, Berners-Lee et al. 2016) is emerging and for sovereignty in Europe, which is becoming painfully aware of its comprehensive technological dependence on the US.
The perception of a crisis is giving rise to a new digital universe, the decentralised and federated Fediverse. For many migrants from toxic environments, it feels like a friendly neighbourhood where reason and civilised conversation prevail. Of course, this is not a genetic trait, hard-coded into Mastodon & Co. But how does an open community oriented towards the common good, a bustling field of players and technologies, organise itself? How does the governance of complex socio-technical systems unfold?
Resilient structures of self-organisation, so the theory goes, are the result of experiences of conflict. Current external or internal conflicts as well as structural problems (onboarding, money, etc.) trigger a collective reflection that challenges open communities to emerge from a lack of structure. The solutions, as I would like to show with examples, can be of technical or social protocols, usually a combination of both.
The dead live longer
Distributed and federated protocols have been around since 1999 with XMPP. According to official historiography, the Fediverse began in 2008 with the decentralised OpenMicroBlogging protocol and the platform Identi.ca, a free version of Twitter based on it, both developed by Evan Prodromou.
In January 2016, the World Wide Web Consortium (W3C) presented the ActivityPub protocol to improve the interoperability of the various decentralised platforms in the Fediverse. Prodromou is again co-author. Also since 2016, Eugen Rochko has been developing the microblog Mastodon, which is now the star among the decentralised platforms with around ten million users. In addition to Mastodon, the microblog Misskey, the photo platform Pixelfed, the link aggregator Lemmy and the video platform Peertube are also popular in the ActivityPub universe (FediDB: Software, April 2025).
As already mentioned, the development is motivated by criticism of the techno-feudalism of the mega-platforms. The current lead author of ActivityPub, Christine Lemmer-Webber, notes that no companies are involved in the team developing the protocol, which is very unusual for technical committees. In addition, the team identifies predominantly as queer, which leads to functions in the protocol and in the clients that help users and administrators to protect themselves from ‘unwanted interaction’ (Klemens 2023).
Mastodon is run by a non-profit limited company. The community excludes venture capital as well as surveillance advertising, which has made the mega-platforms the richest companies in the world. Mastodon per default does not even include a function for displaying adverts. But how is a global community that is essentially financed by collecting donations supposed to build an alternative to this overwhelming power and lure people out of the lock-in by the mega-companies?
As the Fediverse contradicts all business logic, experts predicted that it would soon come to an end (Woźniak 2025). The opposite is the case. At Berlin Fediday 2024, Prodromou (2024) reported on growth by all criteria: ActivityPub is being implemented by more and more platforms (WordPress, Ghost.org, Flipboard, Threads). The number of users is growing continuously, as are the bridges to other protocols, applications, content, publications and institutions of self-organisation: the SocialCG (Community Group) for ActivityPub at the W3C, the online conference FediForum, the moderator community IFTAS, Mastodon’s non-profit offshoot in the USA. He answers the question of his presentation title ‘Is Bigger Better?’ with a resounding yes.
A week later, Prodromou announced the creation of the Social Web Foundation (SWF), whose mission is a ‘growing, healthy, sustainable and multipolar Fediverse’. Shortly afterwards, the foundation became a member of the W3C as a community front-end for ActivityPub: ‘We collect requirements and design potential extensions to the ActivityPub protocol and guide them through standardisation’ (SWF 2025).
Multi-layered self-regulation
The Fediverse is, of course, also subject to external regulation through laws, etc. The focus here is on the area in which the Fediverse players are free to regulate themselves. The Fediverse project unites them on the basis of a normative conviction: a different, decentralised, federated Internet is possible. Civil society and the public sector can collectively create an online environment in which people treat each other in a civilised and respectful manner. Common values are initially shared tacitly. As the community grows and becomes more diverse, but especially when conflicts challenge these values, they are made explicit in rules of conduct, mission statements, etc. and operationalised with mechanisms for their implementation and enforcement.
Projects usually start with minimal ad hoc organisational structures and move on to more permanent forms as required. Regulation arises in order to solve problems, e.g. a legal form must be established in order to open a bank account and thus collect donations. Internal dynamic lead to the problem of the Benevolent Dictator For Life (BDFL). A free software project is started by a man (is there really not a single woman in the Wikipedia list of BDFLs?), becomes popular, grows into a community of co-developers and users, in which the founder remains at the top, respected for his valuable contributions. A meritocracy that, if left unchecked, becomes dysfunctional. The term was coined for Linus Torvalds and his Linux kernel. In the Fediverse, this currently affects Matt Mullenweg from WordPress, Daniel Supernault from Pixelfed and Loops and Eugen Rochko from Mastodon, for example. The latter announced in January 2025 that he would retire from management and concentrate on development. A new non-profit company is to be founded to which he will transfer the Mastodon brand and the copyrights to the code. This means that Mastodon’s independence no longer depends on a single person (Mastodon 2025).
Gab: the Nazis are coming
2016 was a breakthrough year for the Fediverse. It was also the year of Brexit and Trump’s first presidential election. And behind both, the Alt-Right movement emerged onto the research radar from image boards like 4Chan. An Internet-native movement that only half-jokingly boasts of having voted Trump into office and promotes “Fashy”, a “fashionable fascism” (Cramer 2017).
Gab was launched in August 2016 as a social network for radical free speech. Co-founder Andrew Torba cited ‘the total left-wing monopoly of Big Social’ as the motive. Especially during the 2016 election, Facebook and Twitter censored conservative voices. Gab started on its own technology as a mixture of Twitter and Reddit.
Gab was soon banned from the app stores for hate and pornography. In October 2018, a white supremacist killed eleven people in a synagogue in Pittsburgh. The perpetrator had posted his anti-Semitism on Gab for almost a year. As a result, payment services, web hosts and cloud providers also blocked Gab. To circumvent this block, the creators decided to migrate Gab to a fork of Mastodon in July 2019, making it accessible with every Mastodon app.
Mastodon founder Rochko spoke out on the same day. He explained that the licence (AGPLv3) does not allow certain uses or users to be excluded as long as it is complied with. At the same time, he expressed his disgust at Gab,
“which uses the pretense of free speech absolutism as an excuse to platform racist and otherwise dehumanizing content. Mastodon has been originally developed by a person of Jewish heritage and first-generation immigrant background, and Mastodon’s userbase includes many people from marginalized communities.
Mastodon’s decentralized approach that allows communities to self-govern according to their needs has enabled those marginalized communities to create safe spaces for themselves where previously they were reliant on big companies like Twitter to stand up for them, which these companies have often failed to do.” (Rochko 2019)
It was precisely decentralisation and federation that brought about a social protocol as a solution. On the one hand, many Mastodon admins had already decided to block Gab, including mastodon.social, which is operated by the Mastodon gGmbH itself. On the other hand, rules have been made explicit for the servers listed on joinmastodon.org, which is also operated by the gGmbH. With the Mastodon Server Covenant, server operators commit to
1. Active moderation against racism, sexism, homophobia and transphobia,
2. Daily backups,
3. At least one other person with emergency access to the server infrastructure,
4. And to give users at least 3 months of advance warning in case of shutting down. (Mastodon: Covenant)
There is no technical switch against Nazis. Although there have been discussions about inserting code into the clients to prevent them from logging into Gab servers, such changes can be easily reversed. The copyright licence also does not allow Nazis to be excluded from using one’s own software. There is a long debate about banning use for military purposes, for example (Kreutzer 2006). In practice, restrictions on use by licence violate the definition of free software and have not become established.
Nazis can set up their own Fediverse servers. However, the Federation’s code of conduct, the Covenant, ensures that these instances remain isolated, like Gab and Truth Social, and do no harm in the Federation. For newcomers, this level is less visible than the policies of the individual instances. However, it is crucial for the information space as a whole.
Regulations are only as good as their enforcement. Block lists for accounts and instances are maintained as tools for the daily work of admins and moderators (e.g. Oliphant). The moderators have joined forces in the IFTAS (Independent Federated Trust & Safety) forum.
Looking back at research on “alternative social media” (ASM), Robert W. Gehl (2025) notes that the widespread assumption that ASM are progressive had a blind spot: they can just as easily be used by the political right. The deplatforming of right-wing radicals on the mega-platforms increased the pressure to build their own places for radical freedom of speech. Now the research has turned into the opposite and reduced ASM to ‘alt-right social media’. However, Gehl sees an advantage in the fact that an aspect that was largely missing from the earlier literature has since been addressed: governance. ‘Much of the earliest scholarship focused on how technical elements such as free and open source software and decentralized architectures would shift power away from corporate social media to end users, but had less to say about how those users might govern themselves.’ (ibid.)
Threads and Bluesky: Federation Washing?
The next invasion of the Fediverse threatened to come from one of the mega-platforms that the alternative was up against. Meta wanted to capitalise on the Twitter exodus following Musk’s takeover and planned a text-based companion app to Instagram. Threads launches with fanfare on 5 July 2023. Thanks to Instagram’s more than two billion users, the new service gained 100 million users within five days, except in Europe, where a data protection clarification delayed the launch until December. Threads also began integrating the ActivityPub protocol in December 2023 (The Verge 2023).
The bridge from Instagram to the Fediverse has triggered even more heated debates than Gab, including reciprocal death threats. Above all, there were fears about the well-known strategy of embrace, extend, extinguish. From this camp, the tried and tested instrument used against Gab was brought up: a campaign for the collective exclusion of threads from the federation, which was followed by many instances.
Conversely, Fediverse stakeholders welcomed threads because they see interoperability between platforms as a major step forward. ‘We’ve been advocating for this for years,’ wrote Rochko (2023) on the day of the threads launch. In his blog post, he addresses accusations (data tracking, advertising, being overwhelmed by huge servers, embrace-extend-extinguish, moderation). However, he describes the lock-in of the social graph as the biggest problem, which prevents users from switching platforms if they do not want to lose all their contacts.
“The fact that large platforms are adopting ActivityPub is not only validation of the movement towards decentralized social media, but a path forward for people locked into these platforms to switch to better providers. Which in turn, puts pressure on such platforms to provide better, less exploitative services. This is a clear victory for our cause, hopefully one of many to come.” (ibid.)
Prodromou also welcomed the mega-platform’s access so that the Fediverse can quickly grow and become a powerful alternative. If there are problems, every site and all users are free not to connect to the newcomers. ‘Choice is part of the strength of the Fediverse.’ (Prodromou 2024)
Another invasion came from Twitter, specifically from its co-founder and former CEO Jack Dorsey. In 2019, he launched an initiative that gave rise to the AT Protocol and Bluesky Social. The platform with the look and feel of the original Twitter was launched in 2023. In January 2025, Bluesky claimed to have 30 million users (BNO News 2025).
Technically, the AT protocol allows decentralisation. In fact, the system is currently neither decentralised nor federated, as Lemmer-Webber (2024) discusses in detail. Furthermore, venture capital financing, not least from blockchain circles, raises doubts about sustainable freedom.
Conclusio: Small is Beautiful
The mega-platforms must continue to be rendered less hazardous through legal regulation. Buying oneself free is not an option. Rather, building alternatives is crucial. Decentralisation from above leads to a Fedi-Washing that only looks like it. The inherently decentralised network of protocol-connected nodes that has grown over the years and organises itself from below is sustainable. Last but not least, the Fediverse offers an opportunity for Europe. Many of the developers and more than twice as many Fediverse servers are in the EU (8,818) than in the USA (4,275) (Fediverse Observer, April 2025).
The non-profit nature and small size of the communities are clearly positive features of the Fediverse. Kissane & Kazemi (2024) have investigated how governance is organised on individual servers and between servers. Their conclusion: ‘Fediverse governance as we encountered it in our research conversations is emergent, unevenly distributed, and often reactive.’ The majority of Fediverse servers are operated by individuals or small groups. Medium-sized servers offer uniquely favourable conditions for community self-governance according to local norms and allow for very direct, context-dependent moderation that is superior to that of centralised platforms. ‘The Fediverse’s combined emphasis on the sovereignty of local norms and a federated form of network diplomacy can offer a real and optimistic challenge to the dead end of centralized content moderation at scale’ (ibid.).
To summarise: local, manageable communities form the basis, create diplomatic networks and grow organically into a fediverse that is more than the sum of its parts. Small is Beautiful as a prerequisite for Bigger is Better.
Literatur
Berners-Lee, Tim et al. (2016). Solid: A Platform for Decentralized Social Applications Based on Linked Data, 2016, http://emansour.com/research/meccano/solid_protocols.pdf.
BNO News (2015). Twitter alternative Bluesky hits 30 million users, 28.01.2025, https://bnonews.com/index.php/2025/01/twitter-alternative-bluesky-hits-30-million-users/.
Cramer, Florian (2017). Meme Wars: Internet culture and the ‘alt right’, at FACT Liverpool, 07.03.2017, https://www.youtube.com/watch?v=OiNYuhLKzi8.
FediDB: Software (o.J.). https://fedidb.org/software.
Fediverse Observer (o.J.). Server nach Land, https://fediverse.observer/stats.
Gehl, Robert W. (2025). A Brief History of Alternative Social Media Scholarship, 07.02.2025, https://www.socialmediaalternatives.org/2025/02/07/asm-scholarship-history.html.
Kahle, Brewster (2016). Locking the Web Open: A Call for a Decentralized Web, Juni 2016, https://archive.org/details/LockingTheWebOpen_2016.
Kissane, Erin & Darius Kazemi (2024). Findings Report: Governance on Fediverse Microblogging Servers, https://fediverse-governance.github.io/.
Klemens, Ben (2023). Mastodon – and the pros and cons of moving beyond Big Tech gatekeepers, Ars Technica, 02.01.2023, https://arstechnica.com/gadgets/2023/01/mastodon-highlights-pros-and-cons-of-moving-beyond-big-tech-gatekeepers/.
Kreutzer, Till (2006). Open-Source-Software zwischen Moral und Freiheit, iRights, 15.08.2006, https://irights.info/artikel/open-source-software-zwischen-moral-und-freiheit/6219.
Lemmer-Webber, Christine (2024). How decentralized is Bluesky really?, 22.11.2024, https://dustycloud.org/blog/how-decentralized-is-bluesky/.
Lemmer-Webber, Christine (2025). Toot, 19.01.2025, https://social.coop/@cwebber/113856458328842294.
Mastdon: Covenant (n.d.), https://joinmastodon.org/covenant.
Mastodon (2025). The people should own the town square, 13.01.2025, https://blog.joinmastodon.org/2025/01/the-people-should-own-the-town-square/.
Prodromou, Evan (2024). A Bigger Better Fediverse, presentation at Berlin Fediday 2024, 14.10.2024, https://berlinfedi.day/2024/.
Rochko, Eugen (2019). Gab switches to Mastodon’s code. Our statement, 04.07.2019, https://blog.joinmastodon.org/2019/07/statement-on-gabs-fork-of-mastodon/.
Rochko, Eugen (2023). What to know about Threads, 05.07.2023, https://blog.joinmastodon.org/2023/07/what-to-know-about-threads/.
SWF (2025). The Social Web Foundation announces its membership in the World Wide Web Consortium, 11.2.2025, https://socialwebfoundation.org/2025/02/11/the-social-web-foundation-announces-its-membership-in-the-world-wide-web-consortium/.
The Verge (2023). Threads is officially starting to test ActivityPub integration, 13.12.2023, https://www.theverge.com/2023/12/13/24000120/threads-meta-activitypub-test-mastodon.
Woźniak, Michał “rysiek” (2025). Eight years on, Mastodon stubbornly survives, personal blog, 05.04.2025, https://rys.io/en/177.html.
#Fediverse #FreeCulture #Internet #mediaScience #publicSphere
-
Is there any way to setup OAuth2 authentication on self-hosted ejabberd (where ejabberd acts as a client and delegates authentication to an external identity provider)?
Prosody seems to have modules for that, but I feel like migrating might be a pain...
-
This weekend project (yes, another one instead of finishing the 100 others) is a #fastcgi handler to implement xep-0070, alnowing to use an #xmpp account to log in to a website. Writing it in #rust as a learning exercise.
I hope to replace "login with google" and the other things I had to add to my website ovwr the years in order to not store people's passwords. This should allow to do it in a decentralized way without forcing any specific provider.
-
Just tested my Prosody server against the compliance checker at https://compliance.conversations.im My Prosody server got itself a 100% compliance rating, with in-band registration being disabled as it's more of a personal server than a public one, even with that public conference. If you want to see the results for yourself, check out https://compliance.conversations.im/server/simplygregario.us/ I will also point out that both Prosody and CoTurn (which provides media relay services for Prosody) are configured to be dual-stack, meaning everything works both on IPv4 and IPv6. Even got all 8 SRV records configured in DNS so CoTurn's STUN and TURN implementations will hopefully work flawlessly, both via TCP & UDP (and the TLS-based option is included). #Prosody #CoTurn #XMPP #StandardsCompliance #OwnYourData #SelfHosting
-
I've recently gotten hooked to the Gemini protocol. This obsession came about after I learned about the Tildeverse over XMPP, registered for tilde.pink, and started playing with the public_gemini directory. If you can write basic Markdown, you can write Gemtext with minimal differences. It is really easy to create a capsule (webpage) from nothing. As such, I loved it except for one small nitpick.
I am really used to using scripts for fun behaviour. For example, on my own webpage, I usually greet newcomers using their time of day instead of simple greetings like "good to see you" or "hello". I don't have a clue why I prefer this other than "it's funny". However, Gemini doesn't provide any means of scripting in their spec. As such, you cannot script Gemini capsules on most Gemini servers, including gmid which is used by tilde.pink.
I was thinking of solutions for this, and I concluded that I should probably look into templating and scheduled builds for this task. My reasoning for this is that it provides the illusion of scripted behaviour while remaining statically built for the small web. This could also be used in many Gemini servers as it creates Gemtext files from templates. This would make Gemini scriptable while retaining it's purpose.
I'm planning to design this in Ruby, mostly as an influence from Jekyll. If anyone wants to talk about it more with me, please let me know, as I am open to ideas. I also plan to write a post about the Tildeverse when I'm well rested. More specifically, about my thoughts regarding the community.
#tildeverse #tilde #geminiprotocol #web #programming #ruby #jekyll #tech #technology #opensource #SmallWeb
-
You have probably seen this #viral #infographic on #eu #digitalsovereignty by #reddit user u/lukakopajtic. It was viral but not very accurate 😅 recommending #bluesky and #firefox as "EU alternatives"? How? Anyway, he just updated the infographic, and it's much, much better! Most issues have been corrected. I think there is still a couple of issues I disagree with: 1) recommending #matrix instead of #jabber #xmpp 2) recommending #lineageos instead of #grapheneos (but OK, I can understand this if the focus is on self-sovereignty only), 3) recommending #droidify instead of #accrescent (but, even here, I can understand if the goal is to replace #playstore ), and 4) recommending #thunderbird as a comparison to #gmail (nothing wrong with Thunderbird, but that's an email client, not a Gmail-like suite provider, I would have rather recommended #mailfence or #mailbox ). Kudos for the initiative though, the intentions are good!
-
@kkarhan @monocles @Stuxhost @delta Thank you for your valuable input! It's always enlightening to hear different perspectives on communication tools.
#Linphone Firstly, I appreciate the mention of Linphone. It is indeed a great tool, and I should have included it in my list. Linphone stands out for its versatility and strong support for various communication protocols, making it a robust option for both personal and professional use.#DeltaChat is new to me, and I am eager to give it a try. However, I am curious: is it just another XMPP client, or does it offer unique features that set it apart? Generally, I prefer les feature-rich clients because I often use just simple text and voice communication. For my personal use case, XMPP is fine when it is compatible with TTS (Text-to-Speech). You're right that IRC and XMPP have their strengths, but I am always on the lookout for tools that I can offer to regular users.
#Signal and Session are both backed by single entities but prioritize user privacy. Personally, I don't have enough experience to delve deeply into the pros and cons of Signal and Session. A significant limitation of Signal is that I can't build the app from source code, and as far as I know, there is no real way to run it on a server OS—it's only available on iOS, Android, and via Waydroid on Linux, with wayland GUI. At least Session is working on x86 architectures. In general, I think both are useful for mainstream users due to their familiar interfaces and ease of use. While Signal and Session do a good job with privacy, they may not be the most secure options, and they certainly don't rank high on the Free Software scale. Would you agree with my evaluation, or could you elaborate on your criticism?
#Matrix is designed to be decentralized and open, allowing users to host their own servers. This decentralization provides greater control over data and enhances privacy. Comparing Matrix to XMPP+OMEMO might oversimplify its capabilities, as Matrix offers advanced features like cross-platform interoperability and robust end-to-end encryption. It's open-source, and I haven't seen any obvious problems with it. Could you elaborate on your thoughts about Matrix?
-
takahē - A new Fediverse paradigm
Fresh out of the oven is #Takahē, introducing a very interesting basic functional motive for development and delivering a beautiful #UX. It also derives inspiration in the form of its #mascott from a species once thought extinct for about a century.
That is, until a single man obsessed with the saga of this large, flightness bird since his early childhood, endlessly sought out and eventually rediscovered it was actually extant 75 years ago through his tireless efforts.
In recent years, and not without some particularly problematic attempts in the management of this #endangered species, the population of these magnificent birds has more or less stabilized at around 100 members living in the wild, thanks to the committed efforts of a government sponsored #refoliation, hatching, and rearing program; in conjunction with a comprehensive scientific tagging, tracking, and monitoring effort of those members released into the wild alongside the wild-born members of the #population.
The software project itself has struck me as rather special too, and not just for its two functionally unique characteristics amongst other #Fediverse platforms - first, and similar to name based #SSL hosting on #HTTP servers with #SNI, Takahē provides multi-domain virtual hosting capabilities to #ActivityPub - **this is huge**, and opens the door for for even the casusl home self-hoster to provide #turnkey #SaaS offerings to their friends and family members in the form of small and #single user "virtual Fediverse server instances", in consumer based home #LAN environments - let alone the potential for commercial hosting endeavors.
To my knowledge, ***this is the very first time* this novel approach to Fediverse networking over ActivityPub has been broached**.
jointakahe.org/
***If you hurry***, you might still be able to secure for yourself an account in their limited beta program.
Go ahead, you can do that now, I'll still be here when you get back 😎
And as if that alone were not enough to revolutionize the paradigm and dynamic of the Fediverse, **Takahē also introduces multiple account (alt) identities for each user user account on the server**. This can only be described as freaking groundbreaking!
A single user account for a person might be the base for say, both @[email protected] *AND* @userone@SLD02 .TLD02 *AND* @usertwo@SLD02 .TLD02 - that, at least to me, can only be described as, **"The Bees Knees"**.
I'm sure that many will cite, and of course it is not only possible but quite likely, that this will lower the bar for abusive actors to engage in shenanigans. However true as that may be, such potential (and existing practice) exists already within the Fediverse so the ease with which bad actors will avail themselves of such toolings only is only trivially simplified, not introduced; besides, complaining about such a thing is irrelevant - *the cat is already out of the bag*.
Indeed, there are already other Fediverse server platforms (such as the Hubzilla (ZOT) and Misskey families of forks and variants that already support the creation and management of multiple identities under a single account anyway - but Bringing the SNI shared hosting experience into production with a single Fediverse server instance is truly unprecedented in Fediverse space.
There's a lot more. **Did I mention the beautiful, and exceedingly intuitive UI?** Of course I did!
There's another corollary that I alluded to. Did you miss it? It was right there, *before your eyes*.
Yes, there's a metaphor, craftily scripted between the lines of everything you just read (that is, if you didn't tl;dr).
The impetus for much of #decentralization (DeSoc) and the #Genesis of the Fediverse is arguably the notion of what was indeed a #decentralized #World Wide Web over the fully decentralized #Internet, having falling victim to capture by special interests - the #deprecated, #proprietary, #privacy disrespecting and #legacy #monolithic silos - owned, spawned, and managed by mega surveillance-capitalism #data mining corporations.... IOW, the so-called, **Sunnyvale Syndrome**.
This effectively killed of much of the notion that there even still existed an independant, #distributed network of services and sites truly belonging to the #individual participants, i.e., average #schmoes like you and me.
For sometime now, many have even claimed and argued that the kinder, friendlier #web of days gone by, where small #communities of #people and #websites belonging to #individuals and small businesses were actually #extinct in reality - with only those well heeled analytically correct, SEO optimized, #subjugated websites and #chattel in the form of people that had sworn #fealty to their lords and masters remaining. #Apple, #Amazon, the #Google and #Faceplant having long since taken #possession of their souls and #identities.
It's dark, so *incredibly dark*. And you have awakened to find yourself at the bottom of a well that you *apparently* have fallen into. There's plenty of water, you're knee deep in it, and a voice from above booms aloud that food will be delivered so long as, ***"It puts the lotion on its skin!"***
And in a manner of speaking, following an *"Internet century"* (think, 'dog years') of a #dystopian #feudal Institution where _Homo sapien_ drones existing in #Lords and Vassals lockstep, told what to think, how to believe, where to shit, and when to wake up and punch the time clock, had completely replaced the actually extinct human race... Well?...
***Fast forwarding to the scene where...***
Some awkward little child in a dimly candlelit bedroom, many children, truth be told, consumed with the dreams of, and empowered with an obsessive belief that, a world where real, unique and independently diverse human beings actually existed, grew up and many years later *rediscovered that they really did still walk the earth*.
Kinda like the true story of the **Takahē**. And we too, *are beautiful*.
I'm leaving the rest for you to discover for yourselves, and look forward to many discussions on this invigorating topic. In the meantime, you can follow:
@takahe
I can be reached on Matrix at:
`@tallship:matrix.org`
via XMPP at:
`[email protected]`
and in the Fediverse at:
`@[email protected]`
I hope that helps! Enjoy!
#tallship #FOSS #virtual hosting #multiple identity #DeSoc #Sunnyvale Syndrome #AOL Effect
⛵
. -
#### takahē - A new Fediverse paradigm
#### 19 January 2023
Fresh out of the oven is #Takahē, introducing a very interesting basic functional motive for development and delivering a beautiful #UX. It also derives inspiration in the form of its #mascott from a species once thought extinct for about a century.
That is, until a single man obsessed with the saga of this large, flightness bird since his early childhood, endlessly sought out and eventually rediscovered it was actually extant 75 years ago through his tireless efforts.
In recent years, and not without some particularly problematic attempts in the management of this #endangered_species, the population of these magnificent birds has more or less stabilized at around 100 members living in the wild, thanks to the committed efforts of a government sponsored #refoliation, hatching, and rearing program; in conjunction with a comprehensive scientific tagging, tracking, and monitoring effort of those members released into the wild alongside the wild-born members of the #population.
The software project itself has struck me as rather special too, and not just for its two functionally unique characteristics amongst other #Fediverse platforms - first, and similar to name based #SSL hosting on #HTTP servers with #SNI, Takahē provides multi-domain virtual hosting capabilities to #ActivityPub - this is huge, and opens the door for for even the casusl home self-hoster to provide #turnkey #SaaS offerings to their friends and family members in the form of small and #single_user "virtual Fediverse server instances", in consumer based home #LAN environments - let alone the potential for commercial hosting endeavors.
To my knowledge, this is the very first time this novel approach to Fediverse networking over ActivityPub has been broached.
If you hurry, you might still be able to secure for yourself an account in their limited beta program.
Go ahead, you can do that now, I'll still be here when you get back 😎
And as if that alone were not enough to revolutionize the paradigm and dynamic of the Fediverse, Takahē also introduces multiple account (alt) identities for each user user account on the server. This can only be described as freaking groundbreaking!
A single user account for a person might be the base for say, both @[email protected] AND @userone@SLD02 .TLD02 AND @usertwo@SLD02 .TLD02 - that, at least to me, can only be described as, "The Bees Knees".
I'm sure that many will cite, and of course it is not only possible but quite likely, that this will lower the bar for abusive actors to engage in shenanigans. However true as that may be, such potential (and existing practice) exists already within the Fediverse so the ease with which bad actors will avail themselves of such toolings only is only trivially simplified, not introduced; besides, complaining about such a thing is irrelevant - the cat is already out of the bag.
Indeed, there are already other Fediverse server platforms (such as the Hubzilla (ZOT) and Misskey families of forks and variants that already support the creation and management of multiple identities under a single account anyway - but Bringing the SNI shared hosting experience into production with a single Fediverse server instance is truly unprecedented in Fediverse space.
There's a lot more. Did I mention the beautiful, and exceedingly intuitive UI? Of course I did!
There's another corollary that I alluded to. Did you miss it? It was right there, before your eyes.
Yes, there's a metaphor, craftily scripted between the lines of everything you just read (that is, if you didn't tl;dr).
The impetus for much of #decentralization (DeSoc) and the #Genesis of the Fediverse is arguably the notion of what was indeed a #decentralized #World_Wide_Web over the fully decentralized #Internet, having falling victim to capture by special interests - the #deprecated, #proprietary, #privacy_disrespecting and #legacy #monolithic_silos - owned, spawned, and managed by mega surveillance-capitalism #data_mining corporations.... IOW, the so-called, Sunnyvale Syndrome.
This effectively killed of much of the notion that there even still existed an independant, #distributed_network of services and sites truly belonging to the #individual_participants, i.e., average #schmoes like you and me.
For sometime now, many have even claimed and argued that the kinder, friendlier #web of days gone by, where small #communities of #people and #websites belonging to #individuals and small businesses were actually #extinct in reality - with only those well heeled analytically correct, SEO optimized, #subjugated websites and #chattel in the form of people that had sworn #fealty to their lords and masters remaining. #Apple, #Amazon, the #Google and #Faceplant having long since taken #possession of their souls and #identities.
It's dark, so incredibly dark. And you have awakened to find yourself at the bottom of a well that you apparently have fallen into. There's plenty of water, you're knee deep in it, and a voice from above booms aloud that food will be delivered so long as, "It puts the lotion on its skin!"
And in a manner of speaking, following an "Internet century" (think, 'dog years') of a #dystopian #feudal Institution where Homo sapien drones existing in #Lords_and_Vassals lockstep, told what to think, how to believe, where to shit, and when to wake up and punch the time clock, had completely replaced the actually extinct human race... Well?...
Fast forwarding to the scene where...
Some awkward little child in a dimly candlelit bedroom, many children, truth be told, consumed with the dreams of, and empowered with an obsessive belief that, a world where real, unique and independently diverse human beings actually existed, grew up and many years later rediscovered that they really did still walk the earth.
Kinda like the true story of the Takahē. And we too, are beautiful.
I'm leaving the rest for you to discover for yourselves, and look forward to many discussions on this invigorating topic. In the meantime, you can follow:
I can be reached on Matrix at:
@tallship:matrix.orgvia XMPP at:
and in the Fediverse at:
@[email protected]I hope that helps! Enjoy!
#tallship #FOSS #virtual_hosting #multiple_identity #DeSoc #Sunnyvale_Syndrome #AOL_Effect
⛵
.
-
Security Issues in Matrix’s Olm Library
I don’t consider myself exceptional in any regard, but I stumbled upon a few cryptography vulnerabilities in Matrix’s Olm library with so little effort that it was nearly accidental.
It should not be this easy to find these kind of issues in any product people purportedly rely on for private messaging, which many people evangelize incorrectly as a Signal alternative.
Later, I thought I identified an additional vulnerability that would have been much worse, but I was wrong about that one. For the sake of transparency and humility, I’ll also describe that in detail.
This post is organized as follows:
- Disclosure Timeline
- Vulnerabilities in Olm (Technical Details)
- Recommendations
- Background Information
- An Interesting Non-Issue That Looked Critical
I’ve opted to front-load the timeline and vulnerability details to respect the time of busy security professionals.
Please keep in mind that this website is a furry blog, first and foremost, that sometimes happens to cover security and cryptography topics.
Many people have, over the years, assumed the opposite and commented accordingly. The ensuing message board threads are usually is a waste of time and energy for everyone involved. So please adjust your expectations.
Art by HarubakiIf you’re curious, you can learn more here.
Disclosure Timeline
- 2024-05-15: I took a quick look at the Matrix source code. I identified two issues and emailed them to their
security@email address.In my email, I specify that I plan to disclose my findings publicly in 90 days (i.e. on August 14), in adherence with industry best practices for coordinated disclosure, unless they request an extension in writing.
- 2024-05-16: I checked something else on a whim and find a third issue, which I also email to their
security@email address. - 2024-05-17: Matrix security team confirms receipt of my reports.
- 2024-05-17: I follow up with a suspected fourth finding–the most critical of them all. They point out that it is not actually an issue, because I overlooked an important detail in how the code is architected. Mea culpa!
- 2024-05-18: A friend discloses a separate finding with Matrix: Media can be decrypted to multiple valid plaintexts using different keys and Malicious homeservers can trick Element/Schildichat into revealing links in E2EE rooms.
They instructed the Matrix developers to consult with me if they needed cryptography guidance. I never heard from them on this externally reported issue.
- 2024-07-12: I shared this blog post draft with the Matrix security team while reminding them of the public disclosure date.
- 2024-07-31: Matrix pushes a commit that announces that libolm is deprecated.
- 2024-07-31: I email the Matrix security team asking if they plan to fix the reported issues (and if not, if there’s any other reason I should withhold publication).
- 2024-07-31: Matrix confirms they will not fix these issues (due to its now deprecated status), but ask that I withhold publication until the 14th as originally discussed.
- 2024-08-14: This blog post is publicly disclosed to the Internet.
- 2024-08-14: The lead Matrix dev claims they already knew about these issues, and, in fact, knowingly shipped cryptography code that was vulnerable to side-channel attacks for years. See Addendum.
- 2024-08-23: MITRE has assigned CVE IDs to these three findings.
Vulnerabilities in Olm
I identified the following issues with Olm through a quick skim of their source code on Gitlab:
- AES implementation is vulnerable to cache-timing attacks
- Ed25519 signatures are malleable
- Timing leakage in base64 decoding of private key material
This is sorted by the order in which they were discovered, rather than severity.
AES implementation is vulnerable to cache-timing attacks
a.k.a. CVE-2024-45191
Olm ships a pure-software implementation of AES, rather than leveraging hardware acceleration.
// Substitutes a word using the AES S-Box.WORD SubWord(WORD word){unsigned int result;result = (int)aes_sbox[(word >> 4) & 0x0000000F][word & 0x0000000F];result += (int)aes_sbox[(word >> 12) & 0x0000000F][(word >> 8) & 0x0000000F] << 8;result += (int)aes_sbox[(word >> 20) & 0x0000000F][(word >> 16) & 0x0000000F] << 16;result += (int)aes_sbox[(word >> 28) & 0x0000000F][(word >> 24) & 0x0000000F] << 24;return(result);}The code in question is called from this code, which is in turn used to actually encrypt messages.
Software implementations of AES that use a look-up table for the SubWord step of the algorithm are famously susceptible to cache-timing attacks.
This kind of vulnerability in software AES was previously used to extract a secret key from OpenSSL and dm-crypt in about 65 milliseconds. Both papers were published in 2005.
A general rule in cryptography is, “attacks only get better; they never get worse“.
As of 2009, you could remotely detect a timing difference of about 15 microseconds over the Internet with under 50,000 samples. Side-channel exploits are generally statistical in nature, so such a sample size is generally not a significant mitigation.
How is this code actually vulnerable?
In the above code snippet, the vulnerability occurs in
aes_sbox[/* ... */][/* ... */].Due to the details of how the AES block cipher works, the input variable (
word) is a sensitive value.Software written this way allows attackers to detect whether or not a specific value was present in one of the processor’s caches.
To state the obvious: Cache hits are faster than cache misses. This creates an observable timing difference.
Such a timing leak allows the attacker to learn the value that was actually stored in said cache. You can directly learn this from other processes on the same hardware, but it’s also observable over the Internet (with some jitter) through the normal operation of vulnerable software.
See also: cryptocoding’s description for table look-ups indexed by secret data.
How to mitigate this cryptographic side-channel
The correct way to solve this problem is to use hardware accelerated AES, which uses distinct processor features to implement the AES round function and side-steps any cache-timing shenanigans with the S-box.
Not only is this more secure, but it’s faster and uses less energy too!
If you’re also targeting devices that don’t have hardware acceleration available, you should first use hardware acceleration where possible, but then fallback to a bitsliced implementation such as the one in Thomas Pornin’s BearSSL.
See also: the BearSSL documentation for constant-time AES.
Art by AJEd25519 signatures are malleable
a.k.a. CVE-2024-45193
Ed25519 libraries come in various levels of quality regarding signature validation criteria; much to the chagrin of cryptography engineers everywhere. One of those validation criteria involves signature malleability.
Signature malleability usually isn’t a big deal for most protocols, until suddenly you discover a use case where it is. If it matters, that usually that means you’re doing something with cryptocurrency.
Briefly, if your signatures are malleable, that means you can take an existing valid signature for a given message and public key, and generate a second valid signature for the same message. The utility of this flexibility is limited, and the impact depends a lot on how you’re using signatures and what properties you hope to get out of them.
For ECDSA, this means that for a given signature , a second signature is also possible (where is the order of the elliptic curve group you’re working with).
Matrix uses Ed25519, whose malleability is demonstrated between and .
This is trivially possible because S is implicitly reduced modulo the order of the curve, , which is a 253-bit number (
0x1000000000000000000000000000000014def9dea2f79cd65812631a5cf5d3ed) and S is encoded as a 256-bit number.The Ed25519 library used within Olm does not ensure that , thus signatures are malleable. You can verify this yourself by looking at the Ed25519 verification code.
int ed25519_verify(const unsigned char *signature, const unsigned char *message, size_t message_len, const unsigned char *public_key) { unsigned char h[64]; unsigned char checker[32]; sha512_context hash; ge_p3 A; ge_p2 R; if (signature[63] & 224) { return 0; } if (ge_frombytes_negate_vartime(&A, public_key) != 0) { return 0; } sha512_init(&hash); sha512_update(&hash, signature, 32); sha512_update(&hash, public_key, 32); sha512_update(&hash, message, message_len); sha512_final(&hash, h); sc_reduce(h); ge_double_scalarmult_vartime(&R, h, &A, signature + 32); ge_tobytes(checker, &R); if (!consttime_equal(checker, signature)) { return 0; } return 1;}This is almost certainly a no-impact finding (or low-impact at worst), but still an annoying one to see in 2024.
If you’d like to learn more, this page is a fun demo of Ed25519 malleability.
To mitigate this, I recommend implementing these checks from libsodium.
Art: CMYKatTiming leakage in base64 decoding of private key material
a.k.a. CVE-2024-45192
If you weren’t already tired of cache-timing attacks based on table look-ups from AES, the Matrix base64 code is also susceptible to the same implementation flaw.
while (pos != end) { unsigned value = DECODE_BASE64[pos[0] & 0x7F]; value <<= 6; value |= DECODE_BASE64[pos[1] & 0x7F]; value <<= 6; value |= DECODE_BASE64[pos[2] & 0x7F]; value <<= 6; value |= DECODE_BASE64[pos[3] & 0x7F]; pos += 4; output[2] = value; value >>= 8; output[1] = value; value >>= 8; output[0] = value; output += 3;}The base64 decoding function in question is used to load the group session key, which means the attack published in this paper almost certainly applies.
How would you mitigate this leakage?
Steve Thomas (one of the judges of the Password Hashing Competition, among other noteworthy contributions) wrote some open source code a while back that implements base64 encoding routines in constant-time.
The real interesting part is how it avoids a table look-up by using arithmetic (from this file):
// Base64 character set:// [A-Z] [a-z] [0-9] + /// 0x41-0x5a, 0x61-0x7a, 0x30-0x39, 0x2b, 0x2finline int base64Decode6Bits(char src){int ch = (unsigned char) src;int ret = -1;// if (ch > 0x40 && ch < 0x5b) ret += ch - 0x41 + 1; // -64ret += (((0x40 - ch) & (ch - 0x5b)) >> 8) & (ch - 64);// if (ch > 0x60 && ch < 0x7b) ret += ch - 0x61 + 26 + 1; // -70ret += (((0x60 - ch) & (ch - 0x7b)) >> 8) & (ch - 70);// if (ch > 0x2f && ch < 0x3a) ret += ch - 0x30 + 52 + 1; // 5ret += (((0x2f - ch) & (ch - 0x3a)) >> 8) & (ch + 5);// if (ch == 0x2b) ret += 62 + 1;ret += (((0x2a - ch) & (ch - 0x2c)) >> 8) & 63;// if (ch == 0x2f) ret += 63 + 1;ret += (((0x2e - ch) & (ch - 0x30)) >> 8) & 64;return ret;}Any C library that handles base64 codecs for private key material should use a similar implementation. It’s fine to have a faster base64 implementation for non-secret data.
Worth noting: Libsodium also provides a reasonable Base64 codec.
Recommendations
These issues are not fixed in libolm.
Instead of fixing libolm, the Matrix team recommends all Matrix clients adopt vodozemac.
I can’t speak to the security of vodozemac.
Art: CMYKatBut I can speak against the security of libolm, so moving to vodozemac is probably a good idea. It was audited by Least Authority at one point, so it’s probably fine.
Most Matrix clients that still depended on libolm should treat this blog as public 0day, unless the Matrix security team already notified you about these issues.
Background Information
If you’re curious about the backstory and context of these findings, read on.
Otherwise, feel free to skip this section. It’s not pertinent to most audiences. The people that need to read it already know who they are.
End-to-end encryption is one of the topics within cryptography that I find myself often writing about.
In 2020, I wrote a blog post covering end-to-end encryption for application developers. This was published several months after another blog I wrote covering gripes with AES-GCM, which included a shallow analysis of how Signal uses the algorithm for local storage.
In 2021, I published weaknesses in another so-called private messaging app called Threema.
In 2022, after Elon Musk took over Twitter, I joined the Fediverse and sought to build end-to-end encryption support for direct messages into ActivityPub, starting with a specification. Work on this effort was stalled while trying to solve Public Key distribution in a federated environment (which I hope to pick up soon, but I digress).
Earlier this year, the Telegram CEO started fearmongering about Signal with assistance from Elon Musk, so I wrote a blog post urging the furry fandom to move away from Telegram and start using Signal more. As I had demonstrated years prior, I was familiar with Signal’s code and felt it was a good recommendation for security purposes (even if its user experience needs significant work).
I thought that would be a nice, self-contained blog post. Some might listen, most would ignore it, but I could move on with my life.
I was mistaken about that last point.
Art by AJAn overwhelming number of people took it upon themselves to recommend or inquire about Matrix, which prompted me to hastily scribble down my opinion on Matrix so that I might copy/paste a link around and save myself a lot of headache.
Just when I thought the firehose was manageable and I could move onto other topics, one of the Matrix developers responded to my opinion post.
Thus, I decided to briefly look at their source code and see if any major or obvious cryptography issues would fall out of a shallow visual scan.
Since you’re reading this post, you already know how that ended.
Credit: CMYKatSince the first draft of this blog post was penned, I also outlined what I mean when I say an encrypted messaging app is a Signal competitor or not, and published my opinion on XMPP+OMEMO (which people also recommend for private messaging).
Why mention all this?
Because it’s important to know that I have not audited the Olm or Megolm codebases, nor even glanced at their new Rust codebase.
The fact is, I never intended to study Matrix. I was annoyed into looking at it in the first place.
My opinion of their project was already calcified by the previously discovered practically-exploitable cryptographic vulnerabilities in Matrix in 2022.
The bugs described above are the sort of thing I mentally scan for when I first look at a project just to get a feel for the maturity of the codebase. I do this with the expectation (hope, really) of not finding anything at all.
(If you want two specific projects that I’ve subjected to a similar treatment, and failed to discover anything interesting in: Signal and WireGuard. These two set the bar for cryptographic designs.)
It’s absolutely bonkers that an AES cache timing vulnerability was present in their code in 2024.
It’s even worse when you remember that I was inundated with Matrix evangelism in response to recommending furries use Signal.
I’m a little outraged because of how irresponsible this is, in context.
It’s so bad that I didn’t even need to clone their git repository, let alone run basic static analysis tools locally.
So if you take nothing else away from this blog post, let it be this:
There is roughly a 0% chance that I got extremely lucky in my mental
grepand found the only cryptography implementation flaws in their source code. I barely tried at all and found these issues.I would bet money on there being more bugs or design flaws that I didn’t find, because this discovery was the result of an extremely half-assed effort to blow off steam.
Wasn’t libolm deprecated in May 2022?
The Matrix developers like to insist that their new Rust hotness “vodozemac” is what people should be using today.
I haven’t looked at vodozemac at all, but let’s pretend, for the sake of argument, that its cryptography is actually secure.
(This is very likely if they turn out to be using RustCrypto for their primitives, but I don’t have the time or energy for that nerd snipe, so I’m not going to look. Least Authority did audit their Rust library, for what it’s worth, and Least Authority isn’t clownshoes.)
It’s been more than 2 years since they released vodozemac. What does the ecosystem penetration for this new library look like, in practice?
A quick survey of the various Matrix clients on GitHub says that libolm is still the most widely used cryptography implementation in the Matrix ecosystem (as of this writing):
Matrix ClientCryptography Backendhttps://github.com/tulir/gomukslibolm (1, 2)https://github.com/niochat/niolibolm (1, 2)https://github.com/ulyssa/iambvodozemac (1, 2)https://github.com/mirukana/miragelibolm (1)https://github.com/Pony-House/Clientlibolm (1)https://github.com/MTRNord/cetirizinevodozemac (1)https://github.com/nadams/go-matrixclinonehttps://github.com/mustang-im/mustanglibolm (1)https://github.com/marekvospel/libretrixlibolm (1)https://github.com/yusdacra/icy_matrixnonehttps://github.com/ierho/elementlibolm (through the python SDK)https://github.com/mtorials/cordlessnonehttps://github.com/hwipl/nuqql-matrixdlibolm (through the python SDK)https://github.com/maxkratz/element-webvodozemac (1, 2, 3, 4)https://github.com/asozialesnetzwerk/riotlibolm (wasm file)https://github.com/NotAlexNoyle/Versilibolm (1, 2)3 of the 16 clients surveyed use the new vodozemac library. 10 still use libolm, and 3 don’t appear to implement end-to-end encryption at all.
If we only focus on clients that support E2EE, vodozemac has successfully been adopted by 19% of the open source Matrix clients on GitHub.
I deliberately excluded any repositories that were archived or clearly marked as “old” or “legacy” software, because including those would artificially inflate the representation of libolm. It would make for a more compelling narrative to do so, but I’m not trying to be persuasive here.
Deprecation policies are a beautiful lie. The impact of a vulnerability in Olm or Megolm is still far-reaching, and should be taken seriously by the Matrix community.
Worth calling out: this quick survey, which is based on a GitHub Topic, certainly misses other implementations. Both FluffyChat and Cinny, which were not tagged with this GitHub Topic, depend a language-specific Olm binding.
These bindings in turn wrap libolm rather than the Rust replacement, vodozemac.
But the official clients…
I thought the whole point of choosing Matrix over something like Signal is to be federated, and run your own third-party clients?
If we’re going to insist that everyone should be using Element if they want to be secure, that defeats the entire marketing point about third-party clients that Matrix evangelists cite when they decry Signal’s centralization.
So I really don’t want to hear it.
CMYKatAn Interesting Non-Issue That Looked Critical
As I mentioned in the timeline at the top, I thought I found a fourth issue with Matrix’s codebase. Had I been correct, this would have been a critical severity finding that the entire Matrix ecosystem would need to melt down to remediate.
Fortunately for everyone, I made a mistake, and there is no fourth vulnerability after all.
However, I thought it would be interesting to write about what I thought I found, the impact it would have had if it were real, and why I believed it to be an issue.
Let’s start with the code in question:
void ed25519_sign(unsigned char *signature, const unsigned char *message, size_t message_len, const unsigned char *public_key, const unsigned char *private_key) { sha512_context hash; unsigned char hram[64]; unsigned char r[64]; ge_p3 R; sha512_init(&hash); sha512_update(&hash, private_key + 32, 32); sha512_update(&hash, message, message_len); sha512_final(&hash, r); sc_reduce(r); ge_scalarmult_base(&R, r); ge_p3_tobytes(signature, &R); sha512_init(&hash); sha512_update(&hash, signature, 32); sha512_update(&hash, public_key, 32); sha512_update(&hash, message, message_len); sha512_final(&hash, hram); sc_reduce(hram); sc_muladd(signature + 32, hram, private_key, r);}The highlighted segment is doing pointer arithmetic. This means it’s reading 32 bytes, starting from the 32nd byte in
private_key.What’s actually happening here is:
private_keyis the SHA512 hash of a 256-bit seed. If you look at the function prototype, you’ll notice thatpublic_keyis a separate input.Virtually every other Ed25519 implementation I’ve ever looked at before expected users to provide a 32 byte seed followed by the public key as a single input.
This led me to believe that this
private_key + 32pointer arithmetic was actually using the public key for calculatingr.The variable
r(not to be confused with big R) generated via the first SHA512 is the nonce for a given signature, it must remain secret for Ed25519 to remain secure.If
ris known to an attacker, you can do some arithmetic to recover the secret key from a single signature.Because I had mistakenly believed that
Credit: CMYKatrwas calculated from the SHA512 of only public inputs (the public key and message), which I must emphasize isn’t correct, I had falsely concluded that any previously intercepted signature could be used to steal user’s private keys.But because
private_keywas actually the full SHA512 hash of the seed, rather than the seed concatenated with the public key, this pointer arithmetic did NOT use the public key for the calculation ofr, so this vulnerability does not exist.If the code did what I thought it did, however, this would have been a complete fucking disaster for the Matrix ecosystem. Any previously intercepted message would have allowed an attacker to recover a user’s secret key and impersonate them. It wouldn’t be enough to fix the code; every key in the ecosystem would need to be revoked and rotated.
Whew!
I’m happy to be wrong about this one, because that outcome is a headache nobody wants.
So no action is needed, right?
Well, maybe.
Matrix’s library was not vulnerable, but I honestly wouldn’t put it past software developers at large to somehow, somewhere, use the public key (rather than a secret value) to calculate the EdDSA signature nonces as described in the previous section.
To that end, I would like to propose a test vector be added to the Wycheproof test suite to catch any EdDSA implementation that misuses the public key in this way.
Then, if someone else screws up their Ed25519 implementation in the exact way I thought Matrix was, the Wycheproof tests will catch it.
For example, here’s a vulnerable test input for Ed25519:
{ "should-fail": true, "secret-key": "d1d0ef849f9ec88b4713878442aeebca5c7a43e18883265f7f864a8eaaa56c1ef3dbb3b71132206b81f0f3782c8df417524463d2daa8a7c458775c9af725b3fd", "public-key": "f3dbb3b71132206b81f0f3782c8df417524463d2daa8a7c458775c9af725b3fd", "message": "Test message", "signature": "ffc39da0ce356efb49eb0c08ed0d48a1cadddf17e34f921a8d2732a33b980f4ae32d6f5937a5ed25e03a998e4c4f5910c931b31416e143965e6ce85b0ea93c09"}A similar test vector would also be worth creating for Ed448, but the only real users of Ed448 were the authors of the xz backdoor, so I didn’t bother with that.
(None of the Project Wycheproof maintainers knew this suggestion is coming, by the way, because I was respecting the terms of the coordinated disclosure.)
Closing Thoughts
Despite finding cryptography implementation flaws in Matric’s Olm library, my personal opinion on Matrix remains largely unchanged from 2022. I had already assumed it would not meet my bar for security.
Cryptography engineering is difficult because the vulnerabilities you’re usually dealing with are extremely subtle. (Here’s an unrelated example if you’re not convinced of this general observation.) As SwiftOnSecurity once wrote:
https://twitter.com/SwiftOnSecurity/status/832058185049579524
The people that developed Olm and Megolm has not proven themselves ready to build a Signal competitor. In balance, most teams are not qualified to do so.
I really wish the Matrix evangelists would accept this and stop trying to cram Matrix down other people’s throats when they’re talking about problems with other platforms entirely.
More important for the communities of messaging apps:
You don’t need to be a Signal competitor. Having E2EE is a good thing on its own merits, and really should be table stakes for any social application in 2024.
It’s only when people try to advertise their apps as a Signal alternative (or try to recommend it instead of Signal), and offer less security, that I take offense.
Just be your own thing.
My work-in-progress proposal to bring end-to-end encryption to the Fediverse doesn’t aim to compete with Signal. It’s just meant to improve privacy, which is a good thing to do on its own merits.
If I never hear Matrix evangelism again after today, it would be far too soon.
If anyone feels like I’m picking on Matrix, don’t worry: I have far worse things to say about Telegram, Threema, XMPP+OMEMO, Tox, and a myriad other projects that are hungry for Signal’s market share but don’t measure up from a cryptographic security perspective.
If Signal fucked up as bad as these projects, my criticism of Signal would be equally harsh. (And remember, I have looked at Signal before.)
Addendum (2024-08-14)
One of the lead Matrix devs posted a comment on Hacker News after this blog post went live that I will duplicate here:
the author literally picked random projects from github tagged as matrix, without considering their prevalence or whether they are actually maintained etc.
if you actually look at % of impacted clients, it’s tiny.
meanwhile, it is very unclear that any sidechannel attack on a libolm based client is practical over the network (which is why we didn’t fix this years ago). After all, the limited primitives are commented on in the readme and https://github.com/matrix-org/olm/issues/3 since day 1.
So the Matrix developers already knew about these vulnerabilities, but deliberately didn’t fix them, for years.
Congratulations, you’ve changed my stance. It used to be “I don’t consider Matrix a Signal alternative and they’ve had some embarrassing and impactful crypto bugs but otherwise I don’t care”. Now it’s a stronger stance:
Don’t use Matrix.
I had incorrectly assumed ignorance, when it was in fact negligence.
There’s no reasonable world in which anyone should trust the developers of cryptographic software (i.e., libolm) that deliberately ships with side-channels for years, knowing they’re present, and never bother to fix them.
This is fucking clownshoes.
If you’re curious about the cryptography used by other messaging apps, please refer to this page that collects my blogs about this topic.
#crypto #cryptography #endToEndEncryption #Matrix #sideChannels #vuln
-
Our hosting bill for https://poddery.com this month was 3492 INR (36.8 EUR). We provide #XMPP and #Matrix services to public.
It is run by volunteers of Free Software Community of India #fsci
@bady @kannan @sahil @ravi and many more.
Its costs are met through donations. So please consider donating or volunteering today. There is also non technical tasks like fund raising. See https://fsci.in/donate
If you are outside India buying us #Hetzner credits would be better.
-
For Twisted/XMPP developers: I've published Tx-XMPP, a (friendly) fork of Wokkel due to it being unmaintained for years. I've merged several PRs that I needed, along with code from `sat_tmp`, which was a "temporary" package to monkey-patch Wokkel to add those changes (finally not needed anymore after 11+ years!).
https://pypi.org/project/tx-xmpp/
I will provide minimal maintenance to keep it up-to-date with the latest versions of Twisted and Python.
-
For Twisted/XMPP developers: I've published Tx-XMPP, a (friendly) fork of Wokkel due to it being unmaintained for years. I've merged several PRs that I needed, along with code from `sat_tmp`, which was a "temporary" package to monkey-patch Wokkel to add those changes (finally not needed anymore after 11+ years!).
https://pypi.org/project/tx-xmpp/
I will provide minimal maintenance to keep it up-to-date with the latest versions of Twisted and Python.
-
For Twisted/XMPP developers: I've published Tx-XMPP, a (friendly) fork of Wokkel due to it being unmaintained for years. I've merged several PRs that I needed, along with code from `sat_tmp`, which was a "temporary" package to monkey-patch Wokkel to add those changes (finally not needed anymore after 11+ years!).
https://pypi.org/project/tx-xmpp/
I will provide minimal maintenance to keep it up-to-date with the latest versions of Twisted and Python.
-
For Twisted/XMPP developers: I've published Tx-XMPP, a (friendly) fork of Wokkel due to it being unmaintained for years. I've merged several PRs that I needed, along with code from `sat_tmp`, which was a "temporary" package to monkey-patch Wokkel to add those changes (finally not needed anymore after 11+ years!).
https://pypi.org/project/tx-xmpp/
I will provide minimal maintenance to keep it up-to-date with the latest versions of Twisted and Python.
-
For Twisted/XMPP developers: I've published Tx-XMPP, a (friendly) fork of Wokkel due to it being unmaintained for years. I've merged several PRs that I needed, along with code from `sat_tmp`, which was a "temporary" package to monkey-patch Wokkel to add those changes (finally not needed anymore after 11+ years!).
https://pypi.org/project/tx-xmpp/
I will provide minimal maintenance to keep it up-to-date with the latest versions of Twisted and Python.
-
@dnkrupinski @prav since Prav is part of the #XMPP network, people who don't want to provide a phone number can choose any XMPP app/service to talk to #Prav users. In that sense, phone number is optional. It makes a few things easier for people who are ok to use phone number like in other mainstream messengers. But unlike those other mainstream options like WhatsApp, Telegram or Signal, we don't lock people to Prav. For example, you can use Monocles Chat and talk to Prav users.
-
Happy Birthday to #InstantMessaging and #RealTimeCommunication with #XMPP!
Emerged from the #Jabber #community in 1999 and originally designed to provide an open and #decentralised alternative to #ICQ and #MSN, XMPP evolved to an independent alternative for todays #chat apps.
#rtc #whatsapp #signal
