Technical White Paper & Architectural Audit (v124.0.0-BETA) Technisches Whitepaper & Architektur-Audit (v124.0.0-BETA)

I. Executive Summary & Market Value PropositionI. Management-Zusammenfassung & Markt-Nutzenversprechen

1.1 OverviewÜberblick

StateZer0 is a hardened communications platform that minimizes server-side data exposure. The server acts only as a relay for encrypted blobs: I have no visibility into message or attachment content. Metadata is reduced to the minimum needed for routing and is never zero. This design limits, but does not eliminate, exposure to data requests. Phase 2-4 extends this architecture with multimedia encryption, biometric authentication, and Ghost Mode obfuscation. StateZer0 ist eine gehärtete Kommunikationsplattform, die die serverseitige Datenpreisgabe minimiert. Der Server fungiert ausschließlich als Relay für verschlüsselte Blobs. Phase 2-4 erweitert diese Architektur mit Multimedia-Verschlüsselung, biometrischer Authentifizierung und Ghost-Mode-Verschleierung.

1.2 Core Value Drivers (Phase 1 Complete)Kern-Werttreiber (Phase 1 Abgeschlossen)

• Sender-Side Performance & Security Hardening (v76.0.0 - Phase 1): Implemented the Direct RAM Pipeline for images and audio, keeping unencrypted bytes in volatile memory where feasible. For high-overhead video transcoding, transient plaintext artifacts are overwritten as a best-effort measure before deletion, reducing the chance of recoverable residue. Senderseitige Performance & Sicherheitshärtung (v76.0.0 - Phase 1): Implementierung der Direct RAM Pipeline für Bilder und Audio, die unverschlüsselte Bytes nach Möglichkeit im flüchtigen Speicher hält.
• Non-Blocking Netty Engine (v73.0.0): Heavy media extraction and Olm envelope hydration are offloaded to background worker pools. ThumbnailExtractorEngine was converted to an asynchronous service anchored to Dispatchers.IO, improving Main Thread responsiveness. Non-Blocking Netty-Engine (v73.0.0): Ressourcenintensive Medienextraktion und Olm-Envelope-Hydrierung werden in Hintergrund-Worker-Pools ausgelagert.
• Encrypted Relay with Minimized Metadata (v25.2.7): Sensitive identifiers are pre-blinded on the Android client before they reach the relay. The relay routes opaque pointers but does not have access to message or attachment content. Verschlüsseltes Relay mit minimierten Metadaten (v25.2.7): Sensitive Identifikatoren werden auf dem Android-Client vorverblindet, bevor sie das Relay erreichen.
• VoIP Engine Decoupling (v52.0.0): The VoIP media stack is isolated from standard messaging and storage domains. Native WebRTC components are explicitly disposed when a call ends. Calls are forced through TURN as a privacy choice. VoIP-Engine-Entkopplung (v52.0.0): Der VoIP-Medienstack ist von den Standard-Messaging- und Speicherdomänen isoliert.
• Client-Side Identity Autonomy: Identity is established via 256-bit local entropy (BIP39), removing the need for phone numbers or email addresses—the primary vectors for state-level deanonymization. Clientseitige Identitätsautonomie: Die Identität wird über eine lokale 256-Bit-Entropie (BIP39) etabliert, wodurch Telefonnummern oder E-Mail-Adressen überflüssig werden.

1.3 Phase 2-4 Roadmap (In Development)Phase 2-4 Roadmap (In Entwicklung)

II. Encrypted Message Relay & Metadata MinimizationII. Verschlüsselter Nachrichten-Relay & Metadatenminimierung

2.1 Minimized Routing & Metadata Isolation2.1 Minimiertes Routing & Metadaten-Isolation

The StateZer0 server operates as a relay for encrypted data. Message and attachment payloads pass through the pipeline as opaque cryptographic blobs; I have no visibility into their content. Routing metadata is minimized, not eliminated, because delivery requires some addressing information. Der StateZer0-Server fungiert als Relay für verschlüsselte Daten. Nachrichten- und Anhangs-Payloads passieren die Pipeline als opake kryptografische Blobs.

• Blinded Recipient IDs: Recipient identifiers are hashed via SHA-256 and salted with a server-side pepper before database insertion. The relay delivers messages to these blinded pointers without knowledge of the true user identity. Blinded Recipient IDs: Empfängerkennungen werden vor der Datenbankeinfügung über SHA-256 gehasht und mit einem serverseitigen Pepper gesalzen.
• Discovery Policy Enforcement (v25.3.1): Accounts are hidden from search by default. The Add Contact dialog offers 6-character invite codes and QR/deep links as the primary flows, plus a secondary "Search by username" option that only queries users who have opted in. Discovery-Policy-Durchsetzung (v25.3.1): Konten sind standardmäßig in der Suche verborgen. Das Hinzufügen eines Kontakts erfordert eine Einladungsanfrage mit gegenseitiger Zustimmung.
• Payload Opacity: Message and attachment payloads are encrypted end-to-end; the relay cannot decrypt them. Server-side fields needed for routing are encrypted at rest with AES-256-GCM using GHOST_FIELD_KEY. Payload-Opazität: Nachrichten- und Anhangs-Payloads sind Ende-zu-Ende-verschlüsselt; das Relay kann sie nicht entschlüsseln.

2.2 Transport-Layer Security (TLS) vs. E2EE2.2 Transport-Layer Security (TLS) vs. E2EE

