73 HB9ERY QSL

Confidential communications

jma@mbuf.net (jma) — Wed, 20 Aug 2025 00:00:00 Z

## EU end-to-end-encrytion critical concern

## Use safe messenger to apply for private communications

Private and confidential communications is key to mandatory privacy and democracy models. In a private conversation, nobody invited should be able to interfere, influence, pressurize with social judgment. Integrity must ensure original contents are not modified from end to end.

There are recurrent debates to lower security of communications, in order to track criminals. However, this is mathematically not realistic: weak security for criminals, strong security for innocent people. Strong security is preferred at all times.

# Requirements

## Free software license

Mandatory to have clear full freedom use of the project. Features and benefits for such kind of license can be found within GNU clear definitions.

A libre/free software license does not restrict the usage, no unclear context, no ambigous text. 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 details.

However, for active and beloved useful projects, this usually ends in a code fork such as happened for MySQL into MariaDB.

Having the source code is not enough to be qualified as free software. (opensource 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.

Publishing source code permits any user into programming to verify that program actually does what it should. Verification is fundamental. It does not mean code will be audited, but it does ensure that anyone, into verifying, can do it, whatever is her motivation.

This mitigates options to publish a backdoor and ruin the security reputation of the project.

## 3 Network models

### Centralized

Centralized architecture means we fully rely on a vertical model. This is the low hanging fruit model, but also the most problematic regarding user privacy.

All power and decisions are delegated blindly from users to director(s) of the entity. (Recall user censoring issues with X/Twitter)

Surveillance: all your connections, you contacts, your data, connect to same entity of servers. Easy to track the user.
Data hijacking: centralized data hub build huge attack surface and abuse profit.
Censorship: In a vertical model, top can cut any communication at will.
Business model: Selling user social graph with metadata for big profit.

There are hybrid models: client program is fully under foss license, but the servers are under a proprietary license, hidden details. 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 => this is the worst model, while being the most common. WTH! You trade your privacy so that you don’t care about the infrastructure. You sell your private data for the service to work and a large profit margin.

You are enslaved to the company owner decisions. All will be made to discourage you to migrate to a new application or cancellation, although thanks to GDPR, there are few improvements.

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

Think about all users connecting to different servers: self-hosted, school hosted, university hosted, association hosted etc… Each server belongs to small group of people with their own policies. Each server can interact with any other.

You are still on client-server model. 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 much 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.

Federation is about freedom to build or organise yourself and ensure you can then interact with others. There won’t be vendor lock-in that will force you to use a specific tool.

As soon as you own a working email, your contacts don’t care what mail technology you are using.

### 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.

Distributed model does not rely on permanent dedicated set of servers. Full distributed design is complex because of Sybil attack. Managing safety in an untrusted network require special design care.

In real cases, some use set of dedicated bootstrap servers, or hybrid models with set of authority servers, proof of stake for consensus decisions.

Not relying on dedicated infrastructure that must be managed is a huge benefit. No easy surveillance, no censorship, no central control.

Social interactions: such dynamics towards users is much more realistic as in real life than vertical centralized models. Structure of the network evolves according to social interactions.

## What else?

### 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

### Overlay anonymous network friendly

Tor, I2P, NYM, provide very solid overlay network to provide different kind of serious privacy.

Tor provides decorrelated ip address layer for Internet and Tor internal services, onion routing.

I2P provides its own overlay network, using garlic routing, meant to be used only within its distributed network.

NYM network is a young, still under development, serious privacy network. Its goal is to provide full modern anonymity with full data and metadata protection, timing analysis protection. Current provided VPN, using full metadata protection is still very slow to use.

Nym provides multi-layered mixnet network, decorralating any source and destination ip addresses pairs. It injects fake packets, modifies transfer time at packet-level, and can provide uniform size of packets. These techniques should provide serious blocker to DPI or timing analysis. Metadata are protected. Rust based. GPLv3 license. More to come. I may probably dedicate a whole article about NYM.

### 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

Ideal case is a very secure communication protocol with solid API server. There should be, in the API, open door for interoperability such as activitypub.

Without cancelling privacy, there should be a public API to still be interoperable. This would lead to some kind of interactions.

### End-to-end encryption

Not anymore a question today!

#### Aditional layers of protection

Message padding to protect against message size analysis
Plausibe deniability as better confidentiality
PFS for better messages protection
Break-in recovery vs long term encryption keys
2FA vs MiTM
post quantum crypto (long term encryption)

### Protect metadata

Still unsolved privacy challenge: metadata protection.

The critical issue is that metadata are more useful than data to invade privacy. Social graph permit to describe your social interactions. These can reveal who are you friends, lovers, their sexual orientation, politics orientation. Assuming geolocation is also provided, it is easy to describe where you meet your lovers, your colleagues, and so on.

So without any knowledge about you message contents, we can determine the context of your messages and to whom they are sent to. This is much more powerful than if we only had access to message contents, without knowing to who, what time, where.

Serious issue because Internet was not built to protect such metadata. TLS, still, currently, only partially solves the issue, so still not a solution.

Metadata can reveal your location, your behaviour, your social relationships. Recall Cambridge analytica major issue?

#### Aditional layers of protection

Anon + pairwise IDs vs real ID and social graph
Decentralized groups + Group IDs vs group existence
Onion routing against Transport, ipaddr
Session isolation, packet routing vs traffic correlations sess-
Fixed transport pkt size against traf correlation by pkt size

### No phone number or email required

There should be no requirements to link identities. This means no central registration with a phone number, no email.

Favor local keypair generation that do not rely on a central for identity creation.

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.

### Push tokens (mobile clients)

For mobile clients specially, there is a hard problem: how to handle notifications, active requests to handle in almost-realtime, and lower battery consumption.

This is a technical threat against metadata privacy.

Ideally project should use custom solution such as the great work done by Tuta.

## security and privacy definitions

padding: message padding
deniability: plausible deniability
PFS: perfect forward secrecy
recovery: Messages are encrypted using double-ratchet encryption, providing perfect forward secrecy and break-in recovery, similar to OMEMO
2FA: multi factor authentication
PQC: post quantum crypto
anonymity: Can provide or interact with anonymous layers
group: Secret groups are anonymous and private, they are designed to be hard to track by outsiders
mixnet: onion routing
isolation: session or stream isolation to provide better privacy
fixed packet: uses fixed transport packet size
delay: Async delivery with delay
push: push tokens

## Projects

### Conversation, profanity, Gajim XMPP

Baed on XMPP decentralized, federated network. Very mature and documented protocol. There many clients and server projects available.

Requires a user account on a server, self-hosted, or community managed.

It is not end-to-end encrypted by default. The interesting feature, with the cited clients above, is that it can use strong 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 e2ee encrypted. As long as this is a peer to peer connection, this is fine, within TLS connection.

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. Lightweight infrastructure, can be easily setup on a raspberrypi with solar panels battery.

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.

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: xml format, not e2ee by default, legacy protocol disadvantages, not meant for metadata protection, legacy user XMPP ID, no routing or packet privacy feature.
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 (federation). It does not suffer from a proprietary contact connection, anyone using XMPP with their favorite program can connect with you, or you with others. Else as using OMEMO for encryption, there are no safe layers for metadata protection. Last option would be to use Tor, hiding location, but identity is fixed and tied to your user account.

strong security features
deniability
PFS
push

### 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 is there for secure 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, and some nice popularity, mixed with federation. Stay tuned!

Feel free to visit their progress page to keep it up with their work.

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.

strong security features
PFS
2FA

### 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 main drawback I see : centralized architecture.

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. Also, even if you can now hide your phone number from your contacts, you still require to register with a phone number frist, giving your phone number to the central servers. It’s year YYYY, we should provide a unified way to interact without the mess of old phone numbers.

Signal works on features to protect against coming Quantum Computer that will be able to solve big prime numbers factoring and discrete log problem such as for DH authentication protocol. X3DH is the chosen candidate for even more complete implementation.

Good: audited code, strong crypto layer, requires username (not anymore mandatory tied to phone number), best popular adoption among users
Bad: centralized client-server model, no anonymous network support, required username, fixed identity, single identity
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)

