ARCHITECTURE

Architecture technique

Client multiplateforme Flutter, backend Firebase et Signal Protocol E2EE avec cryptographie post-quantique.

02 / 06

Mesh Network · BLE Offline

Hors réseau ? Toujours connecté.

Le P2P BLE hors-ligne maintient vos conversations E2EE actives même quand Internet et les réseaux mobiles tombent. Un vrai recours en cas de catastrophe, de censure ou d'infrastructure saturée.

NO INTERNET. NO PROBLEM.

📡 PAS D'INTERNET

🔋 BLE ACTIVE

🔒 E2EE

VOUS

Stack technologique

Layer	Technology
Client	Flutter 3.44 + Dart
State Management	Riverpod 3.0 (AsyncNotifier / Generator)
Backend	Firebase (Firestore / Auth / Storage / FCM) + GCP
PreKey Server	Elixir/Phoenix (Cloud Run, europe-west1) — Firestore transaction-based atomic PreKey consumption
Mesh Network	Bridgefy BLE SDK
Cryptography	Arc Protocol (libsignal-client Rust FFI): PQXDH (X25519 + ML-KEM-1024), XEdDSA signatures, Sender Key (Group)
Local Database	Hive (NoSQL, type-safe)
Key Storage	FlutterSecureStorage (Keychain / Keystore / Web Crypto API)
Image Cache	CachedNetworkImage

PreKey Server — Elixir/Phoenix

Dedicated server for atomic PreKey consumption during Signal Protocol session establishment. Built with Elixir/Phoenix on Cloud Run (europe-west1), optimized for EMEA users.

Elixir 1.19

Erlang/OTP 28 · BEAM VM

Phoenix 1.8

API only · Bandit HTTP

Cloud Run

europe-west1 · EMEA

Firestore

REST API · eur3 multi-region

Rust (libsignal)

PQXDH · XEdDSA · Sender Key

Flutter 3.44

iOS · Android · macOS · Web

Pipeline de chiffrement E2EE

Phase 1: PQXDH (Post-Quantum Extended Diffie-Hellman)
  IKa(X25519) × SPKb(X25519) → DH1
  EKa(X25519) × IKb(X25519) → DH2
  EKa(X25519) × SPKb(X25519) → DH3
  EKa(X25519) × OPKb(X25519) → DH4
  EKa(ML-KEM-1024) → PQ encapsulate → ss_pq
  HKDF(DH1 ‖ DH2 ‖ DH3 ‖ DH4 ‖ ss_pq) → Root Key

Phase 2: Double Ratchet
  Root Key → Chain Key → Message Key (per message)
  DH Ratchet: New X25519 key pair per exchange
  Symmetric Ratchet: KDF chain for sequential messages

Phase 3: AES-256-GCM
  Message Key → AES-256-GCM encrypt(plaintext)
  12-byte random IV per message
  Authentication tag for integrity

Phase 4: AEGIS (XEdDSA Signature via libsignal)
  Sign(senderId ‖ timestamp ‖ content) → signature
  XEdDSA: Identity Key (X25519) doubles as signing key

Phase 5: Sealed Sender
  Generate ephemeral X25519 key pair
  ECDH with recipient → HKDF-SHA256 → AES key
  Encrypt(senderId ‖ ciphertext) → sealed message

Group Encryption (ECIES + AES-256-GCM)

Key Distribution (per member):
  GroupKey(AES-256) → ECIES encrypt(member.publicKey) → Firestore

Message Encryption:
  AES-256-GCM(groupKey, plaintext, AAD = senderId ‖ groupId ‖ timestamp)

Key Retrieval (fast path):
  Memory Cache → SecureStorage → Firestore ECIES decrypt

O(N) key distribution, O(1) message encryption. Each member receives the group key encrypted with their public key via ECIES. Messages are encrypted once with AES-256-GCM using Additional Authenticated Data (AAD) for integrity.

E2EE Protection Across All App States

Messages are decrypted immediately upon receipt and cached in persistent storage, ensuring E2EE protection regardless of app state — foreground, background, or terminated.

App State	1:1 Chat	Group Chat	Mechanism
Chat screen active	✅	✅	StreamBuilder decrypt → LRU + SentMessageCache
Foreground (other screen)	✅	✅	FCM pre-decrypt → SentMessageCache
Pre-session reset	✅	N/A	Pre-decrypt before ratchet reset
Background / Terminated	✅	✅	SharedPreferences queue → bulk decrypt on resume

Architecture multi-appareils

Device 1 (e.g., iPhone)

[X25519] Identity Key
[Ed25519] Signing Key
[X25519] Signed PreKey
[X25519] OTPKs x 100
[ML-KEM-1024] PQ PreKey
Independent Double Ratchet sessions

Device 2 (e.g., macOS)

[X25519] Identity Key
[Ed25519] Signing Key
[X25519] Signed PreKey
[X25519] OTPKs x 100
[ML-KEM-1024] PQ PreKey
Independent Double Ratchet sessions

Device List Signing: Ed25519 signature on deviceListV1:{sorted_ids}:{timestamp} for tamper detection. No session sharing between devices.

Mesh Network (BLE Offline E2EE)

[Device A] ──BLE── [Device B] ──BLE── [Device C] ──Multi-hop── [Device D]
   100m radius         100m radius         100m radius

Parameter	Value
Direct P2P	BLE 100m radius
Multi-hop	N relay x 100m
Protocol	Bridgefy SDK
Encryption	X3DH + Double Ratchet + AES-256-GCM
Offline	Store & Forward queue
Use Case	Disaster, winery fields, remote areas

architecture.ondeviceTitle

architecture.ondeviceDesc

Rosetta

OfflineBientôt disponible

architecture.rosettaDesc

Model: Gemma 4 (TranslateGemma)
Languages: 55
Processing: 100% on-device
Data leakage: zero

Pet Companion

OfflineBientôt disponible

architecture.petDesc

Model: Gemma 4 (4B parameters)
Storage: Hive (TypeID 96-97)
Processing: 100% on-device
Server communication: none

SUM

OfflineBientôt disponible

Téléversez PDF, présentations et documents pour des résumés alimentés par l'IA, des analyses approfondies et des perspectives — entièrement traités sur l'appareil. Plus des résumés IA instantanés d'URL via Gemini. Fonctionnalité du plan Intelligence.

Model: Gemma 4 (planned)
Input: PDF / DOCX / PPTX
Processing: 100% on-device
Plan: Intelligence

4-Pillar Vision:
  🛡️ DefenseTech     ─── Online: E2EE (PQXDH + ML-KEM-1024) + AEGIS + Sealed Sender
  📡 DisasterTech    ─── Offline: BLE Mesh + additional encryption layers
  🌍 Language Bridge ─── Offline: Gemma 4 (TranslateGemma) on-device translation
  🐾 AI Pet         ─── Offline: Gemma 4 companion, zero server communication

Model Pipeline:
  Firestore config → Download check → Ad gate → Model download → Hive cache
  User input → On-device inference (Gemma 4) → Result → No data leaves device

Cycle de vie des clés & rotation

Key Type	Rotation	Purpose
Identity Key (X25519)	Account lifetime	Core identity
Signing Key (Ed25519)	90 days + grace period	AEGIS message signatures
Signed PreKey (X25519)	7-30 days	X3DH handshake
One-Time PreKeys (X25519)	Single use	Forward secrecy per session
PQ PreKey (ML-KEM-1024)	Account lifetime	Post-quantum key encapsulation
Double Ratchet Keys	Per message exchange	Per-message forward secrecy