While TLS protects the data in transit from external interceptors, StateZer0 treats the relay itself as a potential adversary. The Olm Protocol (Double Ratchet) is used to wrap every payload, ensuring that even if the relay were compromised, the data remains cryptographically inaccessible. Während TLS die Daten während der Übertragung vor externen Interzeptoren schützt, betrachtet StateZer0 das Relay selbst als potenziellen Angreifer.

2.3 Message TTL & Cleanup (Phase 2.4)2.3 Message TTL & Bereinigung (Phase 2.4)

StateZer0 implements automatic message expiration and cleanup protocols to limit temporal data exposure on the relay and in local storage. StateZer0 implementiert automatische Nachrichtenablauf- und Bereinigungsprotokolle, um die zeitliche Datenpreisgabe auf dem Relay und im lokalen Speicher zu begrenzen.

• Server-Side TTL & R2 Media Lifecycle: Acknowledged text messages are purged from MongoDB immediately (0s). Acknowledged media attachments (photos, GIFs, custom photos, audio clips, video recordings, multi-attachment bundles) are purged from Cloudflare R2 within 5 minutes of acknowledgment (allowing client background workers to finalize local disk caching). Undelivered text messages are retained for a maximum 72-hour transit window in MongoDB (`messages.expiresAt` TTL index). Undelivered offline media attachments and orphaned upload URLs are auto-deleted from Cloudflare R2 after 24 hours max. Presence signals (Status and Avatar updates) are strictly ephemeral (live WebSocket-only, never stored in MongoDB). Serverseitige TTL & R2-Medien-Lifecycle: Bestätigte Textnachrichten werden sofort (0s) aus MongoDB gelöscht. Bestätigte Medienanhänge (Fotos, GIFs, Audio, Video, Dateien, Bündel) werden innerhalb von 5 Minuten nach Bestätigung aus Cloudflare R2 gelöscht (für lokales Caching). Unzugestellte Textnachrichten verbleiben maximal 72 Stunden in MongoDB. Unzugestellte Offline-Medienanhänge und verwaiste Upload-URLs werden nach maximal 24 Stunden automatisch aus Cloudflare R2 gelöscht. Präsenzsignale (Status- und Avatar-Updates) sind flüchtig (nur Live-WebSocket) und werden niemals in MongoDB gespeichert.
• Local Message Cleanup (v3.0.0): The app runs a daily cleanup task that deletes archived messages older than 90 days (configurable in Settings). Cached thumbnails and media previews older than 7 days are cleared. This prevents long-term local storage bloat. Lokale Nachrichtenbereinigung (v3.0.0): Die App führt täglich eine Bereinigungsaufgabe durch, die archivierte Nachrichten älter als 90 Tage löscht (konfigurierbar in den Einstellungen).
• Ephemeral Message Mode (Phase 2.5 Preview): Users can set individual messages or entire conversations to auto-delete after 1, 7, 30, or 90 days. The deletion occurs locally and is signaled to the recipient via a metadata flag. Both sender and recipient receive notifications before auto-deletion. Ephemeral Message Mode (Phase 2.5 Vorschau): Benutzer können einzelne Nachrichten oder ganze Unterhaltungen so einstellen, dass sie nach 1, 7, 30 oder 90 Tagen automatisch gelöscht werden.
• Reaper Task Performance: The server background reaper task runs every 60 seconds to process `vault_reaper` jobs and purge expired R2 objects. Tracking records are deleted immediately upon object removal, backed by a 24-hour native MongoDB TTL index (`deleteAt`). Reaper Task Performance: Der Server-Hintergrundreaper läuft alle 60 Sekunden, um `vault_reaper`-Jobs zu verarbeiten und abgelaufene R2-Objekte zu löschen. Tracking-Datensätze werden sofort nach der Objektentfernung gelöscht, abgesichert durch einen 24-Stunden-MongoDB-TTL-Index (`deleteAt`).

2.4 Search, Block, Reactions & Editing (Phase 2.5)2.4 Suche, Blockierung, Reaktionen & Bearbeitung (Phase 2.5)

Phase 2.5 adds advanced messaging features while maintaining end-to-end encryption and privacy. Phase 2.5 fügt erweiterte Messaging-Funktionen hinzu, während gleichzeitig die Ende-zu-Ende-Verschlüsselung und der Datenschutz erhalten bleiben.

