Secure messengers for safe and private communications

Requirements

Free software license

This has nothing to relate about price, but about freedom. I will not explain in details here, so refer to GNU clear definitions.

A libre/free software license does not restrict the usage. Safe licenses such as GPL ensure that the license won’t change in the future to restrict usage. The real danger is a project to be taken over by a predator company to enslave its users, and change, at will, the user’s license. However, for active and beloved projects, this usually end in a code fork such as MySQL and Mariadb.

Having the source code is not enough to be qualified as free software. (opensrouce is not free software, it is one of its feature). All programs involved in the messaging service should be under the same license conditions, and source code provided.

Network models

Centralized

Centralized architecture means we fully rely on a vertical model. This is the simplest model, but also the most problematic, regarding user safety.

• surveillance
• data hijacking
• attractivity for criminal acts (huge data, bigger profit)
• censorship
• unwanted change in policies decided by a minority
• business model to sell user social graph with metadata

What also happens, is that, part of the architecture, is not open as in free software, so you get a free and open client, but their cloud/servers aren’t.

Common centralized models also rely on user tracking for ads and inject unwanted contents (WhatsApp, SnapChat, Skype, ….) => this is the worst model, while being the most common…

The comfort you trade for your privacy and freedom is that you don’t care about the infrastructure, you sell your private data for the service to work.

You submiss to the company owner decisions. Actually, the simple isolated client-server model is exactly what was in place before Internet. Internet strength is about resilience, resilience is about decentralisation and interoperability.

Federation

It permits to self-host and not rely on others for the server management. Your server interconnects with others but you keep control on your server. You are still on client-server model though. Federation is a decentralized version of the client-server model. Email is the popular and oldest federated application protocol. Newer protocols such as ActivityPUB for social networks are there to encourage such interconnections, which is actually the Internet way of doing things!

You are not forced to self-host. You can ask friends, local associations, small companies you know, to manage the service for you. You are not tied forever to them. Whatever you decide in the future, you can still self-host and manage directly or with other friends etc… You can easily find communities you share policies and host with them.

By decentralizing, surveillance becomes harder, as many many targets have to be considered. Also, for data hijacking, this will be more complex as many entities will make different choice of platforms, configurations, and one attack scheme will not be enough. Heterogenous environment are good for overall security.

Federation is also one step better against censorship. Censoring a centralized model is very easy, but denying access of several entities becomes harder to identify and achieve.

Distributed

It is the preferred layout, but also more complex than the others. Not relying on a limited set of servers is quite interesting, we can rely on a network of nodes that is not anymore a single point of failure. We don’t care which nodes go offline or online, we can use distributed databases, and manage the routing dynamically. This also means that your connection actively participates in the network, there is no more client-server model. Bittorrent is a famous example of a successful protocol, even though you may use tracker servers or trackerless mode.

What other feature do we need?

Contacts Presence privacy

On many chat applications, contact discovery is quite automated and it is enough to then monitor the presence of the contact without requiring the contact peer to authorize an explicit permission. This can be abused at different levels. There are security options that permit to protect against that, but on popular apps, the top priority is to easily connect to anyone. Consequence is that default permission are quite open. Contacts in adressbook, untrusted by that contact recipient, can then be tracked. Either it discloses its detailed information such as time last seen, either it shows online/offline presence and still allows for tracking. For apps that may leak that information without explicit owner permission, that kind of tracking can be deployed for many and we can then build correlation between them

Mobile client

it should run on mobile computerphones, f-droid approved as much as possible.

Desktop client available

for GNU/Linux at least. It would be good to provide console and GUI client.

Overlay anonymous network friendly

Tor, I2P, .. If we can hook the program into such overlay network, we get the confidentiality provided by these networks. A messaging application alone will not be able to provide such feature.

File transfer

transfer files between peers with the file metadata protection if the transfer does not occur in a peer-to-peer manner.

Voice calls

an integrated chat + voice call would be great so we can focus on that project for all communications. However voice calls expose peers in peer-to-peer connections, or they rely on a proxy server that itself will see who communicates with who. Such real-time communication brings tradeoff for strict high privacy.

Video calls