strong security features
padding
deniability
PFS
2FA
PQC
isolation

### 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 exchange 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 but this is not the goal.
Use case: tor-protected communication, no social graph, can provide good level of anonymity between endpoints, limited to Android,Linux,Winddows OS. Dedicated for crises areas where unreliable internet connections, use bluetooth, wifi, sneakernet

Language: Java, Kotlin

strong security features
padding
PFS
2FA
group
mixnet
fixed packet
push

### 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

strong security features
padding
deniability
PFS
recovery
2FA
anonymity
mixnet
isolation
fixed packet
push

### 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)

strong security features
2FA
mixnet
delay
push

### 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.

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

strong security features
padding
deniability
PFS
recovery
2FA
PQC
anonymity
group
mixnet
isolation
fixed packet
delay
push

### Delta Chat

Delta.chat deserves really its place. It is a secure messenger built on top of email standard protocols. It can run on many mainstream email providers, you can check officially supported list from the project website. Delta also provides its own servers, called chatmail, set of mail programs, secured and adjusted by minimalism for delta chat use case.

In that context, you can use your existing email address, but it is seriously recommended to not mess with your usual email address.

The default signing and public-key encryption algorithms in Autocrypt are Ed25519 and ECDH over Curve25519 respectivel. Delta Chat additionally supports NIST P-256 and P-384 curves.