• Full-Text Search (Local): Messages are indexed locally using SQLCipher's full-text search (FTS5) module. Search queries run entirely on the device; no search data is sent to the server. Vault items are also searchable by filename and metadata. Volltext-Suche (Lokal): Nachrichten werden lokal mit dem FTS5-Modul von SQLCipher indiziert. Suchanfragen werden vollständig auf dem Gerät durchgeführt; keine Suchdaten werden an den Server gesendet.
• Contact Blocking: Users can block contacts from the contact details page. Blocked users cannot send new messages (new messages are rejected at the relay level). Existing messages from blocked contacts remain visible locally but are marked as "Blocked User" in the UI. Block events are not signaled to the blocked contact. Kontaktblockierung: Benutzer können Kontakte von der Kontaktdetailseite blockieren. Blockierte Benutzer können keine neuen Nachrichten senden. Bestehende Nachrichten blockierter Kontakte bleiben lokal sichtbar, sind aber in der UI als „Blockierter Benutzer" gekennzeichnet.
• Message Reactions (Emoji): Users can react to messages with emoji. Reactions are stored in the message metadata and encrypted inside the Olm envelope. Reaction data is not sent to the relay; it remains encrypted and is only visible to participants in the conversation. Adding or removing a reaction sends a small encrypted metadata update to the recipient. Nachricht-Reaktionen (Emoji): Benutzer können mit Emoji auf Nachrichten reagieren. Reaktionen werden in den Nachricht-Metadaten gespeichert und sind im Olm-Umschlag verschlüsselt. Reaktionsdaten werden nicht an das Relay gesendet.
• Message Editing: Users can edit sent messages up to 24 hours after sending. The edited message is stored as a new version in the local database and is marked with an "edited" timestamp. The original message content is retained as an immutable history entry. Recipients receive an encrypted "edited" notification with the new content. Old message versions are deleted from the relay after 24 hours. Nachrichtenbearbeitung: Benutzer können gesendete Nachrichten bis zu 24 Stunden nach dem Senden bearbeiten. Die bearbeitete Nachricht wird als neue Version in der lokalen Datenbank gespeichert und mit einem „bearbeitet"-Zeitstempel gekennzeichnet.
• Unsend/Delete Message (24h Window): Users can delete messages they sent within a 24-hour window. Deleted messages are marked as "unsent" on both devices; the relay is notified to purge the encrypted blob. After 24 hours, messages cannot be deleted. Nachricht löschen/Unsend (24h-Fenster): Benutzer können innerhalb eines 24-Stunden-Fensters gesendete Nachrichten löschen. Gelöschte Nachrichten werden auf beiden Geräten als „nicht gesendet" markiert; das Relay wird benachrichtigt, den verschlüsselten Blob zu löschen.

III. Phase 2: Multimedia FeaturesIII. Phase 2: Multimedia-Features

3.1 Voice & Video Calls (Phase 2.1)3.1 Sprach- & Videoanrufe (Phase 2.1)

Phase 2.1 extends StateZer0 with encrypted peer-to-peer voice and video calling, maintaining the same security model as messages. Phase 2.1 erweitert StateZer0 um verschlüsselte Peer-to-Peer-Sprach- und Videoanrufe, die das gleiche Sicherheitsmodell wie Nachrichten beibehalten.

• WebRTC End-to-End Encryption: Audio and video streams are encrypted using DTLS-SRTP (Datagram TLS over Secure Real-time Transport Protocol). Each call generates unique encryption keys derived from the Olm session. Call signaling (call initiation, answer, ice candidates) is transmitted inside encrypted Olm envelopes; the relay sees only encrypted metadata. WebRTC End-to-End-Verschlüsselung: Audio- und Video-Streams werden mit DTLS-SRTP verschlüsselt (Datagram TLS über Secure Real-time Transport Protocol). Jeder Anruf generiert eindeutige Verschlüsselungsschlüssel, die aus der Olm-Sitzung abgeleitet werden.
• Signaling via Relay: Call setup signals (offer, answer, ICE candidates) are wrapped in encrypted Olm envelopes and transmitted through the relay. The relay does not interpret the signaling data; it is opaque to the server. Call metadata (initiator, recipient, timestamp, duration) is logged for billing/analytics, but the content of the call is never accessible to the relay. Signalisierung via Relay: Anrufaufbau-Signale (Angebot, Antwort, ICE-Kandidaten) werden in verschlüsselte Olm-Umschläge eingewickelt und über das Relay übertragen. Das Relay interpretiert die Signalisierungsdaten nicht; sie sind für den Server undurchsichtig.
• TURN Relay Enforcement: Calls are forced through TURN relay servers (Metered.ca) as a privacy choice. This hides peer IP addresses from each other but adds latency (~50ms). Direct peer-to-peer connections are not attempted. TURN servers see encrypted audio/video but not the call content. TURN-Relay-Erzwingung: Anrufe werden über TURN-Relay-Server (Metered.ca) als datenschutzorientierte Entscheidung geleitet. Dies verbirgt die Peer-IP-Adressen voreinander, erhöht aber die Latenz (~50ms).
• Audio Processing: Hybrid acoustic echo cancellation (AEC) combines hardware platform filters with AEC3 software filtering. A +150% digital gain stage improves speakerphone clarity. Noise suppression is applied to outgoing audio. Audio-Verarbeitung: Hybrid-Echokompensation kombiniert Hardware-Plattformfilter mit AEC3-Softwarefiltern. Eine +150%-digitale Gain-Stufe verbessert die Freisprechlautstärke.
• Video Codec & Adaptive Bitrate: Video is encoded with VP9 (fallback H.264) and transmitted at adaptive bitrate (300 kbps to 2.5 Mbps depending on network conditions). Resolution adapts dynamically from QVGA to HD (1280x720). Video frames are encrypted with per-frame SRTP keys. Video-Codec & Adaptive Bitrate: Video wird mit VP9 (Fallback H.264) kodiert und mit adaptiver Bitrate (300 kbps bis 2,5 Mbps je nach Netzwerkbedingungen) übertragen. Die Auflösung passt sich dynamisch von QVGA zu HD (1280x720) an.
• Call History & Logs: Call metadata (initiator, recipient, timestamp, duration) is stored locally and encrypted with the message database key. Call history can be deleted manually or via the automatic cleanup task. The relay does not store call history; only metadata for routing is retained during the active call. Anrufhistorie & Protokolle: Anrufmetadaten (Initiator, Empfänger, Zeitstempel, Dauer) werden lokal gespeichert und mit dem Nachrichtendatenbank-Schlüssel verschlüsselt. Die Anrufhistorie kann manuell oder über die automatische Bereinigungsaufgabe gelöscht werden.
• Native Component Disposal (v52.0.0): When a call ends, all WebRTC components (AudioSource, AudioTrack, PeerConnection, VideoTrack) receive explicit dispose() calls. This releases native memory and reduces the window where sensitive call data remains in memory. Freigabe nativer Komponenten (v52.0.0): Wenn ein Anruf endet, erhalten alle WebRTC-Komponenten (AudioSource, AudioTrack, PeerConnection, VideoTrack) explizite dispose()-Aufrufe. Dies gibt nativen Speicher frei und verringert das Zeitfenster, in dem sensible Anrufdaten im Speicher verbleiben.

