op4

op4 — Messagerie sécurisée en terminal

Op4 est une application de messagerie chiffrée fonctionnant en terminal, écrite en Rust. Elle propose des messages privés chiffrés de bout en bout avec une cryptographie post-quantique, acheminés entièrement via le réseau Tor, de sorte que ni le contenu de vos messages ni votre adresse IP ne soient exposés à quiconque — pas même à la personne à qui vous parlez.

Table des matières

1. Ce que fait op4
2. Installation
3. Connexion à un autre utilisateur
4. Modèle de sécurité
5. Vue d'ensemble de l'architecture
6. Structure du projet
7. Statut actuel

Ce que fait op4

op4 permet à deux personnes d'échanger des messages privés sans qu'aucune des deux ne révèle son adresse IP ou sa véritable identité. Chaque message est :

• Chiffré de bout en bout grâce à un protocole Double Ratchet — la même conception fondamentale utilisée par Signal.
• Renforcé contre la menace quantique — la couche d'échange de clés combine le X25519 classique avec ML-KEM-768 (KEM à base de treillis normalisé par le NIST), de sorte qu'un futur ordinateur quantique ne pourra pas déchiffrer rétroactivement le trafic enregistré.
• Anonymisé — tout le trafic transite par des services cachés Tor (adresses .onion). Votre adresse IP n'est jamais exposée à votre contact ni à aucun observateur réseau.
• Stocké localement — il n'y a pas de serveur. Vos messages et contacts résident dans un fichier de coffre chiffré sur votre propre machine, et nulle part ailleurs.

op4 s'exécute entièrement dans le terminal. Il n'a ni interface graphique, ni composant navigateur, ni compte cloud. Le seul processus externe qu'il contacte est le démon Tor tournant sur votre propre machine.

Installation

Toutes les options de téléchargement — AppImage, archive source, clone et compilation, et installateur automatisé — sont documentées dans le Guide de téléchargement et d'installation. La dernière version est disponible sur la page des versions.

Debian / Ubuntu (automatisé)

Sur Debian et Ubuntu, install/setup.sh gère tout en une seule commande : chaîne d'outils Rust, dépendances de compilation, Tor, configuration du port de contrôle, compilation du binaire, utilisateur système, répertoire de données et profil AppArmor.

git clone https://github.com/Opfour/op4.git
cd op4
sudo bash install/setup.sh

Après la fin du script, vous devez vous déconnecter et vous reconnecter avant de lancer op4. L'installateur ajoute votre utilisateur au groupe debian-tor afin qu'il puisse lire le fichier cookie de Tor. Linux n'applique pas les changements de groupe aux sessions déjà ouvertes — une nouvelle connexion est requise.

Ignorer cette étape entraînera un échec au démarrage d'op4 avec : Permission denied reading /run/tor/control.authcookie

Ensuite, vérifiez que le hash source affiché par le script correspond au hash publié pour votre version avant de faire confiance au binaire.

Vérification du hash de la source

Lorsqu'op4 démarre, il affiche un hash source couvrant tous les fichiers source Rust, Cargo.toml, Cargo.lock et build.rs. Comparez-le avec la valeur ci-dessous pour la version que vous avez installée.

Vous pouvez également le vérifier sans lancer l'application complète :

op4 --print-hash

Si le hash ne correspond pas, n'utilisez pas le binaire — il a été soit compilé à partir d'un commit différent, soit falsifié.

Fedora / Arch / autres distributions (manuel)

Installez d'abord les dépendances, puis exécutez le script :

Chaîne d'outils Rust (épinglée à la version 1.89.0 via rust-toolchain.toml) :

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source "$HOME/.cargo/env"

Tor et dépendances de compilation :

# Fedora
sudo dnf install tor gcc pkg-config openssl-devel

# Arch
sudo pacman -S tor base-devel pkg-config openssl

Configurer le port de contrôle Tor — ajoutez dans /etc/tor/torrc :

ControlPort 9051
CookieAuthentication 1

sudo systemctl restart tor

Ajoutez votre utilisateur au groupe Tor :

sudo usermod -aG tor $USER        # Fedora / Arch

Vous devez vous déconnecter et vous reconnecter après cette étape. Les changements d'appartenance à un groupe ne sont pas appliqués aux sessions actives. Jusqu'à ce que vous le fassiez, op4 échouera avec Permission denied reading /run/tor/control.authcookie.

Pour appliquer le changement sans déconnexion complète, exécutez :

root@kitploit:~

newgrp tor

Compilation et installation :

git clone https://github.com/Opfour/op4.git
cd op4
cargo build --release
sudo bash install/setup.sh

Exécution

op4
# ou, sans installation système :
./target/release/op4