as optional, a quite important feature, but not as high priority as the others. Video calls comes with the same tradeoff for privacy as voice calls.

No proprietary dependencies

program code MUST not rely on proprietary code or privacy-harmful pieces. No Google messaging block, no Facebook SDK! It would be meaningless to build a serious messaging application for privacy protection, and in the same way let big data actors collect all you connections with your contacts or all th events of your messages. In the last case, it could be tolerared depending on your threat model, but I dislike supporting such data collectors.

Multidevice support

as we commonly use several devices, it is convenient to use a single user id on these devices, so that it remains out of a mess.

Interoperability

no vendor lock-in! This is an important point. Either we play alone and just try to steal users from other messaging systems, or we agree that there can be other messaging systems, but we can interconnect with them, or at least provide an API that leave open door for contributions so that it can be possible. Interoperability does not mean here that it must only use standard protcols such as HTTP or XMPP. It means more: provide an API so we can create integration bridges, like Matrix provides bridges for many closed applications. To be fair, most FOSS projects in the messengers field currently focus on solving the privacy issues first. So it is no surprise that only Matrix/Element focuses first on interoperability, less on metadata protection, while also working on it but at a smaller pace.

End-to-end encryption

There is no reason to make it optional on today’s Internet.

Protect metadata

now that most popular chat systems enable e2ee, it is time to work hard to restrict metadata exposure. They are worth like diamond for social graph exploitation (abuse). Metadata are part of the things that you give to providers without really being able to select what you expose or not. They can reveal more private details than data themselves. Metadata can reveal your location, your behaviour, your social relationships. Would you really encourage companies to sell data based on these criteria about you and your contacts?

No phone number or email required

this is linked with earlier metadata feature. User should be able to have a user account that is in no way linked to their phone number or email address. The problem with the way it is done with SMS (Signal, Telegram) is that this implies that the provider now knows who you are and it is too late if you wanted to have a good level of privacy in their network. The phone number is an ID that gets collected in so many places that then it reveals easily who you are. Data crossing and correlation is key operation in data mining. The other interesting feature with create a new keypair instantly instead of relying on a register server, you just create your keypair, (apps that use this feature usually use keyspace of 256 bits, which means 2^256 in key set, which is currenly clearly enough collision-safe), and you can have the profile/username you want, forget about mary33_2001, just use the name YOU decide to use.

Programming Languages

Most mobile application are written in Java because this was the first language for developing applications on such devices. Newcomers such as Cwtch, Berty, however prefer to use modern languages such as Go. As Rust is coming to mobile devices, several new projects favouring security will probably target such modern languages.

Projects

Conversation, profanity, Gajim XMPP

It uses a protocol that allows for decentralized, federated network setup, so you have to get your client connected to an XMPP server, whether it is you own or from an existing server.

It is not end-to-end encrypted by default. The interesting feature, with the cited clients above, is that it can use OMEMO for end-to-end security. OMEMO uses peer to peer connections for file transfer. It uses Jingle XEP-0234 protocol but as the data raw encryption end-to-end. Metadata such as session details, file content type, are not e2e encrypted.

XMPP is a mature protocol and very popular, available with several servers and client software. It uses XML packets.

XMPP is a federated protocol. It means, you can use a self-hosted xmpp server and connect with other xmpp hosts to build decentralized and federated communications.

XMPP is limited to messaging by text and files transfer, voice calls or video calls are not available. However it is a simple and secure way to build self-hosted federated communications. XMPP is popular and many ways to integrate it.

Conversations can provide OMEMO with its contacts, which ensure high level of confidentiality. It can also provide voice and video calls. It requires a STUN/TURN server, linked with the xmpp server.

For multi-peers video or audio calls, Jitsi may be preferred, but this is a different application.

• Good: self-host, interconnect, omemo, otr, opengpg encryption, lots of clients and code libraries, anonymous network support (for instance, you can connect over Tor, client to server, or, server to server), Jingle provides p2p voice and video calls (coturn, stun/turn usage)
• Bad: legacy protocol, xml format, not e2ee by default
• Use case: good text lightweight program that can be integrated with any sort of log or notifaction system. Easy to interconnect with other people self-hosting. Does not suffer from a proprietary contact connection, anyone using XMPP with their favorite program can connect with you, or you with others.