3.2 Multi-Attachment Bundles (Phase 2.2)3.2 Multi-Attachment-Bundles (Phase 2.2)

Phase 2.2 introduces multi-attachment bundles, allowing users to send multiple images, videos, and documents in a single transaction. Phase 2.2 führt Multi-Attachment-Bundles ein, die es Benutzern ermöglichen, mehrere Bilder, Videos und Dokumente in einer einzigen Transaktion zu senden.

• Atomic Enclave Ingress (v40.1.6): StateZer0 supports multi-attachment bundles. Multiple images, videos, or documents can be grouped into a single encrypted enclave. The platform uses an isolated staging area (GHOST_STAGING_) with UUID seeds; files are moved to the final payload namespace only after database confirmation. Atomarer Enklaven-Ingress (v40.1.6): StateZer0 unterstützt Multi-Attachment-Bundles. Mehrere Bilder, Videos oder Dokumente können in einer einzigen verschlüsselten Enklave gruppiert werden.
• Media Processing Pipeline: Each attachment is processed independently: images are EXIF-stripped and optimized (max 8 MP), videos are transcoded (H.264, max 1080p), documents are scanned for embedded metadata. Processing is parallelized across Dispatchers.IO. Medienverarbeitungs-Pipeline: Jeder Anhang wird unabhängig verarbeitet: Bilder werden EXIF-bereinigt und optimiert (max 8 MP), Videos werden transkodiert (H.264, max 1080p), Dokumente werden auf eingebettete Metadaten gescannt.
• Progressive Upload: Files are uploaded sequentially; the relay stores each encrypted blob with a timestamp. A "bundle complete" message is sent after all files are confirmed uploaded. If upload fails, only uploaded files are retained; partial bundles can be resumed. Progressive Upload: Dateien werden sequenziell hochgeladen; das Relay speichert jeden verschlüsselten Blob mit einem Zeitstempel. Eine „Bundle-Fertig"-Nachricht wird gesendet, nachdem alle Dateien bestätigt wurden.
• Bundle Playback (Phase 2.3): Recipients can swipe through bundled media using ViewPager2. Each item is decrypted in memory for viewing; decrypted buffers are released when the user swipes away. A "Gallery" view shows thumbnail grid of all items in the bundle. Bundle-Wiedergabe (Phase 2.3): Empfänger können durch gebündelte Medien wischen, indem sie ViewPager2 verwenden. Jedes Element wird für die Anzeige in den Speicher entschlüsselt; entschlüsselte Puffer werden freigegeben, wenn der Benutzer wegwischt.
• Selective Save to Gallery: Users can save individual items from a bundle to their device gallery, or save all at once. Saved files are decrypted into the MediaStore; temporary cache is cleared after save completes. Selektives Speichern in Galerie: Benutzer können einzelne Elemente aus einem Bundle in ihrer Geräte-Galerie speichern oder alle auf einmal speichern. Gespeicherte Dateien werden in den MediaStore entschlüsselt; temporärer Cache wird nach Speichern gelöscht.

3.3 Encryption for All Media Types (Phase 2.2)3.3 Verschlüsselung für alle Medienmitteltypen (Phase 2.2)

• Images (JPEG, PNG, WebP): EXIF/IPTC metadata removed, compressed to max 8 MP, encrypted with AES-256-GCM. Thumbnail (512px) generated for preview. Bilder (JPEG, PNG, WebP): EXIF/IPTC-Metadaten entfernt, auf max 8 MP komprimiert, mit AES-256-GCM verschlüsselt. Miniaturansicht (512px) für Vorschau generiert.
• Videos (MP4, MOV, WebM): Transcoded to H.264 (1080p max, 2.5 Mbps target), encrypted with AES-256-GCM. Poster frame extracted and encrypted separately. Duration and resolution metadata stripped. Videos (MP4, MOV, WebM): In H.264 transkodiert (max 1080p, 2,5 Mbps Ziel), mit AES-256-GCM verschlüsselt. Poster-Frame extrahiert und separat verschlüsselt.
• Audio (MP3, WAV, M4A): Transcoded to AAC (128 kbps), encrypted with AES-256-GCM. Metadata (ID3 tags, artist, title) removed before encryption. Audio (MP3, WAV, M4A): In AAC transkodiert (128 kbps), mit AES-256-GCM verschlüsselt. Metadaten (ID3-Tags, Künstler, Titel) vor Verschlüsselung entfernt.
• Documents (PDF, DOCX, XLSX, TXT): Scanned for embedded metadata and links, compressed if possible, encrypted with AES-256-GCM. File type validated before encryption to prevent polyglot file attacks. Dokumente (PDF, DOCX, XLSX, TXT): Auf eingebettete Metadaten und Links gescannt, wenn möglich komprimiert, mit AES-256-GCM verschlüsselt.