No PFS support: if your Delta Chat private decryption key is leaked, and someone has collected your prior in-transit messages, they will be able to decrypt and read them using the leaked decryption key.

if anyone obtains to your decryption keys, they will typically also be able to obtain your messages, irrespective if Perfect Forward Secrecy is in place or not.

chatmail servers can be self-hosted for private or public usage.

Good: multi-profile and multi-device support
Good: Can hide my real ip address, even from chatmail hosts by using Tor proxying
Good: security audit

### Quiet

Quiet is an alternative to team chat apps like Slack, Discord, and Element that does not require trusting a central server, and no requirement to self-host a server.

Data syncs directly between a team’s devices over Tor with no server required.

Quiet is not audited and should not be used when privacy and security are critical.

Quiet is written (mostly) in TypeScript, with Electron and React Native frontends.

Each group of people (Quiet calls them “communities”) gets their own insular network. Message syncing is taken care of by a project called OrbitDB, which works like a mashup of Git, a gossip protocol, and BitTorrent.

End-to-end Encryption
No email or phone number required
Still needs mature development, security audit
Quiet fully peer-to-peer
Each community creates its own totally isolated IPFS network, with members connecting over Tor
Users create a separate account for each community
user account: set of key pairs and a signed cryptographic certificate from the community owner
Quiet is for teams and communities, not individuals, Quiet lets users join specific communities or teams, each with its own owner and set of channels

Use case: small to medium communities for private communities messages and files sharing, relying on Tor network. Do not use it for a usual daily 1:1 messaging application.

### 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

# Coffee break

Wow…that’s a lot of information…keep relaxed. Have a small joyful small coffee break…

Ready?…best to come!

# off-grid messengers

2 very interesting projects must be cited.

They can communicate over Internet, but the real interest is participating in a fully off-grid distributed network. They rely on LoRa ISM bands as radio carrier.

## meshtastic

Meshtastic An open source, off-grid, decentralized, mesh network built to run on affordable, low-power devices.

Communications can be received over long distances, without any infrastructure as long as there are sufficient Meshtastic nodes in an area that can route the message to the destination node. It can operate in remote areas without cell phone coverage

Each device acts as both a transmitter and a receiver, capable of relaying messages from other devices. Self-healing, decentralized network that can cover large areas and overcome obstacles that might block direct communication between two points

Rebroadcast messages they receive, ensuring that every group member, including those at the furthest distance, can receive messages.

Meshtastic devices communicate directly with each other, forming the backbone of the mesh network. Each device has a unique NodeID, which is used to identify the sender and recipient of messages within the network.

Each device can have its own ECC keypair. PKC permits to send confidential direct messages. A general public channel uses a simple known pre-shared key. All direct messages have encrypted payload, clear metadata. Encryption cipher is aes256-ctr.

Direct messages permit confidential messages for ephemeral security values. There is no strong authentication mechanism, no PFS. Roadmap highlights a will to use AEAD algorithm to provide strong authenticated exchanges.

Currently, integrity and authentication relies on PKC.

Node ID can be spoofed, as they rely on hardware serial but opensource coe can be changed to spoof another device identity, sole security relies then on PKC. Scheme remains safe as long as private key is not stolen.

