ZiaCrypte

Architecture

┌─────────────────────────────┐        ┌──────────────────────────┐
│  App Flutter (Dart)         │        │  Backend (Node.js/TS)    │
│  interface · navigation     │        │  comptes · présence      │
│  aucune cryptographie       │        │  relais de blobs chiffrés│
└──────────────┬──────────────┘        └────────────┬─────────────┘
               │ dart:ffi                           │ WSS / HTTPS
┌──────────────┴──────────────┐                     │
│  Moteur crypto (C++)        │                     │
│  libsodium · liboqs · X3DH  │◄─── blobs ──────────┘
│  Double Ratchet · key store │     chiffrés uniquement
└─────────────────────────────┘

Ce que chaque module ne fait jamais

• crypto-engine (C++)clés, PQXDH, Double Ratchet, sender keys, sealed sender, stockage sécurisé
• app (Flutter)interface, navigation, réseau, préférences locales. Jamais de cryptographie.
• server (Node.js)comptes, authentification, relais de blobs, présence, notifications. Ne déchiffre rien.

Accord de clés hybride

Sur l'appareil

• État de session, identité et historique local chiffrés au repos, sous une clé maîtresse par appareil gardée par le trousseau du système
• Secret Service, Keychain, DPAPI ou Android Keystorece dernier via JNI, faute d'API C côté NDK
• Tampons de secrets protégés, verrouillés en mémoire et systématiquement effacés
• Verrouillage applicatif optionnel, blocage des captures d'écran sur Android, sauvegarde exportable chiffrée par phrase de passe

Face au serveur

• Épinglage d'identité avec numéros de sécurité : une substitution de clé est signalée, et une alerte non résolue retire le badge « vérifié » au lieu de rassurer sur la mauvaise clé
• Présence sur consentement, visible seulement des personnes avec qui une conversation existe déjàet aucun horodatage de dernière connexion, délibérément
• Paquets de mise à jour signés, vérifiés par l'application contre une clé publique intégrée au binaire

Ce qui est vérifié

• Suite de conformité, tests de persistance, de migration et de sauvegarde, plus des fuzzers
• Presets sanitizers (ASan, UBSan) et libFuzzer sur le moteur
• Les tests exercent le vrai trousseau système, pas un bouchon : la session keyring est requise
• Compilations croisées reproductibles vers Windows et Android, liées statiquementla version Windows se vérifie depuis Linux sous Wine
• Tests d'intégration bout en bout avec deux vrais clients contre un serveur dédié

Où ça en est

L'accord de clés post-quantique est implémenté et testé dans le moteur, mais pas encore actif sur le réseau : le serveur ne relaie pas la clé d'encapsulation, les sessions négocient donc encore du X3DH classique. Ce repli est volontaire et testé — c'est lui qui garde les clients déjà installés fonctionnels pendant la migration. Restent la transparence des clés et les appels chiffrés.