Atlas Associates
ARCHITECTURE

技术架构

Flutter 跨平台客户端、Firebase 后端、以及配备后量子密码学的 Signal Protocol E2EE。

02 / 06
Mesh Network · BLE Offline

脱网了？ 依然在线。

BLE 离线 P2P 让你的 E2EE 对话即使在互联网与移动网络中断时也能持续。这是面向灾害、审查与基础设施过载的真正后备方案。

NO INTERNET. NO PROBLEM.

📡 无互联网
🔋 BLE ACTIVE
🔒 E2EE
你
A
M
K
S

技术栈

LayerTechnology
ClientFlutter 3.44 + Dart
State ManagementRiverpod 3.0 (AsyncNotifier / Generator)
BackendFirebase (Firestore / Auth / Storage / FCM) + GCP
PreKey ServerElixir/Phoenix (Cloud Run, europe-west1) — Firestore transaction-based atomic PreKey consumption
Mesh NetworkBridgefy BLE SDK
CryptographyArc Protocol (libsignal-client Rust FFI): PQXDH (X25519 + ML-KEM-1024), XEdDSA signatures, Sender Key (Group)
Local DatabaseHive (NoSQL, type-safe)
Key StorageFlutterSecureStorage (Keychain / Keystore / Web Crypto API)
Image CacheCachedNetworkImage

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
Elixir 1.19
Erlang/OTP 28 · BEAM VM
Phoenix 1.8
Phoenix 1.8
API only · Bandit HTTP
Cloud Run
Cloud Run
europe-west1 · EMEA
Firestore
Firestore
REST API · eur3 multi-region
Rust (libsignal)
Rust (libsignal)
PQXDH · XEdDSA · Sender Key
Flutter 3.44
Flutter 3.44
iOS · Android · macOS · Web

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 State1:1 ChatGroup ChatMechanism
Chat screen active✅✅StreamBuilder decrypt → LRU + SentMessageCache
Foreground (other screen)✅✅FCM pre-decrypt → SentMessageCache
Pre-session reset✅N/APre-decrypt before ratchet reset
Background / Terminated✅✅SharedPreferences queue → bulk decrypt on resume

多设备架构

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 离线 E2EE）

[Device A] ──BLE── [Device B] ──BLE── [Device C] ──Multi-hop── [Device D]
   100m radius         100m radius         100m radius
ParameterValue
Direct P2PBLE 100m radius
Multi-hopN relay x 100m
ProtocolBridgefy SDK
EncryptionX3DH + Double Ratchet + AES-256-GCM
OfflineStore & Forward queue
Use CaseDisaster, winery fields, remote areas

architecture.ondeviceTitle

architecture.ondeviceDesc

Rosetta

Offline即将推出

architecture.rosettaDesc

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

Pet Companion

Offline即将推出

architecture.petDesc

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

SUM

Offline即将推出

上传 PDF、演示文稿和文档以获取 AI 驱动的摘要、深度洞察和多角度分析 — 完全在设备端处理。另外通过 Gemini 即时 AI 摘要 URL。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

密钥生命周期与轮换

Key TypeRotationPurpose
Identity Key (X25519)Account lifetimeCore identity
Signing Key (Ed25519)90 days + grace periodAEGIS message signatures
Signed PreKey (X25519)7-30 daysX3DH handshake
One-Time PreKeys (X25519)Single useForward secrecy per session
PQ PreKey (ML-KEM-1024)Account lifetimePost-quantum key encapsulation
Double Ratchet KeysPer message exchangePer-message forward secrecy