There is no direct link between your identity and the radio device, you are free to remain unidentified or tell your name and location. Also, you can change device details at will, like generating any new nodeid as a burner phone. So all these features mixed can provide very confidential messaging, although anyone can catch the packets over the air.

## meshcore

meshcore is like a light meshtastic protocol, enables multi-hop packet routing for embedded projects using LoRa and other packet radios. Designed for developers who want to create resilient, decentralized communication networks that work without the internet.

Users can flash a pre-built binary using tools like Adafruit ESPTool and interact with the network through a serial console Focus on lightweight multi-hop packet routing for embedded projects. Useful in off-grid, emergency, or tactical situations where traditional communication infrastructure is unavailable

Devices can forward messages across multiple nodes, extending range beyond a single radio’s reach.

More to come :) in 2026.

## reticulum/nomanet

Reticulum is a wonderful opensource project. It can be run over the Internet or over radio such as LoRa. Reticulum is the cryptography-based networking stack for building local and wide-area networks with readily available hardware. Reticulum can continue to operate even in adverse conditions with very high latency and extremely low bandwidth

The vision of Reticulum is to allow anyone to operate their own sovereign communication networks, and to make it cheap and easy to cover vast areas with a myriad of independent, interconnectable and autonomous networks. Reticulum is Unstoppable Networks for The People.

Networks without kill-switches, surveillance, censorship and control. Networks that can freely interoperate, associate and disassociate with each other. Reticulum is Networks for Human Beings.

Reticulum does not use source addresses. No packets transmitted include information about the address, place, machine or person they originated from. There is no central control over the address space in Reticulum. Anyone can allocate as many addresses as they need, when they need them. Reticulum ensures end-to-end connectivity. Newly generated addresses become globally reachable in a matter of seconds to a few minutes. All encryption keys are ephemeral, and communication offers forward secrecy by default.

NomadNet Nomad Network allows you to build private and resilient communications platforms that are in complete control and ownership of the people that use them. No signups, no agreements, no handover of any data, no permissions and gatekeepers.

Nomad Network is build on LXMF and Reticulum, which together provides the cryptographic mesh functionality and peer-to-peer message routing that Nomad Network relies on. This foundation also makes it possible to use the program over a very wide variety of communication mediums, from packet radio to fiber optics.

Definitely a must to follow, while still considered beta, it does work very well! 😄

Both projects deserve their own site section actually. Reticulum permits so much more, mixing high speed networks and high latency networks.

Both meshtastic and reticulum open door to so wide areas, not only messaging, but telemetry, sensors report, any kind of interaction, open to you, and, in reticulum case, highly confidential.

Reticulum might probably be the solid constructive solution to build and develop a communication network for people by the people. It can fix all the issues of the broken Internet of today. Reticulum design is specially interesting and valuable in a world of major climate change, social re-organisation, pressure on resources, pressure on stable infrastructures, pressure on freedom.

# 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”

Reticulum as new democratic and privacy-aware by design network

jma@mbuf.net (jma) — Sun, 20 Apr 2025 00:00:00 Z

As a hamradio OM (HB9ERY), specially focused on SDR, embedded devices, electronics, unix, linux, communications security, I found the project Reticulum.

If, like me, you are those that find the Internet broken, bloated, heavyweight, cosmetic oriented instead of contents, insecure, surveillance issues like still unsolved metadata protection censor-weak, user-tracking, ads, unrequested contents.

Well, reticulum is a full network stack, designed from the start to solve all those critical issues. It does not require any infrastructure, but can dynamically take advantage of it. There is no authority, no user account, no gatekeeper to connect, deny, blacklist. Anyone that can physically interface, can join the network, anywhere.

Encryption, authentication, privacy, are building blocks of the stack, no leaking source.

Protocol stack designed to be able to run on specially high latency networks as well as optical fiber links. Reticulum is not meant to interface with ip, such as Tor network would provide with exit nodes.

Reticulum uses mesh networking, specially radio LoRa communications.

You are free to build private networks, route edges to integrate larger, connect with anyone…etc.. it is up to to you to decide. This is a real game change. This means that you can build small local private network, family, friends, school, community based, whatever you want. And you decide if you integrate or set interface nodes that connect to bigger or other networks. There are no enforce rules. You design your networks as you need them, no more.

