Files

Filip 5fd80e6dd6 initial commit

2026-03-11 16:54:14 +01:00

8.8 KiB

Raw Blame History

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í.

8.8 KiB Raw Blame History