Search
1000 results for “xmpp_providers”
-
@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?
-
Iran blocks Signal messaging app after WhatsApp exodus... BUT many wonder why WhatsApp and Instagram are not blocked
This is pretty puzzling as we know Signal is reputed to be secure (apart from having to provide a phone number to register) and although Telegram's default settings allow access to metadata and even message content ultimately, both have been banned because they have been proven before not to release any user data.
But why was WhatsApp not banned in Iran, and neither in Russia previously either? This is what is really puzzling many people? It would be pure unfounded conjecture to speculate whether WhatsApp provides metadata about who contacts whom, locations, etc to authorities as we've not seen evidence of this yet as far as I know. We do not know this but all the same, the question does need to be asked.
If you are in Iran I'd recommend though that you install XMPP, or P2P apps such as ManyVerse or similar anyway as centralised apps are just too easy to monitor or disable. https://squeet.me/objects/962c3e10902855c52e7485201c0902edc69c4fe2 -
@hardwyrd #ActivityPub integration would be more appropriate for the comments system. #CactusComments creates one-off rooms for separate articles on a whim, which is almost the same fragmentation problem as #XMPP for #PeerTube live chats. OK, former at least provides user a room link, but it's still the wrong tool for the job.
-
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
-
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
-
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
-
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
-
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...
-
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...
-
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...
-
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...
-
@hardwyrd #ActivityPub integration would be more appropriate for the comments system. #CactusComments creates one-off rooms for separate articles on a whim, which is almost the same fragmentation problem as #XMPP for #PeerTube live chats. OK, former at least provides user a room link, but it's still the wrong tool for the job.
-
@hardwyrd #ActivityPub integration would be more appropriate for the comments system. #CactusComments creates one-off rooms for separate articles on a whim, which is almost the same fragmentation problem as #XMPP for #PeerTube live chats. OK, former at least provides user a room link, but it's still the wrong tool for the job.
-
@hardwyrd #ActivityPub integration would be more appropriate for the comments system. #CactusComments creates one-off rooms for separate articles on a whim, which is almost the same fragmentation problem as #XMPP for #PeerTube live chats. OK, former at least provides user a room link, but it's still the wrong tool for the job.
-
@hardwyrd #ActivityPub integration would be more appropriate for the comments system. #CactusComments creates one-off rooms for separate articles on a whim, which is almost the same fragmentation problem as #XMPP for #PeerTube live chats. OK, former at least provides user a room link, but it's still the wrong tool for the job.
-
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
-
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
-
Finally participating in #oggcastplanet on Freenode without the Riot client! Thank you. ❤
Finally I had to register an XMPP account with you as well. At least I think I needed to do it. Either way, I did it. I think my good old provider is behind the times on several XEPs, and perhaps also has some kind of connectivity issues. -
Iran blocks Signal messaging app after WhatsApp exodus... BUT many wonder why WhatsApp and Instagram are not blocked
This is pretty puzzling as we know Signal is reputed to be secure (apart from having to provide a phone number to register) and although Telegram's default settings allow access to metadata and even message content ultimately, both have been banned because they have been proven before not to release any user data.
But why was WhatsApp not banned in Iran, and neither in Russia previously either? This is what is really puzzling many people? It would be pure unfounded conjecture to speculate whether WhatsApp provides metadata about who contacts whom, locations, etc to authorities as we've not seen evidence of this yet as far as I know. We do not know this but all the same, the question does need to be asked.
If you are in Iran I'd recommend though that you install XMPP, or P2P apps such as ManyVerse or similar anyway as centralised apps are just too easy to monitor or disable. https://squeet.me/objects/962c3e10902855c52e7485201c0902edc69c4fe2 -
Client email alternativi e open source
Indice dei contenuti
Client email alternativi e open sourceThunderbirdMailspringSylpheedClaws MailBetterbirdAltri programmi di posta per desktopClient email alternativi e open source per smartphoneFairEmailK-9 Mailp≡pDelta ChatAltri programmi di posta per smartphone
Finalmente, dopo tanto tempo, siamo riusciti a creare un articolo sui client email alternativi e open source! Era da tanto tempo che ce l’avevate chiesto e ci abbiamo messo un po’ a provarli e a scoprirne di nuovi. Come sapete cerchiamo di fare sempre le cose con calma, provando i vari sistemi proposti e analizzando i vari pro e contro.
Per quanto riguarda i client email alternativi abbiamo trovato un po’ di programmi anche se la situazione non è proprio del tutto rosea: principalmente esiste soprattutto Mozilla Thunderbird e altri software più o meno simili.
Client email alternativi e open source
Vogliamo ricordare inoltre che i programmi di posta funzionano con la stragrande maggioranza di provider email ma non con tutti. Ad esempio se utilizzate Tutanota non potete utilizzare esclusivamente la loro applicazione disponibile per tutte le piattaforme. Per quanto riguarda Proton Mail invece potete utilizzare un client esterno ma solo ed esclusivamente se siete un utente a pagamento e utilizzando il loro bridge.
Il problema nasce principalmente dal fatto che questi provider criptano tutte le email sui loro server e non possono quindi utilizzare come tutti gli altri il protocollo IMAP senza perdere la crittografia.
Thunderbird
open source
Probabilmente è ad oggi il re indiscussi dei client email alternativi e open source. È forse anche il più vecchio e famoso client email. È sviluppato dalla MZLA Technologies Corporation, sussidiaria della Mozilla Foundation dal lontano 2003. Permette di gestire email, newsgroup, RSS e addirittura chat (XMPP, IRC e da poco anche Matrix 1). Da non molto tempo ha acquisito il software open source K-9 Mail entrando in questo modo ufficialmente nel mondo mobile (probabilmente un po’ troppo in ritardo ma speriamo possa recuperare).
Mailspring
open source
anche in versione a pagamento
Dopo Thunderbird probabilmente una delle realtà su desktop più interessanti è Mailspring. Esteticamente è assolutamente gradevole e moderno. È gratuito ma alcune caratteristiche come ad esempio l’invio programmato sono a pagamento. Il costo purtroppo non è contenuto e l’abbonamento costa 8$ al mese.
È disponibile per Windows, macOS e Linux.Sylpheed
open source
A chi non interessa troppo l’aspetto estetico ma è interessato soprattutto alla stabilità Sylpheed può essere il software adatto. È il più vecchio programma di posta di questa lista, la prima release risale infatti al 2000. È giapponese ma tradotto interamente in inglese. L’ultima release risale al 2018 ma, come detto, non dà problemi di alcun tipo.
È disponibile per Windows, macOS e Linux.•
codice sorgente
Claws Mail
open source
Claws Mail è un fork indipendente di Sylpheed. A differenza di quest’ultimo lo sviluppo non è fermo al 2018 ma viene costantemente aggiornato. Troviamo sia davvero molto interessante e ben fatto e se non trovate gradevole Thunderbird o Mailspring è sicuramente un’ottima opzione per desktop.
Betterbird
open source
Betterbird è invece un fork di Thunderbird che si basa sull’ultima versione ESR (Extended Support Releases) evitando così di ricevere gli ultimissimi aggiornamenti ma avendo sempre una versione in qualche modo più stabile e senza troppi bug. È perfettamente compatibile con Thunderbird e con eventuali plugin.
Altri programmi di posta per desktop
Kube, questo programma di posta è disponibile sia per Linux che per macOS. Il suo progetto però sembra fermo al 2020.
LucaMail è un progetto open source che però sembra un po’ fermo e con un sito web non più raggiungibile. Non siamo quindi eccessivamente sicuri che ci si possa fidare.
Client email alternativi e open source per smartphone
Anche su smartphone ci sono diverse applicazioni, come abbiamo già detto a inizio articolo parleremo anche di K-9 che dovrebbe diventare Thunderbird Mail dopo l’acquisizione.
FairEmail
open source
anche in versione a pagamento
È probabilmente l’applicazione più completa in assoluto per quanto riguarda gli smartphone Android. Ha pressoché tutto e quello che non trovate è sicuramente incluso nella versione a pagamento. La versione a pagamento non è disponibile esclusivamente sul Play Store ma potete farla anche utilizzando l’applicazione su F-Droid.
K-9 Mail
open source
Graficamente è moderna, forse eccessivamente minimalista per quanto riguarda le opzioni disponibili. A parte questo comunque ha pochi difetti e con l’acquisizione da parte di Thunderbird speriamo diventi sempre migliore!
Esistono inoltre due importanti fork di K-9 Mail che vi segnaliamo:
Librem Mail 2, del progetto Librem One e disponibile esclusivamente sul Play Store
Monocles Mail 3 fa parte del progetto Monocles, un insieme di servizi aperti, liberi, gratuiti e personalizzati con il loro brand. Loro la sponsorizzano principalmente per il loro servizio mail monocles.de ma è possibile usarla per qualsiasi altro provider.
p≡p
open source
Un client email per smartphone davvero particolare. Intanto è il programma predefinito all’interno degli smartphone iodé. Inoltre è il più semplice da utilizzare con PGP, dunque se la vostra idea è quella di utilizzare PGP per le vostre email allora probabilmente dovete assolutamente dare una possibilità a p≡p, che si legge pEp (Pretty Easy Privacy).
Oltre alle versioni mobile esistono anche estensioni per Outlook e Thunderbird.Delta Chat
open source
Menzione d’onore per il mitico Delta Chat, che abbiamo già visto come alternativa a WhatsApp. In pratica permette di utilizzare le email come chat, dunque è in tutto e per tutto un client email ma con una grafica e un metodo di visualizzazione che ricorda proprio le chat. Può risultare dunque un po’ scomoda da utilizzare come client email semplice ma se vi piace l’idea non vi resta che provarlo!
Altri programmi di posta per smartphone
In ultimo vi segnaliamo questi altri client per smartphone, che purtroppo sembrano un po’ abbandonati a sé stessi:
Ltt.rs 4, pronunciato Letters, è un “Proof of concept” per il protocollo JMAP cioè in sostanza un’applicazione fatta solo per dimostrare che è possibile farla, per capirci. È disponibile su F-Droid e Play Store.
Simple Email 5 è un’applicazione semplicissima per leggere le email. Purtroppo gli aggiornamenti sono fermi al 2020. È disponibile su F-Droid.
Hai domande o qualche commento su questo articolo? Trovi la comunità di Le Alternativa su Feddit, su Matrix oppure Telegram.
Thunderbird su Matrix[↩]Codice sorgente di Librem Mail[↩]Codice sorgente di Monocles Mail[↩]Codice sorgente di Ltt.rs[↩]Codice sorgente di Simple Email[↩]
-
The Fulcrum 10 April, 2026Welcome to this week’s The Programmer’s Fulcrum.
It’s your weekly review of the essential news in the Open Media Network and Fediverse development communities with a focus on devastating big tech via Techno Anarchism. We aim to provide actionable content you can use to destroy Techno Feudalism each week. It has the additional benefit of weakening authoritarianism.
IMHO, the best way to do […]
https://newsletter.mobileatom.net/the-fulcrum-10-april-2026/ #ActivityPub #astro #ATProto #BackdropCMS #Bear #Bonfire #Codefloe #CSS #Decidim #DWeb #EmDash #FDroid #FediLab #fediverse #Ghost #Holos #HTML #HTMX #JavasScript #Kdenlive #LAUTI #Linux #OMN #PWAs #RSS #WebAwesome #WordPress #WriteFreely #XMPP #xWiki -
Ever since the Invisible Salamanders paper was published, there has been a quiet renaissance within my friends and colleagues in applied cryptography for studying systems that use Authenticated Encryption with Associated Data (AEAD) constructions, understanding what implicit assumptions these systems make about the guarantees of the AEAD mode they chose to build upon, and the consequences of those assumptions being false.
I’ve discussed Invisible Salamanders several times throughout this blog, from my criticisms of AES-GCM and XMPP + OMEMO to my vulnerability disclosures in Threema.
Five years after Invisible Salamanders, it’s become clear to me that many software developers do not fully appreciate the underlying problem discussed in the Invisible Salamanders paper, even when I share trivial proof-of-concept exploits.
Background
Fast AEAD constructions based on polynomial MACs, such as AES-GCM and ChaCha20-Poly1305, were designed to provide confidentiality and integrity for the plaintext data, and optionally integrity for some additional associated data, in systems where both parties already negotiated one shared symmetric key.
The integrity goals of the systems that adopted these AEAD constructions were often accompanied by performance goals–usually to prevent Denial of Service (DoS) attacks in networking protocols. Verification needed to be very fast and consume minimal resources.
In this sense, AEAD constructions were an incredible success. So successful, in fact, that most cryptographers urge application developers to use one of the fast AEAD modes as the default suggestion without looking deeper at the problem being solved. This is a good thing, because most developers will choose something stupid like ECB mode in the absence of guidance from cryptographers, and AEAD modes are much, much safer than any hand-rolled block cipher modes.
The problem is, that one tiny little assumption that both parties (sender, recipient) for a communication have agreed on exactly one symmetric key for use in the protocol.
Fast MACs Are Not Key-Committing
Cryptographers have concluded that AEAD constructions based on polynomial MACs–while great for performance and rejection of malformed packets without creating DoS risks–tend to make the same assumption. This is even true of misuse-resistant modes like AES-GCM-SIV and extended-nonce constructions like XSalsa20-Poly1305.
When discussing this implicit assumption of only one valid key in the systems that use these AEAD modes, we say that the modes are not key-committing. This terminology is based on what happens when this assumption is false.
Consequently, you can take a single, specially crafted ciphertext (with an authentication tag) and decrypt it under multiple different keys. The authentication tags will be valid for all keys, and the plaintext will be different.
Art: SwizzWhat does this look like in practice?
Consider my GCM exploit, which was written to generate puzzle ciphertexts for the DEFCON Furs badge challenge a few years ago. How it works is conceptually simple (although the actual mechanics behind step 4 is a bit technical):
- Generate two keys.
There’s nothing special about these keys, or their relationship to each other, and can be totally random. They just can’t be identical or the exploit is kind of pointless.
- Encrypt some blocks of plaintext with key1.
- Encrypt some more blocks of plaintext with key2.
- Calculate a collision block from the ciphertext in the previous two steps–which is just a bit of polynomial arithmetic in GF(2^128)
- Return the ciphertext (steps 2, 3, 4) and authentication tag calculated over them (which will collide for both keys).
A system that decrypts the output of this exploit under key1 will see some plaintext, followed by some garbage, followed by 1 final block of garbage.
If the same system decrypts under key2, it will see some garbage, followed by some plaintext, followed by 1 final block of garbage.
For many file formats, this garbage isn’t really a problem. Additionally, a bit more precomputation allows you to choose garbage that will be more advantageous to ensuring both outputs are accepted as “valid” by the target system.
For example, choosing two keys and a targeted nonce may allow both the valid plaintext and garbage blocks to begin with a PDF file header.
If you’re familiar with the file polyglot work of Ange Albertini, you can use this to turn the invisible salamanders problem into an artform.
Why is it called Invisible Salamanders?
The proof-of-concept used in the paper involved sending one picture (of a salamander) over an end-to-end encrypted messaging app, but when the recipient flagged it as abusive, the moderator saw a different picture.
https://www.youtube.com/watch?v=3M1jIO-jLHI
Thus, the salamander was invisible to the moderators of the encrypted messaging app.
As for the choice of a “salamander”, I’ve been told by friends familiar with the research that was inspired by the original name of the Signal Protocol being “Axolotl”.
But, like, who cares about these details besides me? It’s a cute and memorable name.
What are the consequences of violating the “one key” assumption?
That depends entirely on what your system does!
In Database Cryptography Fur the Rest of Us, I discussed the use of AEAD modes to prevent confused deputy attacks. This works great, but if you’re building an application that supports multi-tenancy, you suddenly have to care about this issue again.
An earlier design for OPAQUE, a password authenticated key exchange algorithm, was broken by a partitioning oracle attack due to building atop AEAD modes that are not key-committing. This let an attacker recover passwords from Shadowsocks proxy servers with a complexity similar to a binary search algorithm.
These are two very different impacts from the same weakness, which I believe is a significant factor for why the Invisible Salamanders issue isn’t more widely understood.
Sometimes violating the “one key” assumption that went into fast AEAD modes based on Polynomial MACs completely destroys the security of your system.
Other times, it opens the door for a high-complexity but low-impact behavior that simply violates the principle of least astonishment but doesn’t buy the attacker anything useful.
They Just Don’t Get It
The Invisible Salamanders issue is relevant in any system that uses symmetric-key encryption where more than one key can be valid.
This includes, but is not limited to:
- Multi-tenant data warehouses
- Group messaging protocols
- Envelope encryption schemes with multiple wrapping keys
- Bearer tokens (such as JSON Web Tokens) in systems that utilize Key IDs
Systems can mitigate this issue by introducing an explicit key commitment scheme (based on a cryptographic hash rather than a polynomial MAC) or by using a committing cipher mode (such as AES + HMAC, if done carefully).
However, most of the time, this advice falls on deaf ears whenever this concern is brought up by a cryptography engineer who’s more aware of this issue.
“Abuse reporting? We don’t have no stinking abuse reporting!”
The most common misunderstanding is, “We don’t have a report abuse feature, so this issue doesn’t affect us.”
This is because the Invisible Salamanders talk and paper focused on how it could be leveraged to defeat abuse reporting tools and bypass content moderation.
In my experience, many security teams would read the paper and conclude that it only impacts abuse reporting features and not potentially all systems that allow multiple symmetric keys in a given context.
Another Exploit Scenario
Imagine you’re building a Data Loss Prevention product that integrates with corporate file-sharing and collaboration software (e.g. ownCloud) for small and medium businesses.
One day, someone decides to ship an end-to-end encryption feature to the file-sharing software that uses AES-GCM to encrypt files, and then encrypts the keys to each recipient’s public key. This is basically the envelope encryption use-case above.
In order to update your integration to act as another “user”, whose public key must be included in all E2EE transfers, and will block download of ciphertexts it cannot decrypt OR contains sensitive information.
And this works, until an insider threat clever enough to abuse the Invisible Salamanders issue comes along.
In order for said insider threat (e.g., a senior business analyst) to leak sensitive data (e.g., anything that would be useful for illegal insider trading) to another person that shouldn’t have access to it (e.g., a store clerk that’s talking to the press), they just have to do this:
- Encrypt the data they want to exfiltrate using key1.
- Encrypt some innocuous data that won’t trigger your DLP product, using key2.
- Ensure that both messages encrypt to the same ciphertext and authentication tag.
- Give their recipient key1, give everyone else (including your DLP software) key2.
Bam! File leaked, and everyone’s none the wiser, until it’s too late. Let’s actually imagine what happens next:
A random store clerk has leaked sensitive data to the press that only a few analysts had access to.
The only communication between the analyst and the store clerk is a file that was shared to all employees, using the E2EE protocol. No emails or anything else were identified.
Your DLP product didn’t identify any other communications between these two, but somehow the store clerk has the data on their desktop.
A detailed forensics analysis may eventually figure out what happened, but by then, the damage is done and your product’s reputation is irrecoverably damaged.
All because the hypothetical E2EE protocol didn’t include a key-commitment mechanism, and nobody identified this deficit in their designs.
This isn’t to endorse DLP solutions at all, but rather, to highlight one of the many ways that the Invisible Salamander issue can be used creatively by clever attackers.
Art: AJThe Lesson to Learn
If you’re building a network protocol that uses AEAD to encrypt data over an insecure network (e.g., WireGuard), keep up the good work.
If you’re doing anything more involved than that, at the application layer, pause for a moment and consider whether your system will ever need multiple valid symmetric keys at once.
And, if the answer is “yes”, then you should always explicitly add a key-commitment mechanism to your system design.
(Hire a cryptographer if you’re not sure how to proceed.)
In my opinion, hemming and hawing over whether there’s a significant impact to the Invisible Salamanders issue is a worse use of your time than just solving it directly.
Eventually, I expect a new generation of AEAD modes will be standardized that explicitly provide key-commitment.
When these new designs are standardized, widely supported, and sufficiently trusted by experts, feel free to update my advice to “prefer using those modes” instead.
Header art: Harubaki, CMYKat, and Brian Gratwicke
https://soatok.blog/2024/09/10/invisible-salamanders-are-not-what-you-think/
#AEAD #AESGCM #InvisibleSalamanders #randomKeyRobustness #symmetricCryptography
- Generate two keys.
-
Ever since the Invisible Salamanders paper was published, there has been a quiet renaissance within my friends and colleagues in applied cryptography for studying systems that use Authenticated Encryption with Associated Data (AEAD) constructions, understanding what implicit assumptions these systems make about the guarantees of the AEAD mode they chose to build upon, and the consequences of those assumptions being false.
I’ve discussed Invisible Salamanders several times throughout this blog, from my criticisms of AES-GCM and XMPP + OMEMO to my vulnerability disclosures in Threema.
Five years after Invisible Salamanders, it’s become clear to me that many software developers do not fully appreciate the underlying problem discussed in the Invisible Salamanders paper, even when I share trivial proof-of-concept exploits.
Background
Fast AEAD constructions based on polynomial MACs, such as AES-GCM and ChaCha20-Poly1305, were designed to provide confidentiality and integrity for the plaintext data, and optionally integrity for some additional associated data, in systems where both parties already negotiated one shared symmetric key.
The integrity goals of the systems that adopted these AEAD constructions were often accompanied by performance goals–usually to prevent Denial of Service (DoS) attacks in networking protocols. Verification needed to be very fast and consume minimal resources.
In this sense, AEAD constructions were an incredible success. So successful, in fact, that most cryptographers urge application developers to use one of the fast AEAD modes as the default suggestion without looking deeper at the problem being solved. This is a good thing, because most developers will choose something stupid like ECB mode in the absence of guidance from cryptographers, and AEAD modes are much, much safer than any hand-rolled block cipher modes.
The problem is, that one tiny little assumption that both parties (sender, recipient) for a communication have agreed on exactly one symmetric key for use in the protocol.
Fast MACs Are Not Key-Committing
Cryptographers have concluded that AEAD constructions based on polynomial MACs–while great for performance and rejection of malformed packets without creating DoS risks–tend to make the same assumption. This is even true of misuse-resistant modes like AES-GCM-SIV and extended-nonce constructions like XSalsa20-Poly1305.
When discussing this implicit assumption of only one valid key in the systems that use these AEAD modes, we say that the modes are not key-committing. This terminology is based on what happens when this assumption is false.
Consequently, you can take a single, specially crafted ciphertext (with an authentication tag) and decrypt it under multiple different keys. The authentication tags will be valid for all keys, and the plaintext will be different.
Art: SwizzWhat does this look like in practice?
Consider my GCM exploit, which was written to generate puzzle ciphertexts for the DEFCON Furs badge challenge a few years ago. How it works is conceptually simple (although the actual mechanics behind step 4 is a bit technical):
- Generate two keys.
There’s nothing special about these keys, or their relationship to each other, and can be totally random. They just can’t be identical or the exploit is kind of pointless.
- Encrypt some blocks of plaintext with key1.
- Encrypt some more blocks of plaintext with key2.
- Calculate a collision block from the ciphertext in the previous two steps–which is just a bit of polynomial arithmetic in GF(2^128)
- Return the ciphertext (steps 2, 3, 4) and authentication tag calculated over them (which will collide for both keys).
A system that decrypts the output of this exploit under key1 will see some plaintext, followed by some garbage, followed by 1 final block of garbage.
If the same system decrypts under key2, it will see some garbage, followed by some plaintext, followed by 1 final block of garbage.
For many file formats, this garbage isn’t really a problem. Additionally, a bit more precomputation allows you to choose garbage that will be more advantageous to ensuring both outputs are accepted as “valid” by the target system.
For example, choosing two keys and a targeted nonce may allow both the valid plaintext and garbage blocks to begin with a PDF file header.
If you’re familiar with the file polyglot work of Ange Albertini, you can use this to turn the Invisible Salamanders problem into an artform.
And this is just the simple attack!
The Invisible Salamanders paper outlined a more advanced variant (with a proof of concept) in Section 3.2, which doesn’t suffer from nearly as much garbage data as the simple attack.
As Bruce Schneier often says, “Attacks only get better, they never get worse.”
Why is it called Invisible Salamanders?
The proof-of-concept used in the paper involved sending one picture (of a salamander) over an end-to-end encrypted messaging app, but when the recipient flagged it as abusive, the moderator saw a different picture.
https://www.youtube.com/watch?v=3M1jIO-jLHI
Thus, the salamander was invisible to the moderators of the encrypted messaging app.
As for the choice of a “salamander”, I’ve been told by friends familiar with the research that was inspired by the original name of the Signal Protocol being “Axolotl”.
But, like, who cares about these details besides me? It’s a cute and memorable name.
What are the consequences of violating the “one key” assumption?
That depends entirely on what your system does!
In Database Cryptography Fur the Rest of Us, I discussed the use of AEAD modes to prevent confused deputy attacks. This works great, but if you’re building an application that supports multi-tenancy, you suddenly have to care about this issue again.
An earlier design for OPAQUE, a password authenticated key exchange algorithm, was broken by a partitioning oracle attack due to building atop AEAD modes that are not key-committing. This let an attacker recover passwords from Shadowsocks proxy servers with a complexity similar to a binary search algorithm.
These are two very different impacts from the same weakness, which I believe is a significant factor for why the Invisible Salamanders issue isn’t more widely understood.
Sometimes violating the “one key” assumption that went into fast AEAD modes based on Polynomial MACs completely destroys the security of your system.
Other times, it opens the door for a high-complexity but low-impact behavior that simply violates the principle of least astonishment but doesn’t buy the attacker anything useful.
They Just Don’t Get It
The Invisible Salamanders issue is relevant in any system that uses symmetric-key encryption where more than one key can be valid.
This includes, but is not limited to:
- Multi-tenant data warehouses
- Group messaging protocols
- It’s sometimes tempting to discount group messaging as a relevant consideration if your experience is “emulated groups atop 1-to-1 messaging”, but there are protocols that establish a Group Key (i.e., RFC 9420) and then use that for all group messages.
- Envelope encryption schemes with multiple wrapping keys
- Bearer tokens (such as JSON Web Tokens) in systems that utilize Key IDs
Systems can mitigate this issue by introducing an explicit key commitment scheme (based on a cryptographic hash rather than a polynomial MAC) or by using a committing cipher mode (such as AES + HMAC, if done carefully).
However, most of the time, this advice falls on deaf ears whenever this concern is brought up by a cryptography engineer who’s more aware of this issue.
“Abuse reporting? We don’t have no stinking abuse reporting!”
The most common misunderstanding is, “We don’t have a report abuse feature, so this issue doesn’t affect us.”
This is because the Invisible Salamanders talk and paper focused on how it could be leveraged to defeat abuse reporting tools and bypass content moderation.
In my experience, many security teams would read the paper and conclude that it only impacts abuse reporting features and not potentially all systems that allow multiple symmetric keys in a given context.
Another Exploit Scenario
Imagine you’re building a Data Loss Prevention product that integrates with corporate file-sharing and collaboration software (e.g. ownCloud) for small and medium businesses.
One day, someone decides to ship an end-to-end encryption feature to the file-sharing software that uses AES-GCM to encrypt files, and then encrypts the keys to each recipient’s public key. This is basically the envelope encryption use-case above.
So, you dutifully update your integration to act as another “user”, whose public key must be included in all E2EE transfers, and will block download of ciphertexts it cannot decrypt OR contains sensitive information.
And this works, until an insider threat clever enough to abuse the Invisible Salamanders issue comes along.
In order for said insider threat (e.g., a senior business analyst) to leak sensitive data (e.g., anything that would be useful for illegal insider trading) to another person that shouldn’t have access to it (e.g., a store clerk that’s talking to the press), they just have to do this:
- Encrypt the data they want to exfiltrate using key1.
- Encrypt some innocuous data that won’t trigger your DLP product, using key2.
- Ensure that both messages encrypt to the same ciphertext and authentication tag.
- Give their recipient key1, give everyone else (including your DLP software) key2.
Bam! File leaked, and everyone’s none the wiser, until it’s too late. Let’s actually imagine what happens next:
A random store clerk has leaked sensitive data to the press that only a few analysts had access to.
The only communication between the analyst and the store clerk is a file that was shared to all employees, using the E2EE protocol. No emails or anything else were identified.
Your DLP product didn’t identify any other communications between these two, but somehow the store clerk has the data on their desktop.
A detailed forensics analysis may eventually figure out what happened, but by then, the damage is done and your product’s reputation is irrecoverably damaged.
All because the hypothetical E2EE protocol didn’t include a key-commitment mechanism, and nobody identified this deficit in their designs.
This isn’t to endorse DLP solutions at all, but rather, to highlight one of the many ways that the Invisible Salamander issue can be used creatively by clever attackers.
Art: AJ“Couldn’t you do the same with steganography?”
No, the attack is very different from stego.
Stego is about hiding a message in plain sight, so that only the person that knows where/how to look can find it.
The Invisible Salamanders attack lets you send one ciphertext through a network then selectively decrypt it to one of two plaintexts, depending on which key you reveal to each participant.
In the Invisible Salamanders paper and talk, they used this to send “abusive” messages to a recipient that the moderator would not see. Thus, invisible.
In one, the message is always emitted to anyone who knows how to find it. In the other, the attacker selects which you see, even if you have mechanisms to ensure you’re seeing the same ciphertext. It’s not a subtle difference.
Mitigation Techniques
There are multiple ways to mitigate the risk of Invisible Salamanders in a cryptosystem.
- Use HMAC, or (failing that) something built atop cryptographic hash functions, rather than a Polynomial MAC.
- Use an AEAD cipher designed with multi-recipient integrity as a security goal.
- Compute a non-invertible, one-way commitment of the encryption key.
A trivial mitigation looks like this:
class SoatokExampleEncryptor { const NEW_ENCRYPT_KEY = 'myProtocol$encryptKey'; const NEW_COMMITMENT = 'myProtocol$commitment'; public function __construct(#[SensitiveParameter] private string $key) {} /** * Let's assume we're starting with a simple AES-GCM wrapper */ public function legacyEncrypt(string $plaintext, string $assocData = ''): string { $nonce = random_bytes(12); $tag = ''; $ciphertext = openssl_encrypt( $plaintext, 'aes-256-gcm', $this->key, OPENSSL_RAW_DATA, $nonce, $tag, $assocData ); return $nonce . $ciphertext . $tag; } /** * An improved function looks something like this */ public function newEncrypt(string $plaintext, string $assocData = ''): string { // Avoid birthday bound issues with 256-bits of randomness $longerNonce = random_bytes(32); // Derive a subkey and synthetic nonce $tmp = hash_hkdf('sha512', $this->key, 44, self::NEW_ENCRYPT_KEY . $longerNonce); $encKey = substr($tmp, 0, 32); $nonce = substr($tmp, 32); // New: Key commitment $commitment = hash_hkdf('sha512', $this->key, 32, self::NEW_COMMITMENT . $longerNonce); // Most of this is unchanged $tag = ''; $ciphertext = openssl_encrypt( $plaintext, 'aes-256-gcm', $encKey, OPENSSL_RAW_DATA, $nonce, $tag, $assocData ); return $longerNonce . $commitment . $ciphertext . $tag; }}And then the decryption logic would recalculate the commitment, and compare it with the stored value, in constant-time.
It’s important that the commitment be stored with the ciphertext, rather than bundling it with the key.
(It may be worthwhile to also include the commitment in the associated data, to add a mechanism against downgrade attacks.)
The Lesson to Learn
If you’re building a network protocol that uses AEAD to encrypt data over an insecure network (e.g., WireGuard), keep up the good work.
If you’re doing anything more involved than that, at the application layer, pause for a moment and consider whether your system will ever need multiple valid symmetric keys at once.
And, if the answer is “yes”, then you should always explicitly add a key-commitment mechanism to your system design.
(Hire a cryptographer if you’re not sure how to proceed.)
In my opinion, hemming and hawing over whether there’s a significant impact to the Invisible Salamanders issue is a worse use of your time than just solving it directly.
Eventually, I expect a new generation of AEAD modes will be standardized that explicitly provide key-commitment.
When these new designs are standardized, widely supported, and sufficiently trusted by experts, feel free to update my advice to “prefer using those modes” instead.
Header art: Harubaki, CMYKat, and a photo by Brian Gratwicke. Poorly photoshopped by myself.
https://soatok.blog/2024/09/10/invisible-salamanders-are-not-what-you-think/
#AEAD #AESGCM #InvisibleSalamanders #randomKeyRobustness #symmetricCryptography
- Generate two keys.
-
Ever since the Invisible Salamanders paper was published, there has been a quiet renaissance within my friends and colleagues in applied cryptography for studying systems that use Authenticated Encryption with Associated Data (AEAD) constructions, understanding what implicit assumptions these systems make about the guarantees of the AEAD mode they chose to build upon, and the consequences of those assumptions being false.
I’ve discussed Invisible Salamanders several times throughout this blog, from my criticisms of AES-GCM and XMPP + OMEMO to my vulnerability disclosures in Threema.
Five years after Invisible Salamanders, it’s become clear to me that many software developers do not fully appreciate the underlying problem discussed in the Invisible Salamanders paper, even when I share trivial proof-of-concept exploits.
Background
Fast AEAD constructions based on polynomial MACs, such as AES-GCM and ChaCha20-Poly1305, were designed to provide confidentiality and integrity for the plaintext data, and optionally integrity for some additional associated data, in systems where both parties already negotiated one shared symmetric key.
The integrity goals of the systems that adopted these AEAD constructions were often accompanied by performance goals–usually to prevent Denial of Service (DoS) attacks in networking protocols. Verification needed to be very fast and consume minimal resources.
In this sense, AEAD constructions were an incredible success. So successful, in fact, that most cryptographers urge application developers to use one of the fast AEAD modes as the default suggestion without looking deeper at the problem being solved. This is a good thing, because most developers will choose something stupid like ECB mode in the absence of guidance from cryptographers, and AEAD modes are much, much safer than any hand-rolled block cipher modes.
The problem is, that one tiny little assumption that both parties (sender, recipient) for a communication have agreed on exactly one symmetric key for use in the protocol.
Fast MACs Are Not Key-Committing
Cryptographers have concluded that AEAD constructions based on polynomial MACs–while great for performance and rejection of malformed packets without creating DoS risks–tend to make the same assumption. This is even true of misuse-resistant modes like AES-GCM-SIV and extended-nonce constructions like XSalsa20-Poly1305.
When discussing this implicit assumption of only one valid key in the systems that use these AEAD modes, we say that the modes are not key-committing. This terminology is based on what happens when this assumption is false.
Consequently, you can take a single, specially crafted ciphertext (with an authentication tag) and decrypt it under multiple different keys. The authentication tags will be valid for all keys, and the plaintext will be different.
Art: SwizzWhat does this look like in practice?
Consider my GCM exploit, which was written to generate puzzle ciphertexts for the DEFCON Furs badge challenge a few years ago. How it works is conceptually simple (although the actual mechanics behind step 4 is a bit technical):
- Generate two keys.
There’s nothing special about these keys, or their relationship to each other, and can be totally random. They just can’t be identical or the exploit is kind of pointless.
- Encrypt some blocks of plaintext with key1.
- Encrypt some more blocks of plaintext with key2.
- Calculate a collision block from the ciphertext in the previous two steps–which is just a bit of polynomial arithmetic in GF(2^128)
- Return the ciphertext (steps 2, 3, 4) and authentication tag calculated over them (which will collide for both keys).
A system that decrypts the output of this exploit under key1 will see some plaintext, followed by some garbage, followed by 1 final block of garbage.
If the same system decrypts under key2, it will see some garbage, followed by some plaintext, followed by 1 final block of garbage.
For many file formats, this garbage isn’t really a problem. Additionally, a bit more precomputation allows you to choose garbage that will be more advantageous to ensuring both outputs are accepted as “valid” by the target system.
For example, choosing two keys and a targeted nonce may allow both the valid plaintext and garbage blocks to begin with a PDF file header.
If you’re familiar with the file polyglot work of Ange Albertini, you can use this to turn the Invisible Salamanders problem into an artform.
And this is just the simple attack!
The Invisible Salamanders paper outlined a more advanced variant (with a proof of concept) in Section 3.2, which doesn’t suffer from nearly as much garbage data as the simple attack.
As Bruce Schneier often says, “Attacks only get better, they never get worse.”
Why is it called Invisible Salamanders?
The proof-of-concept used in the paper involved sending one picture (of a salamander) over an end-to-end encrypted messaging app, but when the recipient flagged it as abusive, the moderator saw a different picture.
https://www.youtube.com/watch?v=3M1jIO-jLHI
Thus, the salamander was invisible to the moderators of the encrypted messaging app.
As for the choice of a “salamander”, I’ve been told by friends familiar with the research that was inspired by the original name of the Signal Protocol being “Axolotl”.
But, like, who cares about these details besides me? It’s a cute and memorable name.
What are the consequences of violating the “one key” assumption?
That depends entirely on what your system does!
In Database Cryptography Fur the Rest of Us, I discussed the use of AEAD modes to prevent confused deputy attacks. This works great, but if you’re building an application that supports multi-tenancy, you suddenly have to care about this issue again.
An earlier design for OPAQUE, a password authenticated key exchange algorithm, was broken by a partitioning oracle attack due to building atop AEAD modes that are not key-committing. This let an attacker recover passwords from Shadowsocks proxy servers with a complexity similar to a binary search algorithm.
These are two very different impacts from the same weakness, which I believe is a significant factor for why the Invisible Salamanders issue isn’t more widely understood.
Sometimes violating the “one key” assumption that went into fast AEAD modes based on Polynomial MACs completely destroys the security of your system.
Other times, it opens the door for a high-complexity but low-impact behavior that simply violates the principle of least astonishment but doesn’t buy the attacker anything useful.
They Just Don’t Get It
The Invisible Salamanders issue is relevant in any system that uses symmetric-key encryption where more than one key can be valid.
This includes, but is not limited to:
- Multi-tenant data warehouses
- Group messaging protocols
- It’s sometimes tempting to discount group messaging as a relevant consideration if your experience is “emulated groups atop 1-to-1 messaging”, but there are protocols that establish a Group Key (i.e., RFC 9420) and then use that for all group messages.
- Envelope encryption schemes with multiple wrapping keys
- Bearer tokens (such as JSON Web Tokens) in systems that utilize Key IDs
Systems can mitigate this issue by introducing an explicit key commitment scheme (based on a cryptographic hash rather than a polynomial MAC) or by using a committing cipher mode (such as AES + HMAC, if done carefully).
However, most of the time, this advice falls on deaf ears whenever this concern is brought up by a cryptography engineer who’s more aware of this issue.
“Abuse reporting? We don’t have no stinking abuse reporting!”
The most common misunderstanding is, “We don’t have a report abuse feature, so this issue doesn’t affect us.”
This is because the Invisible Salamanders talk and paper focused on how it could be leveraged to defeat abuse reporting tools and bypass content moderation.
In my experience, many security teams would read the paper and conclude that it only impacts abuse reporting features and not potentially all systems that allow multiple symmetric keys in a given context.
Another Exploit Scenario
Imagine you’re building a Data Loss Prevention product that integrates with corporate file-sharing and collaboration software (e.g. ownCloud) for small and medium businesses.
One day, someone decides to ship an end-to-end encryption feature to the file-sharing software that uses AES-GCM to encrypt files, and then encrypts the keys to each recipient’s public key. This is basically the envelope encryption use-case above.
So, you dutifully update your integration to act as another “user”, whose public key must be included in all E2EE transfers, and will block download of ciphertexts it cannot decrypt OR contains sensitive information.
And this works, until an insider threat clever enough to abuse the Invisible Salamanders issue comes along.
In order for said insider threat (e.g., a senior business analyst) to leak sensitive data (e.g., anything that would be useful for illegal insider trading) to another person that shouldn’t have access to it (e.g., a store clerk that’s talking to the press), they just have to do this:
- Encrypt the data they want to exfiltrate using key1.
- Encrypt some innocuous data that won’t trigger your DLP product, using key2.
- Ensure that both messages encrypt to the same ciphertext and authentication tag.
- Give their recipient key1, give everyone else (including your DLP software) key2.
Bam! File leaked, and everyone’s none the wiser, until it’s too late. Let’s actually imagine what happens next:
A random store clerk has leaked sensitive data to the press that only a few analysts had access to.
The only communication between the analyst and the store clerk is a file that was shared to all employees, using the E2EE protocol. No emails or anything else were identified.
Your DLP product didn’t identify any other communications between these two, but somehow the store clerk has the data on their desktop.
A detailed forensics analysis may eventually figure out what happened, but by then, the damage is done and your product’s reputation is irrecoverably damaged.
All because the hypothetical E2EE protocol didn’t include a key-commitment mechanism, and nobody identified this deficit in their designs.
This isn’t to endorse DLP solutions at all, but rather, to highlight one of the many ways that the Invisible Salamander issue can be used creatively by clever attackers.
Art: AJ“Couldn’t you do the same with steganography?”
No, the attack is very different from stego.
Stego is about hiding a message in plain sight, so that only the person that knows where/how to look can find it.
The Invisible Salamanders attack lets you send one ciphertext through a network then selectively decrypt it to one of two plaintexts, depending on which key you reveal to each participant.
In the Invisible Salamanders paper and talk, they used this to send “abusive” messages to a recipient that the moderator would not see. Thus, invisible.
In one, the message is always emitted to anyone who knows how to find it. In the other, the attacker selects which you see, even if you have mechanisms to ensure you’re seeing the same ciphertext. It’s not a subtle difference.
Mitigation Techniques
There are multiple ways to mitigate the risk of Invisible Salamanders in a cryptosystem.
- Use HMAC, or (failing that) something built atop cryptographic hash functions, rather than a Polynomial MAC.
- Use an AEAD cipher designed with multi-recipient integrity as a security goal.
- Compute a non-invertible, one-way commitment of the encryption key.
A trivial mitigation looks like this:
class SoatokExampleEncryptor { const NEW_ENCRYPT_KEY = 'myProtocol$encryptKey'; const NEW_COMMITMENT = 'myProtocol$commitment'; public function __construct(#[SensitiveParameter] private string $key) {} /** * Let's assume we're starting with a simple AES-GCM wrapper */ public function legacyEncrypt(string $plaintext, string $assocData = ''): string { $nonce = random_bytes(12); $tag = ''; $ciphertext = openssl_encrypt( $plaintext, 'aes-256-gcm', $this->key, OPENSSL_RAW_DATA, $nonce, $tag, $assocData ); return $nonce . $ciphertext . $tag; } /** * An improved function looks something like this */ public function newEncrypt(string $plaintext, string $assocData = ''): string { // Avoid birthday bound issues with 256-bits of randomness $longerNonce = random_bytes(32); // Derive a subkey and synthetic nonce $tmp = hash_hkdf('sha512', $this->key, 44, self::NEW_ENCRYPT_KEY . $longerNonce); $encKey = substr($tmp, 0, 32); $nonce = substr($tmp, 32); // New: Key commitment $commitment = hash_hkdf('sha512', $this->key, 32, self::NEW_COMMITMENT . $longerNonce); // Most of this is unchanged $tag = ''; $ciphertext = openssl_encrypt( $plaintext, 'aes-256-gcm', $encKey, OPENSSL_RAW_DATA, $nonce, $tag, $assocData ); return $longerNonce . $commitment . $ciphertext . $tag; }}And then the decryption logic would recalculate the commitment, and compare it with the stored value, in constant-time.
It’s important that the commitment be stored with the ciphertext, rather than bundling it with the key.
(It may be worthwhile to also include the commitment in the associated data, to add a mechanism against downgrade attacks.)
The Lesson to Learn
If you’re building a network protocol that uses AEAD to encrypt data over an insecure network (e.g., WireGuard), keep up the good work.
If you’re doing anything more involved than that, at the application layer, pause for a moment and consider whether your system will ever need multiple valid symmetric keys at once.
And, if the answer is “yes”, then you should always explicitly add a key-commitment mechanism to your system design.
(Hire a cryptographer if you’re not sure how to proceed.)
In my opinion, hemming and hawing over whether there’s a significant impact to the Invisible Salamanders issue is a worse use of your time than just solving it directly.
Eventually, I expect a new generation of AEAD modes will be standardized that explicitly provide key-commitment.
When these new designs are standardized, widely supported, and sufficiently trusted by experts, feel free to update my advice to “prefer using those modes” instead.
Header art: Harubaki, CMYKat, and a photo by Brian Gratwicke. Poorly photoshopped by myself.
https://soatok.blog/2024/09/10/invisible-salamanders-are-not-what-you-think/
#AEAD #AESGCM #InvisibleSalamanders #randomKeyRobustness #symmetricCryptography
- Generate two keys.
-
Ever since the Invisible Salamanders paper was published, there has been a quiet renaissance within my friends and colleagues in applied cryptography for studying systems that use Authenticated Encryption with Associated Data (AEAD) constructions, understanding what implicit assumptions these systems make about the guarantees of the AEAD mode they chose to build upon, and the consequences of those assumptions being false.
I’ve discussed Invisible Salamanders several times throughout this blog, from my criticisms of AES-GCM and XMPP + OMEMO to my vulnerability disclosures in Threema.
Five years after Invisible Salamanders, it’s become clear to me that many software developers do not fully appreciate the underlying problem discussed in the Invisible Salamanders paper, even when I share trivial proof-of-concept exploits.
Background
Fast AEAD constructions based on polynomial MACs, such as AES-GCM and ChaCha20-Poly1305, were designed to provide confidentiality and integrity for the plaintext data, and optionally integrity for some additional associated data, in systems where both parties already negotiated one shared symmetric key.
The integrity goals of the systems that adopted these AEAD constructions were often accompanied by performance goals–usually to prevent Denial of Service (DoS) attacks in networking protocols. Verification needed to be very fast and consume minimal resources.
In this sense, AEAD constructions were an incredible success. So successful, in fact, that most cryptographers urge application developers to use one of the fast AEAD modes as the default suggestion without looking deeper at the problem being solved. This is a good thing, because most developers will choose something stupid like ECB mode in the absence of guidance from cryptographers, and AEAD modes are much, much safer than any hand-rolled block cipher modes.
The problem is, that one tiny little assumption that both parties (sender, recipient) for a communication have agreed on exactly one symmetric key for use in the protocol.
Fast MACs Are Not Key-Committing
Cryptographers have concluded that AEAD constructions based on polynomial MACs–while great for performance and rejection of malformed packets without creating DoS risks–tend to make the same assumption. This is even true of misuse-resistant modes like AES-GCM-SIV and extended-nonce constructions like XSalsa20-Poly1305.
When discussing this implicit assumption of only one valid key in the systems that use these AEAD modes, we say that the modes are not key-committing. This terminology is based on what happens when this assumption is false.
Consequently, you can take a single, specially crafted ciphertext (with an authentication tag) and decrypt it under multiple different keys. The authentication tags will be valid for all keys, and the plaintext will be different.
Art: SwizzWhat does this look like in practice?
Consider my GCM exploit, which was written to generate puzzle ciphertexts for the DEFCON Furs badge challenge a few years ago. How it works is conceptually simple (although the actual mechanics behind step 4 is a bit technical):
- Generate two keys.
There’s nothing special about these keys, or their relationship to each other, and can be totally random. They just can’t be identical or the exploit is kind of pointless.
- Encrypt some blocks of plaintext with key1.
- Encrypt some more blocks of plaintext with key2.
- Calculate a collision block from the ciphertext in the previous two steps–which is just a bit of polynomial arithmetic in GF(2^128)
- Return the ciphertext (steps 2, 3, 4) and authentication tag calculated over them (which will collide for both keys).
A system that decrypts the output of this exploit under key1 will see some plaintext, followed by some garbage, followed by 1 final block of garbage.
If the same system decrypts under key2, it will see some garbage, followed by some plaintext, followed by 1 final block of garbage.
For many file formats, this garbage isn’t really a problem. Additionally, a bit more precomputation allows you to choose garbage that will be more advantageous to ensuring both outputs are accepted as “valid” by the target system.
For example, choosing two keys and a targeted nonce may allow both the valid plaintext and garbage blocks to begin with a PDF file header.
If you’re familiar with the file polyglot work of Ange Albertini, you can use this to turn the invisible salamanders problem into an artform.
Why is it called Invisible Salamanders?
The proof-of-concept used in the paper involved sending one picture (of a salamander) over an end-to-end encrypted messaging app, but when the recipient flagged it as abusive, the moderator saw a different picture.
https://www.youtube.com/watch?v=3M1jIO-jLHI
Thus, the salamander was invisible to the moderators of the encrypted messaging app.
As for the choice of a “salamander”, I’ve been told by friends familiar with the research that was inspired by the original name of the Signal Protocol being “Axolotl”.
But, like, who cares about these details besides me? It’s a cute and memorable name.
What are the consequences of violating the “one key” assumption?
That depends entirely on what your system does!
In Database Cryptography Fur the Rest of Us, I discussed the use of AEAD modes to prevent confused deputy attacks. This works great, but if you’re building an application that supports multi-tenancy, you suddenly have to care about this issue again.
An earlier design for OPAQUE, a password authenticated key exchange algorithm, was broken by a partitioning oracle attack due to building atop AEAD modes that are not key-committing. This let an attacker recover passwords from Shadowsocks proxy servers with a complexity similar to a binary search algorithm.
These are two very different impacts from the same weakness, which I believe is a significant factor for why the Invisible Salamanders issue isn’t more widely understood.
Sometimes violating the “one key” assumption that went into fast AEAD modes based on Polynomial MACs completely destroys the security of your system.
Other times, it opens the door for a high-complexity but low-impact behavior that simply violates the principle of least astonishment but doesn’t buy the attacker anything useful.
They Just Don’t Get It
The Invisible Salamanders issue is relevant in any system that uses symmetric-key encryption where more than one key can be valid.
This includes, but is not limited to:
- Multi-tenant data warehouses
- Group messaging protocols
- Envelope encryption schemes with multiple wrapping keys
- Bearer tokens (such as JSON Web Tokens) in systems that utilize Key IDs
Systems can mitigate this issue by introducing an explicit key commitment scheme (based on a cryptographic hash rather than a polynomial MAC) or by using a committing cipher mode (such as AES + HMAC, if done carefully).
However, most of the time, this advice falls on deaf ears whenever this concern is brought up by a cryptography engineer who’s more aware of this issue.
“Abuse reporting? We don’t have no stinking abuse reporting!”
The most common misunderstanding is, “We don’t have a report abuse feature, so this issue doesn’t affect us.”
This is because the Invisible Salamanders talk and paper focused on how it could be leveraged to defeat abuse reporting tools and bypass content moderation.
In my experience, many security teams would read the paper and conclude that it only impacts abuse reporting features and not potentially all systems that allow multiple symmetric keys in a given context.
Another Exploit Scenario
Imagine you’re building a Data Loss Prevention product that integrates with corporate file-sharing and collaboration software (e.g. ownCloud) for small and medium businesses.
One day, someone decides to ship an end-to-end encryption feature to the file-sharing software that uses AES-GCM to encrypt files, and then encrypts the keys to each recipient’s public key. This is basically the envelope encryption use-case above.
In order to update your integration to act as another “user”, whose public key must be included in all E2EE transfers, and will block download of ciphertexts it cannot decrypt OR contains sensitive information.
And this works, until an insider threat clever enough to abuse the Invisible Salamanders issue comes along.
In order for said insider threat (e.g., a senior business analyst) to leak sensitive data (e.g., anything that would be useful for illegal insider trading) to another person that shouldn’t have access to it (e.g., a store clerk that’s talking to the press), they just have to do this:
- Encrypt the data they want to exfiltrate using key1.
- Encrypt some innocuous data that won’t trigger your DLP product, using key2.
- Ensure that both messages encrypt to the same ciphertext and authentication tag.
- Give their recipient key1, give everyone else (including your DLP software) key2.
Bam! File leaked, and everyone’s none the wiser, until it’s too late. Let’s actually imagine what happens next:
A random store clerk has leaked sensitive data to the press that only a few analysts had access to.
The only communication between the analyst and the store clerk is a file that was shared to all employees, using the E2EE protocol. No emails or anything else were identified.
Your DLP product didn’t identify any other communications between these two, but somehow the store clerk has the data on their desktop.
A detailed forensics analysis may eventually figure out what happened, but by then, the damage is done and your product’s reputation is irrecoverably damaged.
All because the hypothetical E2EE protocol didn’t include a key-commitment mechanism, and nobody identified this deficit in their designs.
This isn’t to endorse DLP solutions at all, but rather, to highlight one of the many ways that the Invisible Salamander issue can be used creatively by clever attackers.
Art: AJThe Lesson to Learn
If you’re building a network protocol that uses AEAD to encrypt data over an insecure network (e.g., WireGuard), keep up the good work.
If you’re doing anything more involved than that, at the application layer, pause for a moment and consider whether your system will ever need multiple valid symmetric keys at once.
And, if the answer is “yes”, then you should always explicitly add a key-commitment mechanism to your system design.
(Hire a cryptographer if you’re not sure how to proceed.)
In my opinion, hemming and hawing over whether there’s a significant impact to the Invisible Salamanders issue is a worse use of your time than just solving it directly.
Eventually, I expect a new generation of AEAD modes will be standardized that explicitly provide key-commitment.
When these new designs are standardized, widely supported, and sufficiently trusted by experts, feel free to update my advice to “prefer using those modes” instead.
Header art: Harubaki, CMYKat, and Brian Gratwicke
https://soatok.blog/2024/09/10/invisible-salamanders-are-not-what-you-think/
#AEAD #AESGCM #InvisibleSalamanders #randomKeyRobustness #symmetricCryptography
- Generate two keys.
-
@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