Radio devices can be custom built, hardware purchased, software flashed, customized as it is fully opensource project. It runs on cheap hardware, and can intercnnect with mix of different interfaces (wifi local to AP, bluetooth, ethernet, tnc packet HF radio).

What I really enjoy as values carried by the project, this is not anymore a paradigm focused for rich cities with fully modern, all comfort. A core design is to be able to provide communications with high latency network conditions, or intermittent presence.

This means that the same stack will adapt whatever the conditions are met in real situations. That kind of network is also an incentive about non-addictive or non-permanent links. There is no reason to get notified for any stupid publication.

You’ll get messages when you connect. That’s it, enjoy your time at something else in between. Right, this is a fully different paradigm else as anxiety of being able to catch any news as they get published. Reminds me of non-addictive usage of the social network secure scuttlebutt. SSB si very interesting as it models after social habits, not the other way around.

Reticulum network is great for not relying on governance. Shaping as the groups and communities evolve. That kind of dynamic structure will be best fit to adjust people needs, not more, not less. Delegating, moderation, blacklisting, to the user, rather than a group of people is more efficient, considering that Reticulum won’t encourage massive vertical popularity as it’s a distributed network designed for privacy first, no tracking, no surveillance.

The full stack integrating powerful hardware abstraction layer is the correct response for wide integration and mix of carriers. Internet is critically broken because security and privacy where not seriously considered at early days. This network stack takes care to correct all these issues at the network layer directly.

Internet will not be a serious place for privacy, unless using overlay networks such as Tor, I2P, Metadata protection involves core network layer, and considering how hard ipv6 adoption is, Internet for privacy won’t happen anytime soon.

Relying on tcpip as one of possible interface for Reticulum network is awesome, Internet is resilient, nightmare for privacy, but resilience is achieved goal.

The other aspect that Reticulum really offers, by design, power to the users, actors of the network. ISP tend to enforce the user as just a limited customer of a commercial service. With Reticilun, any user is actor of the network, valuable as others. This is probably the best part. It encourages people to be active, actors of their communications.

Reticulum may also forecast crisis with ongoing climate change, incoming oil resource ROI issue. Developing such a distributed network with small low enery devices, solar panels, even on cheap HF devices, recycled wifi, etc.. it might be a required feature of the future to keep communications possible and safe. This network relying on people, not on pubic services or private companies.

The project is not yet fully mature to blindly use it in production, however we can already gain experience with it, contribute to the project. With time, Reticulum can become the mesh democratic project based on privacy by besign.

Stay tuned, more to come deeper with mesh radio project in 2025.

Zoom E2EE

jma@mbuf.net (jma) — Sun, 04 Apr 2021 00:00:00 Z

End-to-end encryption (E2EE) means that data is encrypted between the different endpoints. No intermediary party can decrypt it and thus, private communication is achieved.

After a long long list of security failures, bad programming, poor design choices. Zoom made lots of efforts to fix several serious issues and recently brought finally the E2EE feature.

General meeting uses a meeting key to protect communication transit with aes-256-gcm. The key is distributed, by Zoom servers, to each joining participiant. It uses a KDF (HMAC) including cleartext stream id.

MMR, multimedia routers, relay and multiplex streams without any packet decryption. These are part of Zoom cloud infrastructure. However, any feature that does not natively permit the Zoom protocol, use a Zoom connector, to proxy the streams. These proxy act as an endpoint and decrypt/encrypt all their communication with the endpoint application, such as SIP, PSTN, H323.

Recent development provides (from zoom communication) E2EE with zoom native clients. There are mandatory disabled features to be able to use such security level:

Join before host
Cloud recording
Live streaming
Live transcription
Breakout Rooms
Polling

Free user accounts can use this security feature. They are required to have a valid billing option associated. Phone verification is mandatory.

The E2EE feature is defined as an option in the account settings and group management (Settings->Meeting->Security). Participants will have to verify a security code to ensure they match the expected one.

Better identity management and E2EE SSO integration are part of Phase 2, which is tentatively roadmapped for 2021. Thanks to the support of solid cryptographers, Zoom security features are improving over time.

Zoom’s E2EE meetings support a maximum of 200 participants.

Zoom finally provides a correct level of security. However, don’t forget that they first started to lie about their security. And they really changed because of public pressure, not because of proactive security. Anyway, in the end, it worked and results are there. However, as we don’t have access to the source code, many aspects rely on what can be communicated. Hopefully further independant audits will continue and let users have a more appropriate trust with Zoom.