Matrix/Element

Project to replace XMPP. Designed with modern concepts, JSON formatted. Matrix is an open standard for interoperable, decentralised, real-time communication over IP. It provides bridges for add modules with proprietary applications with lots of effort to try to make it work against companies that invest in gated communities.

It can be used to power Instant Messaging, VoIP/WebRTC signalling, Internet of Things communication - or anywhere you need a standard HTTP API for publishing and subscribing to data whilst tracking the conversation history.

High level of integration and interoperability. Built on mature protocols. Provides solid E2EE. Matrix doesn’t e2e-encrypt metadata (timestamp, sender, recipient).

Personnal data exposure is limited to your hosting server instance you connect to. As for XMPP, federated means you decide what to commmunicate with other servers. But be aware that several data are sent from the client to the server (email address, ip address, device information, contacts, rooms id). This is why a self-hosted or close community hosting server should be chosen first.

Matrix P2P

There are initiatives to design a matrix client-server-self-contained to design a peer-to-peer model for Matrix. This would simplify server hosting for the user, empowering users to have total autonomy and privacy over their data if they want (by storing it in P2P Matrix, by embedding their server into their Matrix client), while also letting users store their data in serverside nodes if they so desire. The goal is to protect metadata much better (as users no longer have to depend on a server run by someone else to communicate), as well as drive new features such as account portability, multi-homed accounts, low-bandwidth Matrix and smarter federation transports.

Pinecone network using libp2p is under research for a possible routing and transport network that would provide matrix-p2p the security layer it derserves for communications, and protect the metadata currently under exposure to the registered server.

P2P Matrix is about more than just letting users store their own conversations: it can also avoid dependencies on the Internet itself by working over local networks, mesh networks, or situations where the Internet has been cut off. We see these goals more and more, like Briar takes care of also.

Currently, nothing is mature enough for the general user, however the perspectives are very interesting and could make Matrix/P2P a success for privacy and usability, mixed with federation. Stay tuned!

• Good: very high interoperability, strong e2ee, full featured with webrtc streams, self-host, federation, encrypted rooms ensure encrypted files transfer and sharing. Special note: it is the only project so far that make lots of efforts for integration and interoperability. transfer.
• Bad: no currently serious metadata protection from the subscribed server, even though federation limits metadata exposure to other matrix servers. Advise: don’t use the principal matrix server and find another, or, self-host yours).
• Use case: daily communications with your contacts, create rooms for your group of friends, self-host, teams, good for day-to-day with friends, team work.

Signal

The very popular messaing app. By default end-to-end. It uses its own protocol, well documented and audited. It provides free software libraries and client.

The 2 main drawbacks I see : centralized architecture, it is linked to your phone number.

Signal does not keep contacts, social graph, conversation list, location, avatars, profile name, group membership. There are efforts to reduce exposure, but I insist : a centralized model will always be the hub, the central point to route all communications with other contacts. Internet is about federation and distributed systems, owned by many many different entities.

Signal Protocol with Sealed Sender (Sealed Sender encrypts who sent the message) activated protects message metadata, this means that Signal won’t know the sender of a message and only the recipient token. This is a great improvements, and they know they have to deal with transport/traffic analysis, this won’t be enough. While Signal engineers made great work with zero knowledge proof and homomorphic encrytion, it won’t solve the network level issue. Eve trackers mght be on the edge can still analyze and inspect traffic from clients to signal servers.

• Good: audited code, strong crypto layer, popular adoption among users
• Bad: centralized client-server model, requires phone number (has become optional AFAIK), no anonymous network support
• Use case: good practice to replace whatsapp by this program, one step to better security and privacy, but we are still in a centralized model and non-interoperable scheme. (There is a matrix bridge btw but this is not api provided)

TOX

Uses DHT to locate clients and setup connections. It works with UDP for voice and video communications, and uses ICE (STNU,TURN,UPnP) to be able to solve the NAT/firewall problem.

Tox protocol uses UDP hole punching technique to setup p2p connections from NAT envrionments. It does not use SIP for signalling, but uses RTP for media streams. Onion routing is used to exchange messages for initial connection between 2 clients. Working with bootstrap nodes and DHT.

