Sicherheit bei LangReply

Was wir verschlüsseln, was wir vernichten und was wir ehrlicherweise nicht garantieren können. Ohne Marketing-Jargon geschrieben.

1. Verschlüsselung im Ruhezustand

Sensible Daten (Benutzerkonten, Übersetzungsverläufe, OTT-Nachrichten, Einstellungen) werden im Ruhezustand mit AES-256-GCM verschlüsselt. Der Hauptschlüssel liegt außerhalb des Git-Repositorys, auf einem Volume mit eingeschränktem Zugriff (Berechtigungen 600, dedizierter Eigentümer).

Jeder sensible Datensatz führt seinen eigenen IV (96-Bit-Zufalls-Nonce) und sein GCM-Authentifizierungs-Tag mit. Eine Manipulation des Chiffretexts wird beim Entschlüsseln erkannt (kryptografischer Fehlschlag, keine stille Korruption).

Dokumentierte Ausnahme: Die Datei languages.json (die öffentliche Liste der unterstützten Sprachen) ist ausdrücklich von der Verschlüsselung ausgenommen — sie ist ein öffentlicher Katalog, keine personenbezogene Angabe.

2. Unumkehrbares Löschen (Crypto-Shredding)

Prinzip

Jede OTT-Konversation, jedes Bündel sensibler Nachrichten und jedes Benutzerkonto besitzt einen eigenen DEK (Data Encryption Key) — einen einmaligen, zufällig erzeugten AES-256-Schlüssel. Die Daten werden mit diesem DEK verschlüsselt; der DEK selbst wird mit dem Hauptschlüssel (KEK) verschlüsselt.

Um Daten unumkehrbar zu löschen, vernichten wir den DEK. Die verschlüsselten Bytes können in der Datenbank oder auf der Platte verbleiben: ohne den Schlüssel sind sie von Zufallsrauschen nicht zu unterscheiden.

Mathematische Garantie

Ein AES-256-DEK hat einen Schlüsselraum von 2256 möglichen Werten — etwa 1,16 × 1077. Einen vernichteten Schlüssel per Brute Force zu rekonstruieren ist nach dem öffentlich bekannten Stand der Kryptografie und der verfügbaren Rechenleistung (einschließlich projizierter Post-Quanten-Angriffe mit Grover, die auf 2128 reduzieren) nicht durchführbar.

Was tatsächlich vernichtet wird

  • Der DEK im RAM (sofortige Nullsetzung).
  • Der verschlüsselte DEK in der Datenbank (UPDATE ... SET encrypted_dek = NULL + Postgres-VACUUM, wo anwendbar).
  • Die Kopien im Anwendungs-Cache.

3. Automatisch verschwindende Nachrichten

Für jede OTT-Konversation lässt sich eine Auto-Löschfrist aktivieren: Danach werden die Nachrichten durch Crypto-Shredding ihres Konversations-DEK vernichtet.

Konfigurierbare Dauern

Ohne Einstellung gilt keine Standarddauer: Nachrichten bleiben bis zur manuellen Löschung erhalten.

Die Frist beginnt, sobald die Nachricht vom Empfänger gelesen wurde (Standard) oder sobald sie gesendet wurde (Option). Ein Server-Sweeper läuft alle 10 Minuten und löscht, was abgelaufen ist.

Eine Änderung der Frist ist in der Konversation sichtbar (Systemnachricht mit Zeitstempel). Weder Absender noch Empfänger können eine bereits abgelaufene Nachricht „verlängern“ — der Schlüssel ist vernichtet.

4. Radikale Kontobereinigung

Im Nutzerportal löst die Schaltfläche „Alle meine Nachrichten vernichten“ die sofortige Vernichtung sämtlicher mit Ihrem Konto verknüpfter DEKs aus: OTT-Konversationen, Übersetzungsverlauf, Entwürfe, verschlüsselte Anhänge.

Der Vorgang ist:

Eine Kontobereinigung löscht nicht das Konto selbst (Kennung, E-Mail, Abrechnungseinstellungen): Dafür nutzen Sie die vollständige Kontolöschung, die getrennt davon erfolgt.

5. Isolation pro Konto

Jedes Konto hat seinen eigenen DEK. Die Kompromittierung eines DEK legt nur die Daten dieses Kontos offen, nicht die anderer. Der Hauptschlüssel (KEK) wird benötigt, um DEKs zu entschlüsseln, reicht aber allein nicht aus, um ein Konto zu lesen, dessen DEK nicht mehr in der Datenbank liegt.

API-Anfragen sind über account_id eingegrenzt. Keine Route nimmt eine Konto-ID als freien Parameter entgegen, ohne die Zugehörigkeit der Sitzung zu prüfen.

6. Selbstgehostete Übersetzungs-Engine

Die primäre Übersetzung nutzt NLLB-200 1.3B (202 Sprachen) auf unserem eigenen Server, in einem internen Microservice, der nicht im Internet exponiert ist. Für die Übersetzung verlässt der Inhalt unsere Infrastruktur nicht.