Please, refer to the EFF guide for good security practice with Zoom application usage.

The Paderborn university provides good instructions on when and how to use Zoom. As they advise, self-hosting a Jitsi instance, provides much better control and confidentiality. Jitsi is free/libre software and does not require at all a user account registration. BTW, Jitsi has an ongoing work on E2EE and it currently works, but not tagged yet production ready.

Traçage de contacts par ordiphone

jma@mbuf.net (jma) — Sat, 25 Apr 2020 00:00:00 Z

Après avoir analysé différents protcoles proposés pour une apllication mobile, qui permet de consolider les données au bénéfice exclusif des épidémiologistes et de prévention de chaîne de risque, pour les utilisateurs de cette application, je tiens à résumer ici celui qui me semble le plus strictement construit dans l’intérêt commun de la santé publique et de la vie privée de ses utilisateurs.

Je ne présenterai pas les autres qui sont certes intéressants mais, à mon sens, n’offrent pas les mêmes garanties, en cherchant le meilleur équilibre, tel que le décrit le DP-3T.

Le protocole PACT écrit par le MIT est très simillaire au DP-3T, certains détails techniques diffèrent mais il ne présente pas de différence majeure ou de propriété nécessaire manquante.

Une première partie résume le fonctionnement du DP-3T en décrivant les avantages et risques pris en compte dans son fonctionnement. Une deuxième partie vient compléter le raisonnement en émettant toutes les réserves à inclure dans sa réflexion.

Aucune solution idéale n’existe. Il ne s’agit que de nuances pour travailler à placer le curseur de son opinion favorable ou défavorable, pouvoir déterminer les choix les plus efficaces et constructifs en tenant compte de l’ensemble de la problèmatique au sens large.

## DP-3T

Ce protocole est construit dans le cadre d’un projet mené par l’EPFL et l’ETHZ en Suisse. Plusieurs acteurs de pays d’Europe s’y sont joints. Initialiement participant à l’initative européenne PEPP-PT, qui inclus plusieurs projets, ils s’en sont détachés pour se consacrer intégralment au DP-3T.

EphID : identifiants éphémères. Ils ont une durée de vite courte (en minutes) pour éviter tout traçace d’un identifiant. Ceci permet de ne pas reconnaître le même code deux fois, passé ce délai, ou s’il se retrouve plus tard, ne sera pas émis du même téléphone, donc non rattachable.

Il s’agit de pseudonymat. Ce sont des codes qui ne permettent pas de reconnaître l’utilisateur, cependant certaines propriété, que nous verrons plus loin, permettent de décrire un comportement propre à l’utilisateur, et donc de l’identifier de façon isolée, sans avoir besoin de son nom.

L’utilisateur installe l’application sur son tếléphone. Pas d’inscription en ligne, pas de renseignement de nom, email, ou numéro de téléphone.

A l’activation du module bluetooth, l’application émet ses EphID, et enregistre localement (exclusivement) les EphID qu’elle rencontre dans le rayonnement proche bluetooth.

Ceci permet de mesurer la distance du téléphone émetteur proche ainsi que sa durée de contact. Avec l’EphID, ce sont les seules données qui sont enregistrées, estampillées par une date : jour-mois-année, sans précision de l’heure et de la date.

L’imprécision de la date suffit à son caractère utile pour déterminer éventuelle période contagieuse et protège contre des techniques d’analyse pour identifier des utilisateurs ou de falsification de données.

Quand l’utilisateur est diagnostiqué/testé positif de la pathologie, muni d’un code de validation, activé par les autorités sanitaires (sous secret médical), il peut se signaler infecté en indiquant la date estimée, selon le personnel médical, du premier jour de contagion.

A noter qu’aucune donnée de géolocalisation n’est enregistrée, ni communiquée, quelle que soit la situation. La conception du protocole élimine volontairement toute donnée non requise à minimat et toute fonction qui permettrait de déterminer un comportement de l’utilisateur. Responsabilité est donnée à l’utilisateur d’adopter un comportement adéquat, ce n’est pas à l’application de le faire.