Generated temporary public key (256 bit) is used as key_id of peer and stored on DHT nodes. It uses same method as bittorrent or ring to find closest nodes to final node. Sender then uses onion routing to send real public key to recipient’s node. Recipients follows same concept to complete handshake with the sender. EC25519 is used for key exchange.

Tox is not 100% distributed. It has to handle mobile devices issues (resources, energy), and provides TCP relay by default, but you can force UDP and it will work as a real p2p clients. Bootstrap nodes are not from a huge list and mainly maintained/provided by tox foundation members. Tox clients can declare themselves as TCP relays in the network. Depending on the tox client implementation, some offer the option to define the list of bootstrap nodes (like toxic), some others don’t (qtox). It can be of a concern to use hardcoded bootstrap nodes. You should be free to select nodes from the official list of registered nodes. Any client can also run a node for bootstrap.

E2EE : xsalsa20 for encryption, poly1305 for authentication. Ttemporary keypair generated that gets stored in DHT are not directly related to long-term master keypair. Each DHT node has its own symmetric key.

Master public key is then never directly exposed on DHT nodes, they are safely transmitted to contacts inside onion routing messages. Client’s ip address is stored encrypted in DHT.

It is readable only when request is made with correct tox ID. A nospam number is also added in the tox id, it is meant to be changeable to prevent easy tox id guessing and friend request spamming. No phone number or email required.

CAVEAT
Tox assumes frend-to-friend social network. This means that there is no effort to protect the ip address between each friends. Your ip address is revealed to your friends but is hidden from people that you did not accept as friends.

• Good: free software, distributed base model, e2ee, metadata protection mechanism, tor-friendly, keypair as user account creation.
• Bad: p2p model on mobile devices is hard problem for energy use, not mature enough for mass adoption, stronger code audit is welcome.
• Use case: regular daily contacts, can use voice and video calls, limited metadata exposure with call streams features, easily echange files, full workstation or mobile devices, full GUI or text console mode.

Briar

Mobile devices targeted : currently only Android. No command line or ncurses based client. Can use direct bluetooth or WIFI (p2p). Uses Tor onion services to interconnect. Code security audited. Group chats limited by invitations or public forums are available. A light blog and RSS features are also available. As it uses Tor, TCP based, so no voice or video stream.

A Desktop version is available, resources and contributions welcome. This version is written in Kotlin (faster java integrations). Versions are available for GNU/Linux and Microsoft Windows OS. While available, they are still under active developments, not to be considered as stable solid, but great for early testers.

In the archiecture of Briar, the message synchronisation relies on transport layers that can be: Tor network, WIFI, bluetooth, removable drive. The use case for different transport mechanism prepare for cases where Internet is unavailable but LAN with community is still possible. In case LAN context is of no use, users can still echange messages with sd cards as a last resort. These transports do not impact the crypto layer that provide message secrecy and contact authentication.

• Good: made for high privacy in mind, simple to use, uses Tor network by default or direct p2p
• Bad: no voice or video calls.
• Use case: tor-protected communication, no social graph, can provide good level of anonymity between endpoints, limited to Android,Linux,Winddows OS.

• Language: Java, Kotlin

Cwtch

Cwtch is in the same family concept as Briar. E2EE being quite easily achieved with the different encryption libraries available, the hard problem remains the metadata, which are, BTW the most important issue.

ip network was never meant by design for privacy, so it is a complex puzzle to provide such layer while directly using ip network. Most solution use a centralised model with all the drawbacks we wanted to avoid.

Solution that is solid and efficient : use an overlay network this is designed for such privacy : Tor.

Cwtch metadata protecion is then ensured by using onion v3 services. Each user account is actually an onion v3 service. To interact with another user, both onion services use a rendezvous protocol within the Tor network. There are NO central servers, messages can only be sent once the other user is also connected.

Each user profile is tied to an ECC keypair ed25519. So this is easy, fast, independant, to create a new profile, if you want to isolate contexts or use unique usage user profile.

Groups use a server that can be self-hosted. The sysadmin of the server cannot reveal who communicates with who on what topic. A isngle group on the server won’t reveal how many members the groups is composed of.

