Should we consider using Simplex instead of the current default and by Whonix documentation preferred XMPP with OMEMO encryption?
I found following statements:
1. Metadata on XMPP chat
XMPP server can see your digital identity like your public key (this is important for the comparison); who is communicating with whom; when one is communicating (the precise timeframe); for how long the session goes; login-logout times; whole social graph; size of the messages; packet patterns; the encryption is quantum-nonresistant.
2. MITM attack XMPP chat
The XMPP server can act as a Man In The Middle and if the attack is successful, the server can read the messages of the communicating parties in the plain, unencrypted. The only protection is to check the fingerprints of the communicating parties through a separate secure channel.
Advantages of Simplex over XMPP
basically no metadata leaking to the servers
there are no identities, not even random numbers, server donât have any way to identify a âuserâ because there are no âusersâ to spy on
multilayer connection padding where every message has the same size (this even improves on Tor), frustrating the adversarial message size attack. Servers and network observers cannot distinguish in between messages - all messages have precisely the same size.
all messages are mixed, so the order in which they were received is not the same order they were sent out (this even improves on Tor), frustrating the correlation attacks
the SimpleX uses quantum resistant NTRU as a very robust encapsulation mechanism combining the standard encryption with the PQC, battle-proved in the wild for many years instead of the KEM that seems to be sensitive to some attacks, because it is based on latices
you can have a unique connection to your every contact with the Incognito mode functionality, in a single app, using completely different channels and servers (that donât see a shit) for every contact
it is MITM resistant, no need to manually prove anything
e2ee voice messages, voice calls, video calls
it has not only PFS but also the BIR (Break In Recovery) feature
it has the Unidirectional Message Queues, that frustrate the adversary analysis of packet direction flows
no need to check the fingerprint manually through a different secure channel - MITM is not possible
no identity to spy on, not even a temporary numbers
every single contact can be connected to you through a different channel - no social graph building possible
message padding - no size analysis possible
message mixing - all deanon attacks related to the order of the messages are dead. This even improves Tor anonymity.
PQ encryption for 10+ years of information protection lifetime
I could not find information about OMEMO and post-quantum security.
SimpleXâs user interface on desktop sucks right now. Quite minimal, spartan, and also ugly (the UI elements are disproportionate, the look and feel is so much Apple-ish (for whatever the reason)). However, the chat functionality works without a problem.
That is unfortunate. However considering SimpleX seems rather solid from a technical perspective I hope others will see the merits and hopefully there will eventually be a better client built on memory-safe primitives.
I believe that Onionshare used to be included in Whonix by default (I saw a different youtube video with it included by default on an earlier version of Whonix). However, it does not appear to be so anymore. I do not know if it was causing a tor-over-tor situation or a stream isolation issue or something. But I presume the same could be the case for SimpleX.
The absence of permanent identifiers is a unique protection.
Message queue randomization on servers and separate server chains for incoming and outgoing messages is a unique protection.
Excellent stealth mode: creating an infinite number of separate anonymous chats with different names for the same interlocutor, creating groups/channels under anonymous names is a unique protection.
Quantum protection through multi-layer encryption is a unique protection.
You can create an infinite number of users.
You can set a fake PIN to destroy the database.
You can run your own servers (support for onion servers).
The messenger is actively updated and has an active support service, with which you can communicate incognito.
It respects Tor and recommends its use for additional protection.
It doesnât force the use of Tor - no Tor over Tor.
There are proxy settings, and even a dedicated proxy is provided to bypass blocks in heavily censored countries.
The creator of Simplex is highly respected in the Monero community and has been giving talks at Monero conferences for several years.
An alternative very secure recommended messenger is Cwtch. Itâs written about in this forum Cwtch messaging Cwtch ranks 3rd in this rating (after Simplex Chat and Briar) https://privacyspreadsheet.com/messaging-apps. But Briar does not solve the problem of Tor over Tor, which has been an issue for many years Briar Desktop in Whonix - #21 by nyxnor The creator of Simplex Chat also highlighted Cwtch for its security at last yearâs Monero conference, and said that the Cwtch team helped resolve some issues in Simplex.
Yes, there is an important nuance - Simplex stores all conversation history locally (unlike XMPP/Matrix, Signal, WireâŚ). This enhances security. But you need to back up the database to ensure access to messages in case of a Whonix failure or if you run Whonix in live mode. Security increases in live mode - you can create an account in Simplex, then run live mode in Whonix and everything you do in Simplex Chat will be destroyed - after rebooting, you will have a clean account with no chats
Please note that simplex does not sign their releases nor does simplex have reproducible builds unlike every other secure messenger. They have made strides by implementing reproducible server builds, but the client still does not have reproducible builds. This means when you download a simplex binary you have no way of verifying that it came from the simplex developers, nor can you verify the code being hosted on github is the same code being shipped in that binary. I would strongly say not to recommend simplex until they fix these issues.
It is indicated in this table Instant Messenger Chat. It is also recommended that users make their own choice. For example, Simplex and Onionshare do not have reproducible builds, Cwtch have not undergone a security audit and is complex to install, XMPP have metadata issues and E2EE is not enabled by default. There is no perfect option. No one is forcing you to use Simplex
Hello @nani thank you for your response. I understand the complexities of implementing reproducible builds especially in the build system they are using, however being able to verify that a binary did in fact come from the developers is something that should be default when it comes to any sort of secure messenger. Itâs an important point users should be informed of and I donât think the link you posted does a good job of informing them.
[âŚ] once the builds are migrated to the environment we control. While the builds are run on the servers we donât control, [âŚ]
So at time of writing, SimpleX doesnât even control their build environment.
I am surprised they didnât fix this since 2023. Local builds and digital software signatures is a lot easier to implement than a lot other features of SimpleX.
This makes me doubt the whole project.
Seems weâll need a new comparison table entry:
local builds on developer controlled machine (not using cloud infrastructure for builds)
This issue and absence of digital software signatures should be documented on the SimpleX wiki page.
I find it concerning that he decided to mark the issue as completed when it has not been addressed in the current release. Also look at the issue mentioned by maltfield the buskill founder.
Hello! Yes, they only sign mobile clients. The desktop version still has this issue. This has been added to the Simplex page and will appear after the documentation is updated. It will be removed if they add verifiable builds and update their documentation in the next release - Iâll keep an eye on it.
By the way, I saw that you were posted Soatok articles on another forum. I wanted to ask what you think about this XMPP review Against XMPP+OMEMO - Dhole Moments? Is there anything very important that should be noted in the wiki? I mean - outdated versions of Omemo, 128-bit encryption, and other remarks. This is the most up-to-date perspective on XMPP - all other reviews are quite outdated.
ps Yes, that page XMPP | Specifications points out that Dino and Gajim use an outdated version of OMEMO. The last update for this version was on 2018-07-31.
Meanwhile, even newer versions of OMEMO (Version 0.4.0 and Version 0.7.0) are still considered experimental and not recommended, even though these are from 2020! XEP-0384: OMEMO Encryption
WARNING: This Standards-Track document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems are advised to carefully consider whether it is appropriate to deploy implementations of this protocol before it advances to a status of Draft.
So, weâre either using outdated encryption or untested and incomplete encryption.
Version 0.7.0 introduced yet another protocol change: The HMAC-SHA-256 authentication tag is now truncated to 128 bits.
I thought it would be worth testing other XMPP clients with the latest versions of OMEMO and adding them to the wiki. But XMPP itself states that their use is not secure. However, using a 7-year-old version is considered normal. I didnât use XMPP and wasnât aware of this. I will note this in the documentation.
They might be failing to properly contextualize for readers with tunnel focus on other subjects (security). Theyâre talking about standardization. Not implying insecurity of encryption.
And this is an insecure thing?
You cannot look at â128â and conclude âbadâ. The â128â number comes up often and is considered secure. Depending heavily on the context.
It needs to be interpreted by a cryptographer.
Taken indefinite retention and retroactive policing into account, if the cryptography is secure, it shouldnât require any upgrades ever.
To my knowledge, at time of writing, TrueCrypt itself has never been publicly broken in the sense of someone defeating its core encryption of offline data through cryptanalysis or brute force attacks. Even though the last version was released more than a decade ago. (Discontinued project.)
(Not a recommendation for TrueCrypt but to show that no updates were necessary, and thatâs a good thing.)
OMEMO update might be useful, have new features but might be unnecessary for essential security.