Un serveur central, ou plusieurs, gèrent la communication des informations des codes, validés par son utilisateur comme infectés, à destination les différents téléphones. Une gestion interopérable entre plusieurs pays est incluse.

Ce serveur ne repose pas sur la confiance : se protéger de tout abus ou vol de données. Il ne fait que recevoir de façon sécurisée les codes et les communique aux différents téléphones, soit à a demande, soit par mise à jour de données vers l’application mobile.

Un éventuel voleur, ou abus des administrateurs du serveur, ne permet pas d’identifier les utilisateurs, ni de déterminer qui est infecfé, ni de construire un graphe social des interactions. Son unique rôle est la communication des mises à jour à tous les utilisateurs, sans distiction.

Lorsque les utilisateurs reçoivent la mise à jour de la liste des codes des personnes infectées, l’application analyse ces codes avec ceux localement enregistrés. La comparaison se fait exclusivement localement et n’est jamais communiqué à qui que ce soit.

Si il y a eu mise en contact de façon risquée, selon un algorithme qui détermine des critères de temps/distance d’exposition, l’utilisateur en est informé. Il est alors seulement informé qu’il s’est trouvé à risque. Il ne sait pas qui a été infecté.

En principe, dès le diagnostic ou dépistage positif, la personne doit s’isoler pour la durée nécessaire comme l’usage actuel.

Il n’y a pas de système de traçage des personnes infectées. Il s’agit seulement de soutenir les épidémiologisites pour que leur modèle soit le plus efficace possible, ce qui mènera à avoir des décisions plus utiles. Il s’agit enfin de favoriser le ralentissement de la propagation tout en effectuant une sortie de confinement mesurée.

Dès lors que l’utilisateur s’est déclaré infecté, son code change, sans lien possible avec celui qu’il a communiqué en se déclarant contiagieux sur une période donnée.

La concept de ce protocole mise sur une sécurité claire, simplifiant au possible sa construction, utilisant des techniques de sécurité éprouvées et des plus actuelles.

Il proposent une variante qui automatise certaines fonctions, sur accord explicite seulement, afin de garantir une meilleure confidentialité dans le comportement de communication : résister aux attaques d’analyse de traffic avec le serveur central.

Une des conceptions décrite en terme d’expérience utilisateur est de ne rien faire dans le dos de l’utilisateur, de lui indiquer chaque action, et de n’exécuter qu’avec l’approbation de l’utilisateur. Tout ceci sans la moindre relation avec une autorité qui pourrait surveiller les actions de l’utilisateur dans l’application.

Ce développment logiciel est sous forme publique, consultable librement en ligne, sur la plateforme de développment github.

Le code source est donc vérifiable, de plus, il sera possible pour les informaticiens tiers de générer les applications à partir du code et de vérifier que les applications mobiles sont bien celles annoncées avec le code source. Tout ceci est donc vérifiable sans confiance.

S’il était découvert un code malveillant, introduit dans le code du programme, volontairement ou non, non seulement cela se verrait rapidement, mais ensuite plus personne ne l’utiliserait. Ce rapport sans confiance avec verifiabilité apporte donc une valeur de transparence qui est requise.

### Dans la partie risques:

Il y a la partie bluetooth en elle-même. Une communication radio souffre des aspects phyisques dont elle ne peut se défaire:

l’exposition radio, on ne contrôle pas qui perçoit ce raynonnement.
Il est facile, bien qu’illégal, de brouiller un signal radio.
Les mesures bluetooth varient avec les propriétés électroniques des équipements radios (selon constructeur, modèle).
La mesure bluetooth ne tient pas compte des objets ne faisant pas écran au rayonnement radio mais qui font écran au virus (vitre, cloison, rideau, ..).
Une antenne directionnelle adaptée permet de capter signal bluetooth sur de grandes distances (écoute passive).

Toutes ces caractéristiques sont propres à le technologie radio, bluetooth dans ce cas, et font partie des raisons pourquoi il n’est pas recommandé d’activer le bluetooth de façon prolongée.

Comme localement l’utiisateur dispose de son historique de contacts EphID, lorsqu’il reçoit des mises à jour de codes qualifés d’infectés, il pourrait déterminer si ses contacts les plus fréquents le sont. Si ses contacts les plus fréquents sont son cercle très proche comme familial ou amis, collègues très proches, on peut considérer que même si cela est possible, socialement, ils seront sans doute au courant, donc ceci n’est pas un risque majeur.