Au premier lancement, op4 vous guidera pour définir une phrase de passe normale et une phrase de passe de contrainte, puis générera vos clés d'identité. Votre coffre est stocké dans ~/.local/share/op4/vault.op4.

Plateformes prises en charge

Noyau minimum : 4.15 (5.4+ recommandé). Architecture : x86-64 (aarch64 devrait fonctionner mais n'est pas testé).

Connexion à un autre utilisateur

Deux personnes ont besoin chacune d'op4 installé, de Tor en cours d'exécution et de leur coffre déverrouillé. L'échange est asymétrique : une personne envoie d'abord son code de contact, l'autre l'ajoute, puis envoie son premier message, qui arrive comme une demande en attente que la première personne doit accepter.

Étape 1 — Premier lancement

Au premier lancement, op4 demande une phrase de passe normale et une phrase de passe de contrainte, puis génère vos clés d'identité. Cela ne se produit qu'une seule fois. Votre coffre est stocké dans ~/.local/share/op4/vault.op4.

$ op4

Étape 2 — Obtenir votre code de contact

Votre code de contact contient l'intégralité de votre trousseau de clés publiques et votre adresse .onion. L'autre personne en a besoin pour vous joindre.

1. Accédez à l'onglet Contacts (appuyez sur 2 ou →)
2. Appuyez sur e pour exporter votre code de contact
3. Votre code s'affiche à l'écran — c'est une longue chaîne Base58 commençant par op4:
4. Copiez-le et envoyez-le à l'autre personne hors bande (Signal, email, en personne, etc.)

Votre code de contact n'est pas secret. Il peut être partagé publiquement sans risque. Il ne contient que vos clés publiques et votre adresse onion — aucun matériel privé.

Étape 3 — Ajouter l'autre personne comme contact

Une fois que vous avez son code de contact :

1. Dans l'onglet Contacts, appuyez sur a pour ajouter un contact
2. Collez son code op4: et appuyez sur Entrée
3. Donnez-lui un nom et appuyez sur Entrée

Étape 4 — Envoyer votre premier message

1. Sélectionnez le contact dans votre liste de contacts (utilisez ↑/↓, puis Entrée)
2. Passez à l'onglet Messages (appuyez sur 3 ou →)
3. Tapez votre message et appuyez sur Entrée

Ce premier message initie la poignée de main chiffrée et est délivré à leur adresse .onion via Tor. Ils le verront comme une demande de contact en attente.

Étape 5 — Accepter une demande entrante

Quand quelqu'un vous envoie un premier message, un badge apparaît sur l'onglet Contacts indiquant le nombre de demandes en attente.

1. Allez dans l'onglet Contacts (appuyez sur 2)
2. Appuyez sur p pour consulter les demandes en attente
3. Vous verrez l'empreinte de l'expéditeur et son premier message
4. Tapez un nom pour ce contact et appuyez sur Entrée pour accepter (appuyez sur Échap pour refuser et supprimer)

Une fois acceptée, le Double Ratchet est initialisé et la conversation est immédiatement disponible dans l'onglet Messages.

Étape 6 — Vérifier l'empreinte (recommandé)

Avant de faire confiance à un contact, confirmez que son empreinte correspond à ce qu'il affiche sur son propre écran. Cela empêche une attaque de l'homme du milieu lors de l'échange initial de contact.

1. Dans l'onglet Contacts, sélectionnez le contact
2. Le panneau d'empreinte à droite montre une chaîne hexadécimale en 16 groupes, par ex. A3F2:91BC:…
3. Demandez à l'autre personne de lire son empreinte pour votre entrée — elle doit correspondre exactement
4. La vérification peut être effectuée par appel vocal, en personne, ou tout autre canal où vous pouvez confirmer son identité

Référence de navigation

Rotation des clés

Si vous pensez que vos clés d'identité ont pu être compromises :

1. Allez dans l'onglet Paramètres (appuyez sur 4 ou naviguez vers la droite)
2. Appuyez sur r pour faire la rotation des clés
3. op4 génère une nouvelle paire de clés, signe un certificat de révocation avec votre ancienne clé et le diffuse à tous vos contacts via Tor
4. Votre code de contact change — partagez le nouveau avec vos contacts

Modèle de sécurité

Primitives cryptographiques (toutes issues de l'écosystème RustCrypto)

Double Ratchet

op4 utilise un protocole Double Ratchet (similaire au Signal Protocol) pour la secreté de transmission (forward secrecy). Cela signifie :

• Chaque message est chiffré avec une clé unique dérivée d'une chaîne de ratchet.
• Compromettre une clé de message n'expose aucun autre message.
• Si votre appareil est saisi, les messages passés déjà supprimés ne peuvent pas être déchiffrés même si l'attaquant apprend votre phrase de passe du coffre.

Échange de clés hybride post-quantique

L'étape KEM combine X25519 et ML-KEM-768 comme suit :

shared_secret = HKDF(X25519_ss || MLKEM_ss)

Un attaquant doit casser les deux algorithmes pour compromettre l'échange de clés. Cela protège contre un adversaire quantique (ML-KEM-768) tout en restant sûr contre les attaques classiques si ML-KEM-768 présente une faille inconnue (repli X25519).

Authentification non répudiable

Les messages sont authentifiés avec HMAC-SHA256 en utilisant une clé dérivée de l'état partagé du ratchet. Les deux parties détenant la même clé HMAC, l'une ou l'autre aurait pu produire un MAC donné. C'est la même propriété de non-répudiation utilisée par OTR et Signal : les messages ne peuvent pas être attribués cryptographiquement à un expéditeur spécifique dans le cadre d'une procédure judiciaire.

Coffre et phrase de passe de contrainte

Le fichier de coffre dans ~/.local/share/op4/vault.op4 stocke tous les contacts, conversations et clés d'identité. Il est protégé par deux clés indépendantes dérivées via Argon2id :

• Phrase de passe normale — déverrouille vos véritables contacts et messages.
• Phrase de passe de contrainte — déverrouille une boîte de réception leurre visuellement identique mais vide. Utilisez-la si vous êtes contraint de déverrouiller l'application. De l'extérieur, les deux phrases de passe sont indiscernables.

Anonymat réseau

op4 crée un service caché Tor v3 pour votre boîte de réception. Votre adresse .onion est dérivée de manière déterministe de votre clé d'identité (via HKDF), donc elle est stable entre les redémarrages sans avoir besoin de stocker une clé séparée. Les messages sortants sont envoyés via le proxy SOCKS5 de Tor. Votre véritable adresse IP n'apparaît jamais dans aucun paquet réseau lié à op4.

Le trafic de couverture (messages factices à distribution de Poisson envoyés à soi-même, intervalle moyen de 30 secondes) empêche un observateur réseau de savoir si vous messagiez activement avec quelqu'un en surveillant le volume de trafic.

Renforcement au niveau du système d'exploitation

• mlockall — empêche l'écriture des clés du coffre et du texte clair dans le swap.
• RLIMIT_CORE = 0 — désactive les fichiers core qui pourraient exposer la mémoire.
• PR_SET_DUMPABLE = 0 — empêche les autres processus d'attacher un débogueur.
• seccomp-bpf — installe une liste blanche d'appels système. Tout appel système ne figurant pas dans la liste entraîne la mort immédiate du processus.
• Profil AppArmor (apparmor/op4.profile) — restreint l'accès au système de fichiers au seul répertoire du coffre, aux périphériques terminal et à Tor.

Vue d'ensemble de l'architecture

┌─────────────────────────────────────────────────────────────┐
│                        op4 process                          │
│                                                             │
│  ┌──────────┐   ┌──────────────────┐   ┌────────────────┐  │
│  │   TUI    │   │  Double Ratchet  │   │  Tor Transport │  │
│  │ (ratatui)│──▶│  + Hybrid PQ     │──▶│  nym_client.rs │  │
│  │          │   │  Crypto          │   │                │  │
│  └──────────┘   └──────────────────┘   └───────┬────────┘  │
│                                                │           │
│  ┌──────────────────────────────┐              │           │
│  │  Encrypted Vault             │    SOCKS5 / control port │
│  │  ~/.local/share/op4/vault.op4│              │           │
│  └──────────────────────────────┘              │           │
└────────────────────────────────────────────────┼───────────┘
                                                 │
                                    ┌────────────▼────────────┐
                                    │      Tor daemon         │
                                    │  127.0.0.1:9050 (SOCKS) │
                                    │  127.0.0.1:9051 (ctrl)  │
                                    └────────────┬────────────┘
                                                 │
                                         Tor network
                                                 │
                                    ┌────────────▼────────────┐
                                    │  Peer's .onion address  │
                                    │  (their hidden service) │
                                    └─────────────────────────┘

Structure du projet

op4/
├── src/
│   ├── main.rs                  Point d'entrée, séquence de démarrage
│   ├── error.rs                 Types d'erreur unifiés
│   ├── crypto/
│   │   ├── keys.rs              Paires de clés KEM hybride + signature
│   │   ├── primitives.rs        AEAD, HKDF, HMAC, Argon2id
│   │   ├── ratchet.rs           Implémentation du Double Ratchet
│   │   ├── hmac_auth.rs         Étiquettes d'authentification non répudiable
│   │   └── handshake.rs         Accord de clés initial (style X3DH)
│   ├── network/
│   │   ├── nym_client.rs        Transport par service caché Tor
│   │   └── message.rs           Format du message filaire + padding
│   ├── storage/
│   │   └── vault.rs             Coffre chiffré (Argon2id + AEAD)
│   ├── identity/
│   │   ├── profile.rs           Codes de contact, contacts stockés
│   │   └── revocation.rs        Enregistrements de révocation de clé
│   ├── hardening/
│   │   ├── memory.rs            mlockall, RLIMIT_CORE, dumpable
│   │   └── seccomp.rs           Filtre d'appels système seccomp-bpf
│   └── ui/
│       ├── app.rs               Boucle d'événements TUI et machine d'état
│       ├── contacts.rs          Rendu de l'onglet Contacts
│       ├── conversation.rs      Rendu de l'onglet Messages
│       ├── settings.rs          Rendu de l'onglet Paramètres
│       ├── duress.rs            Rendu de la boîte de réception de contrainte
│       ├── input.rs             Nettoyage des entrées (suppression CSI/OSC)
│       └── passphrase.rs        Invites de phrase de passe sécurisées
├── apparmor/
│   └── op4.profile              Profil MAC AppArmor
├── install/
│   └── setup.sh                 Script d'installation système
├── build.rs                     Embarque le hash source à la compilation
├── deny.toml                    Règles de licence et d'avis pour cargo-deny
├── rust-toolchain.toml          Épingle Rust 1.89.0
└── docs/                        Cette documentation

Statut actuel

Version : 0.2.0-dev (pré-version)

op4 est en développement actif. Les couches suivantes sont complètes et testées :

• Coffre (création, déverrouillage, sauvegarde, mode contrainte)
• Toutes les primitives cryptographiques (12/12 tests unitaires réussis)
• Transport par service caché Tor (connexion, envoi, réception, trafic de couverture)
• Interface utilisateur en terminal (navigation, gestion des contacts, vue des conversations)
• Renforcement du système d'exploitation (mémoire, seccomp, AppArmor)

Toutes les couches sont maintenant reliées de bout en bout :

• Les paires de clés d'identité (X25519+ML-KEM-768, Ed25519+ML-DSA-65) sont générées au premier lancement et stockées chiffrées dans le coffre.
• L'exportation du code de contact produit un véritable PublicKeyBundle codé en Base58 (votre jeu complet de clés publiques + adresse onion).
• L'envoi d'un message effectue une poignée de main complète de type X3DH sur le premier message adressé à un contact, puis un chiffrement Double Ratchet sur les messages suivants, transmis via Tor.
• Les messages entrants sont interrogés depuis le transport Tor dans la boucle d'événements TUI et affichés dans la vue de conversation (modèle expéditeur scellé : la couche de routage ne révèle jamais qui a envoyé le message).

Toutes les limitations connues ont été résolues. L'application est désormais en statut de fonctionnalités complètes pour la version 0.2.0-dev :

• L'authentification non répudiable HMAC est entièrement câblée. Chaque message sortant porte une étiquette HMAC-SHA256 calculée à partir de la clé de ratchet par message sur (conversation_id || message_counter || ciphertext). Les messages entrants sont vérifiés avant d'être acceptés ; les étiquettes remplies de zéros provenant d'anciens pairs sont tolérées pour la rétrocompatibilité.

• L'historique des messages persiste entre les redémarrages. Le journal complet de la conversation est chiffré avec une clé dérivée via HKDF propre à la conversation et stocké dans le champ message_log_ct du coffre. Les messages sont chargés depuis le coffre lorsqu'une conversation est ouverte et réécrits après chaque envoi ou réception.

• Les demandes de contact entrantes provenant de personnes inconnues sont mises en file d'attente plutôt que supprimées. L'onglet Contacts affiche un badge lorsqu'il y a des demandes en attente. Appuyez sur [p] pour les consulter : vous voyez l'empreinte de l'expéditeur et son premier message, tapez un nom et appuyez sur Entrée pour accepter (ou Échap pour refuser). Une fois acceptée, le contact est ajouté, le Double Ratchet est initialisé et le message initial est sauvegardé dans le coffre.

• Le coffre de contrainte est préservé entre les sauvegardes. Le format du fichier de coffre (v2) stocke les longueurs exactes du texte chiffré dans l'en-tête, de sorte que le déchiffrement AEAD opère sur les véritables octets plutôt que sur des sections remplies de zéros. La section chiffrée de contrainte est stockée textuellement à chaque appel save(), ce qui maintient la validité de la phrase de passe de contrainte indéfiniment.

• Clé de bootstrap dédiée au Double Ratchet. Une paire de clés X25519 séparée (identity_ratchet_secret) est générée au premier lancement et incluse dans le code de contact sous le nom . Le ratchet d'Alice est initialisé avec le de Bob plutôt qu'avec sa clé d'identité KEM, séparant ainsi les rôles des clés.