Cwtch handles in the background the onion v3 connection while the user is not using the application.

This is a newcomer with solid security goals and design. It is a real p2p application as it relies on no central server and exchanges messages directly with the contact in the dialog. Both parties MUST be Exception for group messaging that relies on a server, without lowering the privacy level.

Onion services use directory services as bootstrap and add consensus security layer. Rendez-vous protocol between onion services ensures authentication and confidentiality. An ephemeral session key is used for communication.

• Good: using Tor onion v3 services ensures for very high level of privacy, user account is not tied your real identity, user can create multiple user account in the application, rotate the user accounts, make them ephemeral
• Good: good privacy design : only allow exposure by explicit consent!
• Good: Clean API and libraries permit bots and custom development integration
• Bad: no voice or video calls, but this is the constraint of tor onion tcp protocol design
• Bad: Application not yet on f-droid repo
• Use case: as for Briar, this provides highly confidentialy messaging, be it fr long term or short term, ephemeral and unique
• Language: Go

Session/Oxen Messenger

Code fork from Signal encryption scheme. Several modification applied.

Metadata protection : no phone number or email required. Identity is created indivudally by creating strong keypair. Your profile name can be anything you want, no conflict with a central registry. You can delete-create a new session identity at anytime, those identities will have no relationships.

A long-term X25519 keypair is generated for each Session account at time of account creation, and the public part of this keypair is the account’s “Session ID”.

PFS protects against accessing old messages as regular session keys are re-generated. In the case of a messenger, if an attacker can access the device with the messenger, all messages are stored on the device. So, PFS or not, in that context, the result is the same. Without the devices and stealing the longterm private key, an attacker won’t be able to read the conversation, PFS or not. Session does not provide PFS.

Signal protocol provides deniability. It can hide long term key conversation relationship. In practice, this is moderate as for many cases, seized devices are used. Session does not provide such deniablity, signatures are immediately deleted after validation so attacker would need to have compromised long-term keypair to scrape the message before the signature was deleted. Session will add the ability to edit other users’ messages locally, as signatures are shortly deleted, this won’t prove authenticity of text contents.

Signal’s central servers have a log of which IP address sends which message and which IP address retrieves that message. With Session onion routing this is not possible.

Based on the Loki now Oxen anonymous network as an anonymous layer with onion routing as in tor. Application provides group chat, recorded sounds, file attachments. It uses monero code for blockchain module to provide proof of stake on router nodes in order to protect against Sybil attacks so that we can avoid to rely on any central authorities and use trustless servers to carry mixnet message anonymously. Oxen network is also used for a cryptocurrency under development. ($OXEN)

Messages are temporarily stored on multiple Service Nodes within the swarm to provide redundancy.

Session is not a pure p2p messenger. Swarms form the distributed network, session client connect to them via the onion routing. This solves the energy issue for mobiles devices (such that tox meet in udp, pure p2p mode).

CAVEAT:
Oxen is hosted in Australia. Australia has invasive privacy laws with encrypted communications. While this may create unanswered questions over time, the project is still opensource and sources can be verified outside Oxen. Australia is NOT the best country for data protection, this is true. However more and more countries vote for laws in that direction …sighs…. Even Switzerland, which remains probably among the best in the list, acquires new laws about data interception. USA cloud act can act in any country… So this is very complex, BND in Germany may pressure communications companies too… It it not very clear how far data can be leaked from Oxen with the current protocol, seems quite complex anyway. So think about it, but I wouldn’t abandon just because of fear, it should be adequately evaluated with theat model first.

• Good: metadata protection, client app connecting to distributed nodes, mobile and desktop platforms, free software, loki network ecosystem integrated, multi-device support. Code and design have been externally audited. (Quarkslab)
• Bad: PFS code removed but can be more or less argued… Threat model has to be considered then. Videos and media posted are of limited size.
• Use case: you can replace your usual messenger with this one, this is the only one that by design provides metadata protection by integrating an anonymous network overlay. Voice and Viceo calls work, tradeoff is giving your ipaddresses to media provider, again, depends on theat model. (voice and video calls MUST use some direct realtime network routing which does not currently fit the onion routing, but a solution is in progress to solve that miss)