Les téléphones émettent ces EphId générés à partir d’une clé, qui elle aussi change régulièrement. Les EphID sont émis à partir d’une liste générée, mais de façon aléatoire, afin de dissimuler la chronologie, pas de séquence précise calculable pas un attaquant.

Les risque d’exposition existent cependant. Utiliser plusieurs téléphones ou équipements installant l’application de façon abusive pourraient corréler des émissions et tenter d’identifier des sources d’émissions avec des analyses de caméra ou couplées à d’autres techniques.

Sur des acteurs majeurs de surveillance, il est déjà très facile de géolocaliser les personnes, les enregistrements historiques existent déjà chez les opératueurs, et je n’évoque pas ici le traçage des géants comme Google, etc… qui le font déjà en toute impunité et manifeste violation GDPR, particulièrement en consentment non-libre.

De multiples erreurs peuvent survenir, et il faudra en tenir compte. L’imprécision des distances, les éventels faux-positifs conséquents peuvent mener des personnes à s’isoler alors qu’elles n’ont pas été à risque. En cas de faux négatifs, cela peut mener des utilisateurs à se sentir protégés alors qu’ils ont été en contact avec des personnes infectées, facilitant potentiellement une contagion à des tiers.

Favoriser l’usage de bluetooth en masse peut donner lieu à des multiplications d’attaques sur cette technologie relarivement fragile, ainsi que des techniques d’identification par signature des metadonnées émises ou comportement radio propre à l’appareil.

Déterminer si ses contacts les plus fréquents sont infectés n’est pas grave si ce sont des très proches qui auront socialement informés les leurs. Cependant, un contact très fréquent n’est pas forcément un intime. Si l’on a peu d’interactions, un contact régulier avec un commerçant par exemple, peu devenir un contact fréquent identifiable. Ces effets de bords arriveront.

Ce genre d’application peut favoriser une culture de la suspiçion et de la volonté de dénoncer ceux qui sont infectés. De tels comportements par différents prémisses se sont déjà signalés en cette période.

On peut volontairement déployer des téléphones qui ne restent qu’en contact avec des cibles voulues, on pourra alors très facilement savoir quand ils ont été en période contagieuse et infectés. Activer un téléphone seulement en la présence de victimes potentielles permet le même résultat. Il y a rupture de la confidentialité.

L’efficacité d’un tel déploiement repose notamment sur un dépistage général. Est-ce que cette caractéristique sera garantie? Sur quelle durée?

Cela pourrait mener à un sentiment illusoire de sécurité des utilisateurs, qui peuvent ainsi réduire l’attention aux gestes barrières, se sentant en confiance de l’absence de signalement par l’application.

En aucun cas, le refus d’utiliser l’application ne doit discriminer les déplacements ou l’accès à des services. En outre, il y a un risque de pression sociale nuisible au consentement libre.

En terme de droit, il faut être très vigilant et se discipliner à un principe de parcimonie, car dans la pratique, les lois d’exception s’installent dans la durée au détriment du droit commun, affaiblissant petit à petit l’Etat de droit. A ce titre, il y a déjà des utilisations exceptionnelles de drones de surveillance, d’usage des caméra de surveillance, ainsi qu’une envie de favoriser l’installation massive de la reconnaissance faciale..

Il y a risque ici de banalisation et d’acceptation de techniques de surveillance de la population. Ce système mis en place ne doit en aucun cas servir à un autre but que celui explicitement décrit.

Actuellement, environ 77% de la population dispose d’un ordiphone, il faut aussi en tenir compte. Par comparaison, à Singapour, lieu qui a été très efficace pour stopper la propagation critique de l’épidémie, seulement 16% de la population a utilise une application de traçage des utilisateurs.

Il faut réflechir sans idéologie à la place d’un tel investissement au détriment d’une consolidation des ressources en faveur de dépistages et matériel de protection.

Enfin, le solutionisme technologique, cette pensée magique, croyance aveugle que la technologie peut pallier à chaque situation, est un leurre. Il faut une réflexion de fond, qui prenne en compte la problématique générale intégrant les sujets sanitaires, sociaux, et techniques. Une solution technique ne saurait cacher ou résoudre le manque d’investissement dans la santé publique.

Références