IV. Phase 3: Biometric Security & Local Storage HardeningIV. Phase 3: Biometrische Sicherheit & Lokale Speicherhärtung

4.1 Biometric Authentication (Phase 3.1)4.1 Biometrische Authentifizierung (Phase 3.1)

Phase 3.1 adds optional biometric (fingerprint, face) app lock to protect local data access. Phase 3.1 fügt optionalen biometrischen (Fingerabdruck, Gesicht) App-Lock hinzu, um den lokalen Datenzugriff zu schützen.

• Fingerprint/Face Unlock: Uses AndroidX BiometricPrompt API for fingerprint and face authentication. Biometric data never leaves the device's secure processor. App unlock uses a 30-second timeout after successful authentication. Fingerabdruck/Gesichts-Entsperrung: Verwendet AndroidX BiometricPrompt API für Fingerabdruck- und Gesichtserkennung. Biometrische Daten verlassen nie den sicheren Prozessor des Geräts.
• App Lock & Screen Security: Enabling the app lock automatically enables screen security (blocks screenshots and screen recording). App lock re-prompts after 2 seconds in background. Users can customize lock timeout (5s, 30s, 1m, 5m). App-Sperre & Bildschirm-Sicherheit: Das Aktivieren der App-Sperre aktiviert automatisch die Bildschirm-Sicherheit (blockiert Screenshots und Bildschirmaufnahmen). App-Sperre fordert nach 2 Sekunden im Hintergrund erneut auf.
• Fallback PIN: Users can set a 4-6 digit PIN as fallback if biometric authentication fails. The PIN is hashed with Argon2 and stored in Android Keystore. Fallback-PIN: Benutzer können eine 4-6-stellige PIN als Fallback einstellen, wenn die biometrische Authentifizierung fehlschlägt. Die PIN wird mit Argon2 gehasht und im Android Keystore gespeichert.
• Biometric Failure Handling: After 5 failed biometric attempts, the app requires PIN entry. After 5 failed PIN attempts, the app triggers emergency account deletion (same as Emergency PIN feature). Users are warned before reaching the limit. Biometrischer Fehler-Handling: Nach 5 fehlgeschlagenen biometrischen Versuchen erfordert die App PIN-Eingabe. Nach 5 fehlgeschlagenen PIN-Versuchen wird die Notfall-Kontolöschung ausgelöst.

4.2 Database Encryption & Android Keystore Integration (Phase 3.2)4.2 Datenbankverschlüsselung & Android Keystore Integration (Phase 3.2)

• SQLCipher AES-256: All local data is encrypted with SQLCipher using AES-256-GCM. The database passphrase is wrapped with an Android Keystore AES key. SQLCipher AES-256: Alle lokalen Daten werden mit SQLCipher mit AES-256-GCM verschlüsselt. Die Datenbank-Passphrase wird mit einem Android-Keystore-AES-Schlüssel umhüllt.
• Key Rotation (Yearly): The database encryption key is rotated annually. During rotation, the passphrase is re-wrapped with a new Keystore key. Rotation happens in background during app idle time. Schlüssel-Rotation (Jährlich): Der Datenbank-Verschlüsselungsschlüssel wird jährlich rotiert. Bei der Rotation wird die Passphrase mit einem neuen Keystore-Schlüssel re-wrapped. Die Rotation erfolgt im Hintergrund während Leerlauf der App.
• Memory Sanitization: Sensitive keys (mnemonics, passphrases) are held in ByteArray/CharArray and zeroed after use using Arrays.fill(key, 0) in finally blocks. Speicher-Sanitisation: Sensible Schlüssel (Mnemonics, Passphrasen) werden in ByteArray/CharArray gehalten und nach Gebrauch mit Arrays.fill(key, 0) in finally-Blöcken auf Null gesetzt.

4.3 Vault Encryption & Secure Deletion (Phase 3.3)4.3 Vault-Verschlüsselung & Sichere Löschung (Phase 3.3)

• The Sovereign Vault (v11.0.0+): A localized, encrypted repository for long-term storage of sensitive media, documents, and sealed transcripts. Vault items are encrypted with unique per-file AES-256-GCM keys and indexed via SHA-256 hashes. Decryption keys are stored in the SQLCipher database. Der Sovereign Vault (v11.0.0+): Ein lokales, verschlüsseltes Repository für die langfristige Speicherung sensibler Medien, Dokumente und versiegelte Transkripte. Vault-Elemente werden mit eindeutigen AES-256-GCM-Schlüsseln verschlüsselt und über SHA-256-Hashes indiziert.
• Chat-to-Vault Archive: Individual attachments, voice notes, and sealed text transcripts can be saved directly from the chat context menu into the Vault, keeping them encrypted and isolating them from transient chat enclaves. Chat-zu-Vault-Archiv: Einzelne Anhänge, Sprachnotizen und versiegelte Texttransskripte können direkt aus dem Chat-Kontextmenü im Vault gespeichert werden.
• One-Tap Secure Deletion: Deleting from the Vault removes the file and overwrites the storage area as a best-effort measure before deletion. Overwrite uses 1-pass zero fill (best-effort). One-Tap Sichere Löschung: Das Löschen aus dem Vault entfernt die Datei und überschreibt den Speicherbereich vor der Löschung nach bestem Bemühen.
• Forced Player Release: Active media players are released before a delete or account-wipe command runs, so file locks do not block deletion. Forced Player Release: Aktive Medienplayer werden freigegeben, bevor ein Lösch- oder Konto-Lösch-Befehl ausgeführt wird.