SimpleX

Here is an impressive opensource project, ambitious, with a different concept a usual, but using mature public strong crypto layers.

Part of the application is written in Haskell! This is great, use a pure functionnal language provides some clean design and won’t leak with all side effects of many other languages. Kotlin and Swift are the usual other suspects for mobile application programming.

Application is available for all mobile platforms, as well as terminal and cli linux applications.

SimpleX cares about privacy in the complete scheme: data, metadata, profile, contacts. There is no permanent identity for a user. Modern secure applications, such as Session, ties a ECC keypair to a user account. While there is no need for email, phone number, it links a permanent identity (keypair) to the user account. Cwtch is in the intermediate state, you can easily manage how long you want your onion identity to keep, manage multiple at the same time, or only use ephemeral identities, but it remains 1:1 during the period of use.

Key concept: SimpleX uses the addresses of unidirectional (simplex) message queues. Like having a different email address or a phone number for each contact you have, as Cwtch permits, but without the need to manage these details.

A planned feature will be to rotate servers connections to improve discretion and hide even better social graph. Tor integration is completely possible to provider another layer of confidentiality.

You cannot be contacted unless you share a one-time invitation link or an optional temporary user address. You are in control of your exposition, permanent, ephemeral, only via explicit invitation link, it is up to you. This is a really different paradigm as once your identitiy is known, anyone can abuse, and forced to change for a new user account, As in friend-to-friend concept (Session, Tox), nobody can message you, unless you explicitely accept the contact. Email is fully open to SPAM because, by design, you first receive the messages.

SimpleX stores all user data on client devices, messages are only held temporarily on SimpleX relay servers until they are received. This is usual, servers act as store-and-forward agents, but only store encrypted data objects. SimpleX servers do not store user accounts.

Sent and received messages are encrypted the same way, there is no distinction. So if anybody is observing server traffic, they cannot easily determine who is communicating with whom.

You can self-host your SimpleX servers for a private community for instance, and still use official servers to interact with other users, again, you are in control of what you want to as interaction.

SimpleX platform uses an open protocol and provides SDK to create chat bots, API integrations.

SimpleX has identifiers for message queues, separate for each of your contacts. Current proto: each queue is used until the contact is deleted => planned: queue rotation to the client protocol, so that even conversations don’t have long term identifiers visible to the network.

You define which server(s) to use to receive the messages, your contacts – the servers you use to send the messages to them. Multiple servers can be defined for resilience.

Multiple servers: message relay nodes, async message passing, via unidirectional (simplex) message queues, providing recipient and sender anonymity. All messages are passed through one or several server nodes, that do not even need to have persistence. (in-memory message storage) No global participant identifiers are used to deliver messages.

Unlike federated networks, the server nodes do not have records of the users, do not communicate with each other and do not store messages after they are delivered to the recipients. There is no way to discover the full list of servers participating in SimpleX network.

Observing the network graph on the application level is more difficult, as for n users there can be up to n * (n-1) message queues (spread over s servers).

End-to-end encryption in each message queue using NaCl cryptobox. Curve25519 keys are used for key negotiation.

Double ratchet end-to-end encryption in each conversation between two users (or group members). OTR messaging with forward secrecy (each message is encrypted by its own ephemeral key) and break-in recovery (the keys are frequently re-negotiated as part of the message exchange). Two pairs of Curve448 keys are used for the initial key agreement.

Additional layer of encryption using NaCL cryptobox for the messages delivered from the server to the recipient. This layer avoids having any ciphertext in common between sent and received traffic of the server inside TLS (and there are no identifiers in common as well).

Only TLS 1.2/1.3 are allowed for client-server connections, limited to cryptographic algorithms: CHACHA20POLY1305_SHA256, Ed25519/Ed448, Curve25519/Curve448.

SimpleX servers require tlsunique channel binding as session ID in each client command signed with per-queue ephemeral key.

Once you install the app, create your local profile, not shared on servers, but shared with you contacts when connecting with them. Create a one-time connection link or QR code. Only one user can connect via this link.

With SimpleX there is no meta-data in common between your conversations with different contacts.

