Secure Chat

Warum so gebaut

Vier Modi für den Live-Raum

Alle Modi außer One-Time-Pad nutzen dieselbe Ratsche: zwei HMAC-SHA-256-Ketten, ein frischer AES-256-GCM-Schlüssel pro Nachricht, der nach Gebrauch gelöscht wird. Sie unterscheiden sich nur darin, woher das Startgeheimnis kommt.

• DHKE

  Empfohlen / Standard

  Flüchtiges ECDH P-256, Nachrichten mit geratschtem AES-256-GCM.

  Identitätsauthentifiziert, Forward Secrecy.

• Post-Quanten

  ML-KEM-768

  Hybrid aus ECDH P-256 und ML-KEM-768, über HKDF zusammengeführt.

  Ein Angreifer muss beides brechen. Das schützt gegen „heute mitschneiden, später entschlüsseln“.

• AES-256

  Gemeinsame Passphrase

  PBKDF2 mit 600.000 Runden aus einer gemeinsamen Passphrase plus frischer Nonce von beiden Seiten.

  Kein Schlüsselaustausch, also kann sich das Relais nicht dazwischenschalten. Dafür keine Forward Secrecy über Sitzungen hinweg: Wer die Passphrase kennt und mitgeschnitten hat, liest alles.

• One-Time-Pad

  Persönlich übergeben

  XOR mit einem vorab geteilten Pad, dazu ein einmaliges HMAC-SHA-256-Tag. Das Pad reist per Bluetooth, USB, QR oder NFC, verschlüsselt mit Passphrase.

  Informationstheoretisch vertraulich. Das Integritäts-Tag ist rechnerisch, nicht informationstheoretisch.

RSA-OAEP-2048 wurde entfernt statt geflickt: Die Seite, die ihren RSA-Schlüssel anbot, hätte allein über die Geheimhaltung der Sitzung entschieden, und ein absichtlich schwacher Modulus besteht jede Prüfung, die sich ein Client leisten kann.

Wer da wirklich spricht

Was das Relais sieht

So geht’s

1. 01

   Öffne den Web-Client oder die Onion-Adresse im Tor Browser. Lege mit „Create identity“ eine Identität mit Passphrase an. Für DHKE und Post-Quanten brauchst du eine.

2. 02

   Ein Chat-Code entsteht automatisch. Teile ihn über einen Kanal, dem du vertraust: als Text, Einladungslink oder QR-Code.

3. 03

   Beide wählen unter „Security options“ denselben Modus. DHKE ist der empfohlene Standard.

4. 04

   Wer den Code erzeugt hat, drückt zuerst „Connect“ und wird Besitzer. Die andere Person fügt den Code ein und verbindet sich.

5. 05

   Der Besitzer sieht den Fingerabdruck der anklopfenden Person und lässt sie herein. Im DHKE- und Post-Quanten-Modus bestätigt der Gast ebenfalls.

6. 06

   Vergleicht die Sicherheitsnummer persönlich. Nur bei Übereinstimmung „It matches“ drücken, sonst trennen.

7. 07

   Schreibt. Für jedes Gespräch ein neuer Code, am Ende „Disconnect“.

Für dauerhafte 1:1-Chats registrierst du dich im Verzeichnis, teilst dein Handle im Format username#token und legst mit „New chat“ los. Die Post liegt als versiegelter Umschlag im Briefkasten und wird beim Abholen gelöscht.

Überall derselbe Client

Nur die Apps schließen die Lücke, dass ein kompromittierter Server dem Browser manipuliertes JavaScript ausliefern könnte. Der Web-Client schützt gegen ein passiv mitlesendes Relais.

Geprüft, immer wieder

Seit Juli 2026 läuft nach jeder größeren Änderung ein KI-gestütztes Red-Team-Review mit nachgestellten Angriffen. Die Berichte liegen vollständig im Repository.

• 18. Jul 2026

  Sicherheitsaudit. Ein Fund hoch, drei mittel, drei niedrig. Alles behoben.

• 25.–29. Jul

  Vier Pentest-Runden, darunter Two-Time-Pad im OTP-Modus und der Start des Onion-Dienstes. Alle hohen Funde innerhalb eines Tages geschlossen.

• 7. Aug

  Multi-Agenten-Red-Team. Nichts Kritisches, nichts Hohes. 47 Funde: 14 mittel, 18 niedrig, 15 Hinweise.

• 30. Sep

  Gegen v0.5.0: nichts Kritisches, nichts Hohes. 19 Funde: 6 mittel, 4 niedrig, 9 Hinweise. Die mittleren sind offen und warten auf Entscheidung.

Was es nicht ist

• Kein Gruppenchat. Zwei Personen pro Raum, nur druckbares ASCII.
• Keine Anonymität des Servers. Das Onion verbirgt nicht, wo die Maschine steht.
• Kein Metadatenschutz. Zeitpunkte, Größen und Nachschlagevorgänge sind sichtbar.
• Keine Offline-Funktion und kein Service Worker.
• Schwache Passphrasen werden angemahnt, nicht abgelehnt.
• Keine Open-Source-Lizenz. Der Code ist einsehbar, aber nicht freigegeben.