Ausweichlösung: Bei Nichtverfügbarkeit kann ein automatischer Fallback ausschließlich Claude (Anthropic) aufrufen. Dieser Fallback lässt sich pro Konto für sensible Anwendungsfälle deaktivieren; wird er ausgelöst, wird der Inhalt an Anthropic übermittelt, und wir weisen in der API-Antwort darauf hin.

Der MyMemory-Fallback wurde am 28. Juli 2026 entfernt: Er übertrug den Inhalt im Klartext in der URL, ohne Auftragsverarbeitungsvertrag. Eine dritte Rückfallebene gibt es nicht: Ist keine Engine verfügbar, schlägt die Übersetzung fehl, statt an einen nicht vertraglich gebundenen Dritten übergeben zu werden.

7. Authentifizierung

Passwörter werden mit scrypt gehasht (N=16384, r=8, p=1). Sitzungen über ein HMAC-signiertes HttpOnly-Cookie. 2FA verfügbar: TOTP (Google Authenticator, Aegis, 1Password) und SMS-OTP (Twilio, Nachrichten in der Sprache des Empfängers).

Ratenbegrenzung an den Authentifizierungs-Endpunkten (429 nach wiederholten Versuchen). Kein Passwort wird per E-Mail versendet; Zurücksetzungen erfolgen über einen Einmal-Link.

8. Backups

Täglich verschlüsselte Backups des Datenvolumes. Aufbewahrung: rollierend 14 Tage, danach Löschung.

Eine verschlüsselte Off-Site-Kopie (AES-256) wird bei GitHub und Backblaze (USA) aufbewahrt. OTT-/SMS-Nachrichten und deren Schlüssel sind davon ausgenommen und verlassen die Europäische Union nie.

9. Ihre Rechte (DSGVO / Gesetz 25 / CCPA)

Recht auf Auskunft, Berichtigung, Löschung, Datenübertragbarkeit und Widerspruch. Anfragen per E-Mail an privacy@langreply.com werden innerhalb von 30 Tagen bearbeitet. Die Löschung nutzt das oben beschriebene Crypto-Shredding.

10. Zertifizierungen — ehrlich

Wir sind heute nicht nach SOC 2, ISO 27001 oder HIPAA zertifiziert. Wir werden nichts anderes behaupten, solange es nicht stimmt. Die hier beschriebenen Maßnahmen sind tatsächlich umgesetzt; die entsprechenden externen Audits noch nicht.

11. Was wir ehrlicherweise nicht garantieren

Wir sagen lieber die Wahrheit, als eine Illusion zu verkaufen. Das leistet Crypto-Shredding nicht:

  • Backups: Unsere Backups schließen die Nachrichten- und Schlüsseltabellen aus — eine Wiederherstellung kann eine vernichtete Nachricht nicht erneut offenlegen. Der bewusst in Kauf genommene Preis: Geht die Datenbank verloren, ist der OTT-/SMS-Verlauf nicht wiederherstellbar.
  • Screenshots beim Empfänger: Wenn Sie jemandem eine verschwindende Nachricht senden, kann diese Person ihren Bildschirm mit einem anderen Gerät abfotografieren. Keine Software der Welt kann das verhindern. Signal auch nicht.
  • WAL, Logs, Replikate: Postgres schreibt Transaktionsprotokolle (WAL). Ein Chiffretext-Byte kann dort gelegen haben, bevor es gelöscht wurde. Diese Protokolle rotieren, aber nicht sofort.
  • SSDs und Wear-Leveling: SSDs verteilen Schreibvorgänge physisch. Ein logisches DELETE überschreibt nicht zwingend den physischen Sektor. Genau deshalb ist Crypto-Shredding zuverlässiger als physisches Löschen — das Chiffretext-Byte kann jedoch physisch noch eine Weile bestehen bleiben. Ohne den Schlüssel bleibt es unlesbar.
  • Audit-Metadaten: Wir bewahren minimale Metadaten auf (Zeitstempel einer Bereinigung, IP) für Audit und Missbrauchsabwehr. Sie enthalten nicht den vernichteten Inhalt.
  • Ende-zu-Ende-Verschlüsselung: Das OTT-Messaging ist serverseitig im Ruhezustand verschlüsselt, aber es ist keine E2EE im Sinne von Signal (wo selbst der Server nicht mitlesen kann). LangReply ist technisch in der Lage, eine Nachricht zu entschlüsseln, solange ihr DEK existiert. Wir tun es nicht — aber wir können nicht das Gegenteil behaupten.

12. Ein Sicherheitsproblem melden

Koordinierte Offenlegung an security@langreply.com mit dem Betreff [SECURITY]. Wir bestätigen den Eingang innerhalb von 72 h und liefern je nach Schweregrad in angemessener Frist einen Fix oder eine Abmilderung. Bislang kein formelles Bug-Bounty-Programm; wir nennen Melder, die dies wünschen.

Zuletzt aktualisiert: 6. August 2026.