___Note: I will add more details to the protocol designed SMP and XFTP.

• Good: Haskell is alive!
• Good: new paradigm detaching from permanent user identity, metadata protections, self-hosting, full control of your exposure
• Good: Tor integration, cli console tools, API integrations with SDK
• Good: Seems to catch balanced compromise with severs selection and avoid distributed design issues
• Good: code has been audited
• Need to go deeper: temp user address, queue id rotation, SMP XFTP protocols designs

Berty

A newcomer to the family. It is based on IPFS peer-to-peer content location network. It uses state-of-the art ECC. E2EE is on by default on all communication.

Berty provides text messaging and file transfer. Identity is keypair so no username needed or phone number. Group chat is available.

Bluetooth Low energy mode can be used as offline mode to communicate.

Programs are available for many platforms mobile or desktops.

Connect with your contacts with a QR code, public key sharing, invite link. Multidevice per user account is supported.

Bery relies on IPFS layout. However, in the design of IPFS, privacy protection is not a main goal. IPFS is much more oriented towards solid authentication for public data. Nodes participating in the network can be found from the public DHT and gather information about data (CID) they provide or retrive. In that aspect, IPFS cannot protect again a social of the interactions.

Berty tries to workaround with PeerID renewal, but this is really not safe enough for serious cases. They admit that they are still in WIP to find a better solution.

Do not use it for serious privacy of communications. It currently only provides E2EE and authentication in that area.

IPFS is not adequately design to be used with Tor, nor I2P. Don’t use Berty for communication that need more than content encryption.

• Good : solid IPFS layer, availability on variety of platforms, good level of privacy with ease of use
• Bad : not meant for anonymous communications but metadata moderately protected
• Use case : usual contacts for text and file sharing, taking advantage of p2p

Note : more evaluation details to come

Conclusion

I can not advise a one-for-all solution, and there won’t be one seriously. Depending on your priorities and goals some projects are more adequate than others. This page is meant as an ever ongoing update process.

Probably you can use one that will be popular choice of your contacts for regular communications and advise them to switch to safer communication program. Then dedicate another for highly confidential one, because of security constraints against communications realtime constraints, it will be a complex problem to solve for some time still.

What I would like to become a kind of winner is not a full-featured app, but a set of protocols that we can use to build different set of tools with, joining a mixnet to cover our tracks because metadata protection is the only path to correct privacy, regulations fail for now and they probably will continue. We have to design a technology that just does not permit such privacy violations.

Providing high metadata protection in the clearnet is nearly impossible without an overlay network such as Tor or I2P. Briar and Cwtch messenger are built for Tor network.

Special note for Tor

The Onion Router…Onion routing decouples ipaddress from sender and receiver. 3 layers to isolate such information, like onions layers, you can’t reveal the inside from the outide.

tor is a mature and active developped project, it can quickly provide this high privacy level of decoupling for any tcp-based protocol. UDP is not working and not compatible on top of TCP, while the reverse is possible like VPN (wireguard, ..).

Briar and Cwtch are developped to rely on the security and privacy features provided by onionv3 services. Each user account is setup as an onion service, no central identity autority, you can use the accounts for long-term or ephemeral usage, as you prefer.

Communication is established by rendezvous protocol subset of onion services, providing high privacy for the sender and the receiver, any contacts. The constraints, as in peer-to-peer protocols, you need to be both connected at the same time, messages won’t go in a store-and-forward node swarm like Session/Oxen is setup. Subset of the application can handle this for the user in the background actually, so solutions are getting built and improved.

Tor-compatible applications such as XMPP applications also provide a way to enhance your privacy level.

Special note for I2P

I2P provides the mixnet layer for serious privacy metadata protection, even though this will imply some laency due to its design (and security level), users can use IRC or client-server model on top of I2P.

Concept is a bit different than the messenger app usually understood, but using the i2p layer, brings directly p2p design and the high privacy desired.

I2P provides garlic routing. All nodes participate in the messaging routing and delivery, no central servers at all. It is pure peer-to-peer design. Garlic provides some ading value for rendering complex the identification of a node sender and receiver. Traffic analysis becomes very hard. However, I2P is not meant be a proxy to the clearnet, all the benefits come with using only its mixnet overlay network and provided api/socks for building applications on top of it. No need for highly encrypted applications as I2P layers already take care of it, but applications like OpenSSH work on top of it.

