2e7b72307d
E2E encrypted chat (X3DH + Double Ratchet, Signal Protocol). Server: asyncio TCP + TLS, MySQL. Clients: PyQt6 GUI + CLI. Secrets (.env, TLS keys, Cloudflare token), runtime data and mobile clients (separate repos) are gitignored. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
153 lines
8.8 KiB
Markdown
153 lines
8.8 KiB
Markdown
# Gemini Advanced Roadmap: Beyond the Basics
|
|
|
|
Tento dokument obsahuje pokročilé návrhy na vylepšení bezpečnosti, architektury a UX aplikace `encrypted_chat`. Tyto body jdou nad rámec běžného "best practice" a směřují k funkcionalitě profesionálních secure messengerů (Signal, Threema, Wire) se zaměřením na ochranu metadat a anti-forenzní techniky.
|
|
|
|
---
|
|
|
|
## 1. Ochrana Metadat & Traffic Analysis Resistance
|
|
*Cíl: Server by neměl vědět, KDO s KÝM komunikuje, ani JAKÝ typ dat si posílají.*
|
|
|
|
### Sealed Sender (Odesílatel v obálce)
|
|
- **Koncept:** Server zná pouze `recipient_id`. Identita odesílatele (`sender_id`) je zašifrována uvnitř zprávy (v "obálce"), kterou server nedokáže přečíst.
|
|
- **Implementace:**
|
|
1. Odesílatel vygeneruje klíč pro obálku (např. z profilu příjemce).
|
|
2. Zabalí `sender_id` a payload do šifrovaného bloku.
|
|
3. Server doručí blob příjemci bez ověření odesílatele (ověření proběhne až na klientovi po rozbalení).
|
|
4. **Výhoda:** Při kompromitaci serveru útočník nevidí sociální graf (kdo se s kým baví).
|
|
|
|
### Traffic Padding & Constant Bitrate
|
|
- **Problém:** Délka paketu prozrazuje obsah (krátký paket = "Ahoj", dlouhý paket = obrázek/klíč). Intervaly prozrazují aktivitu.
|
|
- **Řešení:**
|
|
1. **Padding:** Všechny zprávy doplňovat náhodnými daty na fixní velikosti (např. bloky 4KB).
|
|
2. **Dummy Traffic (Chaff):** Klient náhodně odesílá "falešné" pakety na server, které server zahodí nebo vrátí (echo).
|
|
3. **Výhoda:** Pro síťového analytika (ISP) vypadá tok dat jako konstantní šum.
|
|
|
|
---
|
|
|
|
## 2. Anti-Forenzní Ochrana (Client-side)
|
|
*Cíl: Minimalizovat dopad fyzického zabavení zařízení nebo vynuceného odemčení.*
|
|
|
|
### Duress Password (Heslo pod nátlakem)
|
|
- **Funkce:** Uživatel si nastaví *druhé* heslo.
|
|
- **Chování:** Pokud se přihlásí tímto heslem:
|
|
- **Varianta A (Decoy):** Odemkne se prázdná nebo falešná databáze s neškodnými konverzacemi.
|
|
- **Varianta B (Panic):** Aplikace na pozadí tiše provede **secure wipe** (přepis) privátních klíčů a reálné DB, zatímco uživateli zobrazí "Connection Error".
|
|
|
|
### Secure Deletion & DB Vacuuming
|
|
- **Problém:** SQL `DELETE` data nesmaže fyzicky, jen označí místo jako volné.
|
|
- **Řešení:**
|
|
1. Před smazáním zprávy přepsat obsah náhodnými byty (`UPDATE messages SET content = random_blob WHERE id = ...`).
|
|
2. Pravidelně spouštět `VACUUM` (u SQLite) nebo optimalizaci tabulek.
|
|
3. Pro soubory (obrázky) použít bezpečné mazání (overwrite passes) před `os.unlink()`.
|
|
|
|
### Disappearing Messages (TTL)
|
|
- **Funkce:** Odesílatel nastaví životnost zprávy (např. 1 minuta).
|
|
- **Implementace:** Odpočet začíná okamžikem zobrazení (Read Receipt). Po uplynutí času klient data nenávratně smaže z disku (včetně secure wipe). Server maže ihned po doručení.
|
|
|
|
---
|
|
|
|
## 3. Infrastruktura & Škálování
|
|
*Cíl: Odlehčit Python procesu a databázi pro podporu tisíců uživatelů.*
|
|
|
|
### Object Storage (MinIO / S3) + Presigned URLs
|
|
- **Problém:** `server.py` blokuje I/O při příjmu velkých souborů.
|
|
- **Řešení:**
|
|
1. Klient požádá server o upload.
|
|
2. Server vygeneruje **Presigned PUT URL** (časově omezený token pro přímý upload do MinIO/S3).
|
|
3. Klient nahrává data přímo do úložiště (obchází aplikační server).
|
|
4. Server ukládá pouze odkaz (URL/Key).
|
|
- **Výhoda:** Masivní zrychlení, server řeší jen metadata.
|
|
|
|
### Read/Write Splitting (MySQL Replication)
|
|
- **Architektura:**
|
|
- **Master DB:** Pouze pro `INSERT`, `UPDATE`, `DELETE`.
|
|
- **Read Replicas (Slaves):** Pro těžké `SELECT` dotazy (historie zpráv, hledání).
|
|
- **Implementace v `db.py`:** Router, který podle typu dotazu volí connection pool.
|
|
|
|
---
|
|
|
|
## 4. Protokol & Funkce
|
|
*Cíl: Rozšíření možností komunikace bez nutnosti centralizovaného streamování.*
|
|
|
|
### P2P Volání (WebRTC Signalizace)
|
|
- **Koncept:** Využít existující bezpečný kanál (Double Ratchet) pro výměnu SDP (Session Description Protocol) paketů.
|
|
- **Flow:**
|
|
1. Alice pošle Bobovi zašifrovanou zprávu typu `CALL_OFFER` s parametry WebRTC.
|
|
2. Bob odpoví `CALL_ANSWER`.
|
|
3. Klienti si vymění `ICE_CANDIDATES` (IP adresy/porty) a naváží přímé P2P spojení (UDP).
|
|
4. Audio/Video stream (SRTP) jde mimo server.
|
|
|
|
### Diferenciální Synchronizace (Merkle Trees)
|
|
- **Problém:** Stahování seznamu kontaktů (`get_user_contacts`) je pomalé při velkém množství dat.
|
|
- **Řešení:** Klient a server si udržují Hash Tree (Merkle Tree) stavu. Při synchronizaci porovnají pouze root hash. Pokud se liší, stahují se jen změněné větve stromu (delta update).
|
|
|
|
---
|
|
|
|
## 5. UI/UX (PyQt Speciality)
|
|
*Cíl: Ochrana soukromí na úrovni OS a skrytá komunikace.*
|
|
|
|
### Privacy Overlay (Task Switcher)
|
|
- **Funkce:** Detekovat událost ztráty fokusu okna (`QEvent.WindowDeactivate`) nebo minimalizace.
|
|
- **Akce:** Překrýt obsah okna rozmazaným efektem (`QGraphicsBlurEffect`) nebo logem aplikace.
|
|
- **Důvod:** Zabrání operačnímu systému (Windows/Linux/macOS) vytvořit čitelný náhled okna v Alt+Tab menu nebo v historii aktivit.
|
|
|
|
### Steganografie
|
|
- **Funkce:** Ukrýt šifrovanou zprávu do obrazových dat nevinného obrázku (např. meme kočky).
|
|
- **Implementace:** Modifikace LSB (Least Significant Bit) pixelů obrázku.
|
|
- **Výhoda:** Pro síťového admina nebo forenzní analýzu to vypadá jako běžné posílání obrázků, přítomnost šifrované komunikace je popiratelná.
|
|
|
|
---
|
|
|
|
## 6. High Availability Architecture (Distribuovaný Cluster)
|
|
*Cíl: Zajištění provozu i při výpadku/napadení serveru (Active-Active "RAID 1 přes síť").*
|
|
|
|
### Architektura: Geograficky Distribuovaný "Zero-Trust" Cluster
|
|
|
|
#### 1. Vstupní brána (Global Traffic Manager)
|
|
- **Funkce:** Rozděluje klienty mezi dostupné servery (Round Robin / Geo-DNS).
|
|
- **Self-Healing:** Při výpadku Serveru A okamžitě přesměruje provoz na Server B. Uživatel nic nepozná.
|
|
|
|
#### 2. Aplikační vrstva (Stateless Servers)
|
|
- **Stav:** Servery jsou **bezstavové**. `server.py` neukládá nic důležitého v RAM.
|
|
- **Škálování:** Můžete spustit N instancí serveru. Je jedno, ke kterému se uživatel připojí.
|
|
- **Komunikace:** Servery spolu mluví přes rychlý Message Bus (Redis Pub/Sub) pro doručování real-time zpráv mezi uživateli na různých uzlech.
|
|
|
|
#### 3. Datová vrstva (Zrcadlení Dat - "RAID 1")
|
|
- **Databáze (MySQL Galera Cluster):** Synchronní multi-master replikace. Zápis na Serveru A se potvrdí, až když je fyzicky zapsán i na Serveru B (a C).
|
|
- *Efekt:* Ztráta serveru neznamená ztrátu dat (klíčů, zpráv).
|
|
- **Soubory (MinIO Cluster):** Distribuovaný Object Storage s Erasure Coding. Soubory jsou matematicky rozprostřeny přes všechny servery. Výpadek disku/serveru nevadí.
|
|
|
|
#### 4. Bezpečnostní pojistky ("Poisoned Node")
|
|
- **Soft Delete:** Databáze nemaže data ihned, ale označuje je jako smazané (ochrana proti `DELETE *` od útočníka).
|
|
- **Client-Side Verification:** I kdyby kompromitovaný server posílal podvržené klíče, klienti ověřují digitální podpisy (Identity Keys). Server nemůže zfalšovat identitu uživatelů.
|
|
|
|
---
|
|
|
|
## 7. Technický Upgrade pro Stateless Architekturu
|
|
*Cíl: Odstranit závislost na paměti procesu (RAM) pro umožnění horizontálního škálování.*
|
|
|
|
### 1. Redis jako Distribuovaná Paměť
|
|
Nahrazení Python `dict` struktur, které jsou lokální pro jeden proces, za centrální Redis úložiště přístupné všem serverům.
|
|
|
|
* **Párovací Session:**
|
|
* *Stav:* `pairing_sessions` (dict) -> Redis Key `pair:{code}` (Hash/String s TTL).
|
|
* *Efekt:* Uživatel může vyžádat kód na Serveru A a potvrdit ho na Serveru B.
|
|
* **Rate Limiting:**
|
|
* *Stav:* `rate_limits` (dict) -> Redis Key `rl:{ip}:{action}` (Counter s EXPIRE).
|
|
* *Efekt:* Limity platí globálně pro celý cluster, ne jen per server.
|
|
|
|
### 2. Redis Pub/Sub pro Real-Time Routing
|
|
Doručení zprávy uživateli, který je připojen k JINÉMU serveru než odesílatel.
|
|
|
|
* **Princip:**
|
|
1. Server A (odesílatel) zjistí, že příjemce Bob není připojen lokálně.
|
|
2. Server A publikuje zprávu do Redis kanálu `user:{bob_user_id}`.
|
|
3. Server B (kde je Bob připojen) tento kanál poslouchá (subscribe).
|
|
4. Server B přijme zprávu z Redisu a pošle ji Bobovi do otevřeného TCP socketu.
|
|
|
|
### 3. Session Sticky vs. Stateless Uploads
|
|
Řešení pro nahrávání souborů po částech (chunks).
|
|
|
|
* **Varianta A (Infrastructure - Sticky Sessions):** Load Balancer (HAProxy/Nginx) zajistí, že všechny požadavky od jedné IP jdou vždy na stejný server. Nejjednodušší, nevyžaduje změnu kódu.
|
|
* **Varianta B (Architectural - Direct Upload):** Viz bod 3 "Object Storage + Presigned URLs". Server vůbec nepřijímá data souboru, pouze vygeneruje token. Plně stateless řešení.
|