V. Phase 4: Ghost Mode & Metadata ObfuscationV. Phase 4: Ghost Mode & Metadaten-Verschleierung

5.1 Ghost Mode Overview (Phase 4.1)5.1 Ghost Mode Überblick (Phase 4.1)

Phase 4 introduces Ghost Mode, an optional privacy enhancement that obfuscates metadata visible to the relay server. When enabled, Ghost Mode applies multiple countermeasures to hide temporal and behavioral patterns. Phase 4 führt den Ghost Mode ein, eine optionale Datenschutz-Erweiterung, die für das Relay sichtbare Metadaten verschleiert. Wenn aktiviert, wendet der Ghost Mode mehrere Gegenmaßnahmen an, um zeitliche und verhaltensbezogene Muster zu verbergen.

5.2 Metadata Obfuscation Techniques (Phase 4.1-4.3)5.2 Metadaten-Verschleierungs-Techniken (Phase 4.1-4.3)

• Decoy Messages (Phase 4.1): When enabled, Ghost Mode injects dummy encrypted messages at randomized intervals (1-5 min) to the relay. Decoy messages are indistinguishable from real messages. They are rejected by recipients (duplicate-checked via local tracking) and are deleted by the relay after 1 minute. This hides true message sending patterns. Dummy-Nachrichten (Phase 4.1): Wenn aktiviert, fügt der Ghost Mode Dummy-verschlüsselte Nachrichten in zufälligen Intervallen (1-5 Min.) zum Relay hinzu. Dummy-Nachrichten sind von echten Nachrichten nicht zu unterscheiden. Sie werden vom Empfänger abgelehnt (Duplikat-geprüft via lokales Tracking) und vom Relay nach 1 Minute gelöscht. Dies verbirgt echte Nachrichtenmuster.
• Connection Noise (Phase 4.2): Ghost Mode maintains a constant connection with random "heartbeat" jitter (±30% variance). This makes it harder for network observers to determine when the user is actually active vs. idle. Heartbeat packets are encrypted and carry no payload data. Verbindungs-Rauschen (Phase 4.2): Der Ghost Mode behält eine konstante Verbindung mit zufälligem „Herzschlag"-Jitter (±30% Varianz) bei. Dies macht es für Netzwerk-Beobachter schwieriger, zu bestimmen, wann der Benutzer tatsächlich aktiv ist, im Gegensatz zu inaktiv.
• Metadata Blinding (Phase 4.2): Timestamp precision is reduced from milliseconds to 5-minute buckets. Read receipts are delayed by 2-10 minutes to hide true reading patterns. Typing indicators are disabled. Contact relationship changes are not immediately signaled; they are batched and sent at random intervals. Metadaten-Verblindung (Phase 4.2): Die Zeitstempel-Genauigkeit wird von Millisekunden auf 5-Minuten-Buckets reduziert. Lesebestätigungen werden um 2-10 Minuten verzögert, um echte Lesemuster zu verbergen. Tipp-Indikatoren sind deaktiviert.
• Contact Shuffling (Phase 4.3): In Ghost Mode, contact roster updates are batched and reshuffled so the relay cannot infer which contacts you are actively communicating with. Roster queries are padded with fake lookups to confuse pattern analysis. Kontakt-Durchmischung (Phase 4.3): Im Ghost Mode werden Contact Roster-Updates gesammelt und durchgemischt, sodass das Relay nicht schlussfolgern kann, mit welchen Kontakten Sie aktiv kommunizieren. Roster-Anfragen werden mit falschen Lookups aufgefüllt.
• CPU Cost & Battery Trade-off: Ghost Mode increases CPU usage by ~15% and battery drain by ~8% due to decoy message generation and connection noise. Users can disable Ghost Mode to improve battery life. CPU-Kosten & Akku-Tradeoff: Der Ghost Mode erhöht die CPU-Auslastung um ~15% und den Akkuverbrauch um ~8% aufgrund der Dummy-Nachrichtengenerierung und des Verbindungs-Rauschens. Benutzer können den Ghost Mode deaktivieren, um die Akkulaufzeit zu verbessern.

5.3 Ghost Mode Settings & Controls (Phase 4.4)5.3 Ghost Mode Einstellungen & Steuerelemente (Phase 4.4)

• Per-Chat Ghost Mode: Users can enable Ghost Mode on individual conversations (hide metadata for only that contact) or system-wide (all chats). Per-chat mode is useful for sensitive conversations; system-wide mode is extreme privacy but expensive. Pro-Chat Ghost Mode: Benutzer können den Ghost Mode für einzelne Unterhaltungen (Metadaten nur für diesen Kontakt ausblenden) oder system-weit (alle Chats) aktivieren. Pro-Chat-Modus ist nützlich für vertrauliche Unterhaltungen.
• Ghost Mode Indicator: When Ghost Mode is enabled, a "👻" icon appears in the chat header or conversation list. Recipients are not notified that Ghost Mode is active (hiding that would leak metadata). Ghost Mode Indikator: Wenn der Ghost Mode aktiviert ist, wird ein „👻"-Symbol in der Chat-Kopfzeile oder Unterhaltungsliste angezeigt.
• Ghost Mode Toggle in Privacy Settings: Under Settings → Privacy, users can toggle system-wide Ghost Mode, adjust decoy message frequency (disabled, low, medium, high), and set read receipt delay (immediate, 2-5 min, 5-10 min). Ghost Mode Umschalter in Datenschutzeinstellungen: Unter Einstellungen → Datenschutz können Benutzer den system-weiten Ghost Mode umschalten, die Dummy-Nachrichtenhäufigkeit anpassen und die Verzögerung der Lesebestätigung einstellen.