On mobile devices, i2p app exists to connect to i2p. So, you could use an IRC i2p compatible and connect via i2p to an IRC server. In this use case, anonymity is superior to confidentiality. IRC server will get data in clear, but won’t be able to know from where and from what identity. You could self-host the IRC server behind your i2p tunnels.

There is a p2p i2p application. This way, no server at all, full p2p, and highest privacy level you can achieve.

With some work, cwtch could be interface with i2p. i2p provides well defined API for intefacing with the i2p network.

More to come.

Obfusaction and risks of use

Until now, we assumed Internet usage was provided as a freedom, without serious aggressive blocking mechanism and wide legal use of such communication network.

However, in many countries, the use of security and privacy mechanism on the Internet is simply illegal and assimilated as a spy or terrorism act, which lead to serious awful consequences.

Oppressive regimes play on the legal side, as on the technical side this is very hard to block. This pressurizes alot the user of such security coomunication tools.

One important feature in such use-case, where using Tor, I2P, Oxen network is declared illegal, is obfusaction.

Oppressive regime can block defined set of servers for Signal for instance. While a workaround can be the use of VPN, Tor, peer-to-peer i2p or other overly networks, DPI (deep packet inspection) may reveal the kind of protocol you are using.

If you are identified from your phone of computer and DPI confirms you are using Tor, and Tor is illegal, then you are at serious risk.

So now in this kind of scenario, the priority is obfuscation, looking like a regular user of regular applications. So you could turn to Signal, but Signal servers are blocked….

You now need obfuscation techniques…but…this is a hard problem and looks like an arms race too. DPI techniques evolves and learns to become more efficient, and new techniques of evasion evolve also, but nothing is perfect in that area.

Tor provides transport modules that will help obfuscation and DPI blocking.

You may use a VPN, assuming you can ensure the VPN endpoint won’t lie to you. So don’t use VPN of same country, verify reputation from customers reports, etc.. Then you can use your secure messenger or Tor or I2p on top of it. However, VPN usage can also be detected, so again, this is to be evalutated on a case by case.

For instance a VPN and connecting to a public Cryptpad instance, may look like a regular connection to a web site, but cryptpad from vpn and Tor can let users safely communicate and look quite normal.

People can also use social network such as mastodon from a VPN to post a picture with steganography to hide a message. Or your VPN + Tor and connect to a social network (and not connecting from anywhere else) to post or read a message.

Messaging project such as Briar feature LAN, Bluetooth communication for close communication that does not rely on Internet at all but still provide strong authentication and encryption between the contacts.

Tor OONI is a great project that help building a map of network censorship and blocking features over the world. This will give you an good estimation from collected metrics on what is blocked, how efficient it is.

How to choose??

There is no easy answer. Evaluate the threat model involved in your goal.

Based on the strong features of each messengers, you will pick the closest to your ideal one. However, user adoption is specially complicated, and none of these will become the one for all at any time.

As for interoperability, the only project in that direction is matrix.io, building bridges with other applications.

Of course, people can argue that usability is first choice and having all his/her friends already on whatsapp is enough to just use it and no worry further.

I understand the complicated situation that convincing all your friends is hard and why should they follow you, why should the be in the same complex situation with their own other friends, and friends of friends…. Well…it is a hard problem, but I could somehow argue with food analogy. If your friends only eat in industrial fast-food and you prefer organic and well-cooked food, how do you solve this?

What issue do you try to solve?

• Avoiding censorship?
• Protect the privacy of your contacts because they might be at risk
• Less data/metadata tracking is better anyway
• You don’t want to rely on Evil Corp
• You work with people in anonymity to discuss without pressure and judgment
• You are an activist for climate change and try to organize event wihout being tracked
• You are a journalist and you protect your sources seriously
• You understand with depth the citation from Edward Snowden: “Arguing that you don’t care about the right to privacy because you have nothing to hide is no different than saying you don’t care about free speech because you have nothing to say”