VI. Client-Side Cryptographic Core (Deep Dive)VI. Clientseitiger kryptografischer Kern (Deep Dive)

6.1 Identity & Device-Bound Scarcity (The 1-Device Rule)6.1 Identität & gerätegebundene Knappheit (Die 1-Geräte-Regel)

To enforce account scarcity and limit automated Sybil attacks, StateZer0 ties each account to a device-bound identity key. Um Kontenknappheit durchzusetzen und automatisierte Sybil-Angriffe einzuschränken, bindet StateZer0 jedes Konto an einen gerätegebundenen Identitätsschlüssel.

• Android Keystore Identity Key: The client generates a device-bound identity key in Android Keystore. The key is non-exportable and used to derive a stable device identifier that the server checks for scarcity enforcement. Android-Keystore-Identitätsschlüssel: Der Client generiert einen gerätegebundenen Identitätsschlüssel im Android Keystore. Der Schlüssel ist nicht exportierbar und dient zur Ableitung eines stabilen Geräte-Identifikators.
• Device Attestation: The registration flow invokes the Google Play Integrity API to obtain a token used as an integrity signal. The relay rejects attempts to register a device-bound identifier that is already marked as occupied. Geräte-Attestierung: Der Registrierungsablauf ruft die Google Play Integrity API auf, um ein Token als Integritätssignal zu erhalten.

6.2 The Double Ratchet Mechanism6.2 Der Double-Ratchet-Mechanismus

Payload encryption is managed by the Double Ratchet mechanism, combining a Diffie-Hellman (DH) Ratchet and a Symmetric-Key Ratchet. Die Verschlüsselung der Payload wird durch den Double-Ratchet-Mechanismus verwaltet, der einen Diffie-Hellman (DH) Ratchet und einen Symmetric-Key Ratchet kombiniert.

• Perfect Forward Secrecy (PFS): Every message is encrypted with a unique key derived from the rolling ratchet. Compromising one key yields no access to previous messages. Perfect Forward Secrecy (PFS): Jede Nachricht wird mit einem eindeutigen Schlüssel verschlüsselt, der aus dem rotierenden Ratchet abgeleitet wird.
• Break-in Recovery (Future Secrecy): If an adversary compromises a device's current state, the DH ratchet ensures the session "heals" as soon as the next message exchange occurs, locking the adversary out of future communications. Break-in Recovery (Future Secrecy): Wenn ein Angreifer den aktuellen Zustand eines Geräts kompromittiert, stellt der DH-Ratchet sicher, dass die Sitzung „heilt".

6.3 Deterministic Identity & BIP39 Restorations6.3 Deterministische Identität & BIP39-Wiederherstellungen

StateZer0 derives the master identity keypair from the 12-word BIP39 mnemonic. This avoids "Identity Changed" warnings when the same mnemonic is restored on a new device. StateZer0 leitet das Master-Identitätsschlüsselpaar aus dem 12-Wörter-BIP39-Mnemonic ab. Dies vermeidet Warnungen über eine „geänderte Identität".

VII. Sovereign Vault & Encrypted Media PipelineVII. Sovereign Vault & Verschlüsselte Medien-Pipeline

7.1 The Sovereign Vault (Encrypted Archive Management)7.1 Der Sovereign Vault (Verschlüsselte Archivverwaltung)

StateZer0 introduces the Sovereign Vault, a localized, encrypted repository for long-term storage of sensitive media, documents, audio, and sealed chat transcripts. Unlike standard galleries, the Vault operates strictly within the "Ghost Protocol" parameters. StateZer0 führt den Sovereign Vault ein, ein lokales, verschlüsseltes Repository für die langfristige Speicherung sensibler Medien und Texte. Im Gegensatz zu Standardgalerien arbeitet der Vault streng innerhalb der „Ghost-Protokoll"-Parameter.

• Proprietary .ghost Envelopes: Assets are exported as encrypted blobs. These files are indexed via deterministic SHA-256 hashes; decryption keys are stored in the local SQLCipher database and are never sent to the server. Proprietäre .ghost-Envelopes: Assets werden als verschlüsselte Blobs exportiert. Diese Dateien werden über deterministische SHA-256-Hashes indiziert.
• Metadata Sanitization (v25.1.0): EXIF and other metadata (GPS coordinates, device make/model tags, capture timestamps) are stripped before encryption. Metadaten-Bereinigung (v25.1.0): EXIF- und andere Metadaten werden vor der Verschlüsselung entfernt.
• Memory-Only Decryption: Vault assets are decrypted into memory for viewing. No unencrypted persistent copy is kept; temporary cache files are cleared and overwritten as a best-effort measure. Speicherbasierte Entschlüsselung: Vault-Assets werden für die Anzeige in den Speicher entschlüsselt. Es wird keine unverschlüsselte persistente Kopie angelegt.

7.2 Ephemeral Symmetric Media Keys7.2 Ephemere symmetrische Media-Keys

High-overhead attachments (videos, images, documents) are encrypted using a Hybrid Blob Architecture: Attachments mit hohem Overhead (Videos, Bilder, Dokumente) werden mittels einer Hybrid-Blob-Architektur verschlüsselt:

1. The client generates a unique 256-bit AES symmetric key for the specific file.Der Client generiert einen eindeutigen symmetrischen 256-Bit AES-Schlüssel für die spezifische Datei.
2. The file is encrypted locally.Die Datei wird lokal verschlüsselt.
3. The encrypted binary is uploaded to Cloudflare R2 object storage.Das verschlüsselte Binary wird zu Cloudflare R2 Object Storage hochgeladen.
4. The symmetric key and URL are sealed inside the Olm E2EE envelope and sent to the recipient.Der symmetrische Schlüssel und die URL werden im Olm-E2EE-Umschlag versiegelt und an den Empfänger gesendet.

VIII. Infrastructure, Scalability, & Retention TTLVIII. Infrastruktur, Skalierbarkeit & Aufbewahrungs-TTL

8.1 Retention & Time-to-Live (TTL)8.1 Aufbewahrung & Time-to-Live (TTL)

StateZer0 applies strict retention rules on the relay: acknowledged text messages are purged immediately (0s) from MongoDB; acknowledged media attachments are purged from Cloudflare R2 within 5 minutes of acknowledgment. Undelivered messages and offline media files expire after a maximum 24-hour window (backed by Cloudflare R2 Lifecycle Rules and MongoDB native TTL indices). Local chat history remains on the user's device until deleted by the user or by a wipe. StateZer0 wendet folgende Aufbewahrungsregeln auf dem Relay an: Bestätigte Textnachrichten werden sofort (0s) aus MongoDB gelöscht; bestätigte Medienanhänge werden innerhalb von 5 Minuten nach Bestätigung aus Cloudflare R2 gelöscht. Unzugestellte Nachrichten und Offline-Medien verbleiben maximal 24 Stunden (abgesichert durch Cloudflare R2 Lifecycle-Regeln und MongoDB-TTL-Indizes).

8.2 Universal I18N & UX Standards (v25.4.0)8.2 Universelle I18N & UX-Standards (v25.4.0)

StateZer0 implements a 21-language localization framework using the Android Resources system. No hardcoded strings; all UI text is managed via the Resources system. StateZer0 implementiert ein 21-Sprachen-Lokalisierungs-Framework über das Android-Ressourcensystem. Keine hartcodierten Strings; alle UI-Texte werden über das Ressourcensystem verwaltet.

IX. Compliance & Audit StatusIX. Compliance- und Audit-Status

Data Minimization Audit (v82.2.0)Datenminimierungs-Audit (v82.2.0)

StateZer0 has been architected to minimize server-side data retention. A comprehensive audit has confirmed: StateZer0 wurde als Architektur entwickelt, um die serverseitige Datenspeicherung zu minimieren. Ein umfassendes Audit hat Bestätigt:

• ✓ All user message and attachment content is encrypted end-to-end and unreadable by the relay✓ Alle Benutzer-Nachrichten- und Anhangs-Inhalte sind Ende-zu-Ende-verschlüsselt und für das Relay unleserlich
• ✓ Metadata (timestamps, routing IDs, delivery state) is minimized to the minimum necessary for routing✓ Metadaten werden auf das Mindestnotwendige für das Routing minimiert
• ✓ Acknowledged text messages are purged immediately (0s); acknowledged media files are purged from R2 within 5 minutes✓ Bestätigte Textnachrichten werden sofort (0s) gelöscht; bestätigte Mediendateien werden innerhalb von 5 Minuten aus R2 gelöscht
• ✓ Undelivered offline media files and orphan upload URLs are auto-deleted after 24 hours max✓ Unzugestellte Offline-Mediendateien und verwaiste Upload-URLs werden nach maximal 24 Stunden automatisch gelöscht
• ✓ Local data cleanup runs daily, deleting temporary files and cached data older than 7 days✓ Die Benutzer-lokale Datenbereinigung läuft täglich und löscht temporäre Dateien und gecachte Daten älter als 7 Tage
• ✓ No social graphs, public directories, or behavioral analytics are maintained✓ Keine sozialen Graphen, öffentliche Verzeichnisse oder Verhaltensanalysen werden gepflegt

Regulatory Compliance (GDPR, DSA, TDDDG)Einhaltung von Vorschriften (GDPR, DSA, TDDDG)

StateZer0 is operated in compliance with the following regulations: StateZer0 wird in Einhaltung der folgenden Vorschriften betrieben:

• General Data Protection Regulation (GDPR, EU 2016/679):Datenschutz-Grundverordnung (GDPR, EU 2016/679): User data is processed only on legal bases specified in Art. 6. Data subject rights under Art. 15-21 are honored. The service is designed to minimize data retention and enable account deletion on request (Art. 17). Benutzerdaten werden nur auf Rechtsgrundlagen verarbeitet, die in Art. 6 festgelegt sind. Betroffenenrechte unter Art. 15-21 werden beachtet.
• Digital Services Act (DSA, EU 2022/2065):Digital Services Act (DSA, EU 2022/2065): StateZer0 maintains a single point of contact for authorities, publishes transparency reports, and responds to illegal content reports within the limits of end-to-end encryption. StateZer0 unterhält eine Einzelkontaktstelle für Behörden und veröffentlicht Transparenzberichte.
• Telecommunications Act (TDDDG) & German Privacy Law:Telekommunikationsgesetz (TDDDG) & deutsches Datenschutzrecht: All user telecommunications are encrypted end-to-end. Data minimization principles are implemented throughout the architecture. Alle Benutzer-Telekommunikationen sind Ende-zu-Ende-verschlüsselt. Datenminimierungsgrundsätze sind in der gesamten Architektur implementiert.