So funktioniert die Verschlüsselung

Der Messenger liefert den Container

Secure Chat arbeitet unabhängig von Telegram, E-Mail und anderen Übertragungswegen. Auf dem Gerät des Absenders wird Text oder eine Datei in einen verschlüsselten Container umgewandelt. Dieser Container wird über den gewählten Kanal übertragen und vom Empfänger lokal mit seinem privaten Schlüssel entschlüsselt.

1. Die Beteiligten erstellen eigene Profile und tauschen öffentliche Schlüsselkarten aus.
2. Sie vergleichen unabhängig die vollständigen Schlüsselfingerabdrücke und bestätigen den Kontakt in der Anwendung.
3. Der Absender wählt sein Profil, den Empfänger und den Algorithmus. Secure Chat verschlüsselt den Inhalt und signiert den Container.
4. Der Empfänger öffnet den Container, gibt gegebenenfalls das Tresorpasswort ein und erhält das überprüfte Ergebnis.

Der Zugriff auf den Messengerverlauf allein verschafft keinen privaten Secure-Chat-Schlüssel. Diese zusätzliche Schutzschicht hilft bei den Inhalten, die Sie vorher verschlüsselt haben. Sie verbirgt weder die Kommunikation selbst noch Beteiligte, Übertragungszeit oder Netzwerkadressen und schützt kein bereits mit Schadsoftware infiziertes Gerät.

Zwei Schlüsselpaare pro Profil

Die öffentliche Karte .scpub enthält den Namen, beide öffentlichen Schlüssel, den Fingerabdruck und die Formatversion. Private Schlüssel sind nicht enthalten. Das Kartenformat ist lesbares JSON; Binärfelder werden in Base64 gespeichert.

Format: SecureChat.PublicKey
Version: 1
Name
EncryptionPublicKey
SigningPublicKey
Fingerprint

So wird das Gegenüber geprüft

Der Fingerabdruck fasst beide öffentlichen Schlüssel zu einem SHA-256-Hash mit 64 Hexadezimalzeichen zusammen. Vergleichen Sie ihn vor dem Versand vollständig bei einem persönlichen Treffen oder über einen anderen vertrauenswürdigen Kanal. Der Name einer importierten Karte ist kein Identitätsnachweis.

SHA256(
  UTF8("SecureChat.Identity.v1\0")
  || int32BE(length(RSA_SPKI)) || RSA_SPKI
  || int32BE(length(ECDSA_SPKI)) || ECDSA_SPKI
)

Ein importierter Kontakt gilt zunächst immer als ungeprüft. Die Anwendung erlaubt die Verschlüsselung für diesen Kontakt erst nach Bestätigung des Fingerabdruckvergleichs. Eigene Profile können zum Testen der Anwendung als Empfänger gewählt werden.

Eine gültige digitale Signatur bestätigt die Übereinstimmung des Containers mit dem Signaturschlüssel. Die Verbindung dieses Schlüssels mit einer Person wird durch den verglichenen Fingerabdruck hergestellt. Bei unbekannten oder ungeprüften Schlüsseln zeigt die Anwendung gesondert an, dass die Identität des Absenders nicht bestätigt ist.

Ein eigener Zufallsschlüssel für jeden Container

Jede neue Nachricht und jede Datei erhalten einen neuen zufälligen 256-Bit-Schlüssel über RandomNumberGenerator.GetBytes . Sie wählen einen von zwei Modi für authentifizierte Verschlüsselung, AEAD:

ChaCha20-Poly1305 wird nur angeboten, wenn das Betriebssystem es unterstützt. Der gewählte Algorithmus ist Bestandteil des authentifizierten Headers; es gibt keinen automatischen Wechsel auf eine schwächere Variante.

Der zufällige Inhaltsschlüssel wird mit dem öffentlichen RSA-Schlüssel des Empfängers verschlüsselt. Eine separate Kopie wird mit dem öffentlichen RSA-Schlüssel des Absenders verschlüsselt, damit auch dieser seine ausgehende Nachricht öffnen kann. Beim Versand an sich selbst entsteht nur ein solcher Slot.

AEAD prüft die Integrität des Inhalts und der zugehörigen Daten. Die Signatur ECDSA-P256/SHA-256 verknüpft den Container zusätzlich mit dem Schlüssel des Absenders. Schlägt eine Prüfung fehl, wird die Entschlüsselung abgebrochen.

Passwortgeschützter Tresor

Profile mit privaten Schlüsseln, Kontakte, geschützte Einstellungen und Verlauf befinden sich in einer Datei Data/wallet.scvault neben der Anwendung. Der Tresor wird mit AES-256-GCM verschlüsselt.

Das Passwort und ein separater Passwort-Prüfhash werden nicht gespeichert. PBKDF2 verlangsamt Brute-Force-Angriffe, die Schutzstärke hängt aber weiterhin vom Passwort selbst ab. Für eine lange, einzigartige Passphrase eignen sich zufällige Wörter oder ein Passwortmanager.

Auch der 64 Byte lange Header wird authentifiziert. Danach folgen Chiffretext und Tag:

"SCVAULT1"[8]
|| version:int32LE
|| iterations:int32LE
|| salt[32]
|| nonce[12]
|| ciphertext_length:int32LE
|| ciphertext
|| tag[16]

Das Format Version 1 akzeptiert ausschließlich die festgelegten KDF-Parameter, eine begrenzte Größe und die genaue Dateilänge. Zum Speichern wird eine vollständig vorbereitete verschlüsselte Kopie geschrieben und die Datei ersetzt. Gleichzeitiges Schreiben und das Überschreiben erkannter externer Änderungen werden abgelehnt. Die Hilfsdatei .lock enthält keine Schlüssel.

Was im unverschlüsselten Header steht

Ein Nachrichten- oder Dateicontainer beginnt mit vier Typ-Bytes, der Länge des JSON-Headers und dem Header selbst. Der JSON-Inhalt ist auf 16.384 Byte begrenzt.

magic[4] || header_length:int32LE || header_json[header_length]

Diese Metadaten sind nicht verschlüsselt. Algorithmus, Größe, Dateiname, öffentliche Schlüssel und Fingerabdrücke sind sichtbar. Dauerhafte Schlüssel ermöglichen es, Container desselben Absenders einander zuzuordnen. Ist der Dateiname vertraulich, benennen Sie die Datei vor dem Verschlüsseln um.

Der unverschlüsselte Header ist gegen unbemerkte Änderungen geschützt: Signatur und AEAD verwenden seine ursprünglichen Bytes und kein neu zusammengestelltes JSON. In der folgenden Beschreibung bedeutet || die Verkettung von Bytes. Ganzzahlen werden in Little-Endian gespeichert; Big-Endian-Ausnahmen sind ausdrücklich gekennzeichnet.

Text: SC1-Container und .scmsg-Anhang

Der ursprüngliche Text ist auf 1 MiB in striktem UTF-8 begrenzt. Der Binärcontainer hat den Typ SCT1 :

"SCT1"
|| header_length:int32LE || header_json
|| ciphertext_length:int32LE || ciphertext
|| tag[16] || signature[64]

Als zusätzliche authentifizierte Daten (AAD) dient das gesamte Präfix: Typ, Länge und JSON des Headers. Die ECDSA-P256-Signatur wird über den SHA-256-Hash aller vorangehenden Bytes berechnet. Das Signaturformat ist IeeeP1363FixedFieldConcatenation : r || s , jeweils 32 Byte.

Zur Übertragung wird der Binärcontainer in Base64url ohne Füllzeichen umgewandelt = :

SC1:<base64url(binary_container)>
securechat://message/<base64url(binary_container)>

Vor der Ausgabe des Textes prüft die Anwendung Struktur, exakte Länge und Signatur, entschlüsselt anschließend die RSA-Schlüsselhülle und prüft AEAD. Ungültige Zeichen, Zeilenumbrüche innerhalb des Umschlags, zusätzliche URI-Parameter und beschädigte Daten werden abgelehnt.

Übertragung über Telegram

Die Schaltfläche „Datei für den Chat“ kopiert die verschlüsselte .scmsg in die Datei-Zwischenablage von Windows. Fügen Sie sie im Chat ein mit Ctrl + V und senden Sie den Anhang. Der Empfänger lädt die Datei herunter und öffnet sie in Secure Chat. Eine gesperrte Anwendung fragt zuerst nach dem Passwort.

Den normalen Umschlag SC1:… können Sie ebenfalls manuell kopieren und einfügen. Der Windows-Link securechat://… ist auf 8.000 Zeichen begrenzt und nicht in allen Clients anklickbar. Telegram Desktop verwandelt dieses frei definierte Schema nicht in einen normalen automatischen Link; dafür ist der Anhang .scmsg vorgesehen. Ältere .sct werden ausdrücklich in der Anwendung geöffnet.

Dateien: Blöcke, Signatur und zwei Prüfdurchläufe

Eine verschlüsselte Datei erhält die Endung .scx und den Typ SCF1 . Das Format erlaubt ursprüngliche Dateien bis 1 TiB. Die Verarbeitung erfolgt als Stream: Die Datei wird nicht vollständig in den Arbeitsspeicher geladen, sondern in Blöcke von 1 MiB aufgeteilt.

"SCF1" || header_length:int32LE || header_json
|| (chunk_length:int32LE || ciphertext[chunk_length] || tag[16])*
|| 0:int32LE || terminal_tag[16]
|| signature[64]

Für jeden Block wird eine eigene 12-Byte-Nonce gebildet. Sie setzt sich aus dem zufälligen 4-Byte-Präfix des Containers und dem 8-Byte-Blockindex zusammen:

nonce = Nonce[4] || uint64BE(chunk_index)
AAD   = SHA256(full_prefix)[32]
        || uint64BE(chunk_index)
        || int32LE(chunk_length)

Der Index beginnt bei null. Der leere Abschlussblock erhält den nächsten Index und einen eigenen Tag. Selbst eine leere Datei enthält Header, Abschlussblock, Tag und Signatur. Für jede neue Datei wird ein neuer Inhaltsschlüssel erzeugt.

Die Signatur umfasst alle Bytes von SCF1 bis einschließlich zum abschließenden AEAD-Tag. Blockreihenfolge und -größe, die genaue Containerlänge und das Dateiende werden geprüft. Umordnen, Duplizieren oder Entfernen von Blöcken, Abschneiden und Anhängen führen zur Ablehnung.

So läuft die Entschlüsselung ab

1. Der größenbegrenzte Header, die Dateilänge und das Vorhandensein eines passenden privaten Schlüssels werden geprüft.
2. Der erste Durchlauf liest den Container und prüft die vollständige Signatur. Eine temporäre Klartextdatei wird noch nicht angelegt.
3. Der zweite Durchlauf prüft AEAD für jeden Block, schreibt die entschlüsselten Daten in eine temporäre Datei und prüft die Gesamtsignatur erneut.
4. Nach erfolgreichem Abschluss wird das Ergebnis in eine vom Nutzer gewählte neue Datei umbenannt. Eine bereits vorhandene Datei wird nicht überschrieben.

Die Statusanzeige zeigt den Gesamtfortschritt einschließlich Signaturprüfung, Entschlüsselung und Speichern. 100 % bedeutet, dass das Ergebnis erfolgreich gespeichert wurde. Während der Verarbeitung können Sie abbrechen; bei einem regulären Fehler oder Abbruch wird die temporäre Datei entfernt.

Die Quelldatei bleibt erhalten. Das entschlüsselte Ergebnis wird nicht automatisch ausgeführt. Stromausfall, erzwungenes Prozessende oder ein fremdes Handle, das die Löschung verhindert, können eine temporäre Klartextdatei zurücklassen. Der Schutz von Zielordner und Datenträger bleibt ein wichtiger Teil des Umgangs mit Geheimnissen.

Lokale Speicherung, Verlauf und Sperre

Der Verlauf enthält Vorgangsmetadaten und verschlüsselte Textumschläge. Klartext und Dateiinhalte werden nicht darin gespeichert. Die letzten 100 Einträge mit insgesamt etwa 8 MiB Umschlagdaten bleiben erhalten; ältere Einträge werden automatisch entfernt. Sie können den Verlauf deaktivieren oder leeren.

Der Tresor wird gesperrt mit Ctrl + L , beim Minimieren, Sperren oder Trennen der Windows-Sitzung, beim Wechsel in den Ruhezustand und bei Inaktivität. Das Inaktivitätsintervall liegt zwischen 1 und 15 Minuten, standardmäßig 5 Minuten. Ein laufender Dateivorgang wird vor dem Freigeben der Schlüssel abgebrochen.

Beim Sperren werden Eingabefelder und Verweise auf Einträge geleert; anwendungseigene Arrays mit privaten Schlüsseln und dem abgeleiteten Schlüssel werden mit Nullen überschrieben. Eine vollständige Entfernung aller Kopien aus dem Speicher ist nicht garantiert: Verwaltete Zeichenfolgen, Zwischenablage, Speicherabbilder und Auslagerungsdatei können Datenreste enthalten.

Zwei unterschiedliche Zwischenablage-Modi

„Text kopieren“ kennzeichnet den eigenen Zwischenablageeintrag und löscht ihn nach 30 Sekunden oder beim Sperren, sofern er noch Secure Chat gehört. Ein neuerer Eintrag einer anderen Anwendung wird nicht gelöscht. Gewöhnliches Kopieren mit dem Systembefehl Ctrl + C unterliegt diesem Timer nicht.

„Datei für den Chat“ legt in Windows FileDrop den Pfad zur fertigen .scmsg ab, die nur Chiffretext enthält. Diese Kopie bleibt nach dem Sperren und Schließen des Tresors verfügbar, damit der Messenger sie lesen kann. Jeder Kopiervorgang erstellt einen eigenen Anhang.

Kopien, die älter als 24 Stunden sind, werden beim nächsten Start oder Kopieren entfernt. Es werden höchstens 128 temporäre Anhänge gleichzeitig gespeichert; am Limit können Sie die Nachricht ausdrücklich in einem gewählten Ordner speichern. Verbote für Verlauf und Cloud-Zwischenablage werden als Hinweise an Windows übergeben; fremde Zwischenablage-Manager können sie ignorieren.

Sicherungskopien, Umzug und Updates

Eine Sicherungskopie ist der vollständige verschlüsselte Tresor. Zum Öffnen benötigen Sie das zum Erstellungszeitpunkt gültige Passwort. Aktualisieren Sie die Sicherung nach dem Hinzufügen neuer Schlüssel. Eine Wiederherstellung ohne Passwort und private Schlüssel ist nicht vorgesehen.

Passwortänderungen, das Löschen eines Profils und das Leeren des Verlaufs verändern den aktuellen Tresor. Alte Sicherungen behalten das frühere Passwort, die früheren Schlüssel und den Verlauf. Das Löschen eines Eintrags garantiert außerdem keine physische Löschung von SSDs, aus Snapshots oder einem Journaling-Dateisystem.

Zum Aktualisieren auf 0.1.6 schließen Sie Secure Chat und ersetzen SecureChat.exe im bisherigen Ordner. Behalten Sie den gesamten Ordner Data bei. Tresor- und Containerformate bleiben auf Version 1; eine Migration ist nicht erforderlich. Für künftige Versionen mit Formatänderungen wird das Migrationsverfahren gesondert beschrieben.

Beim Umzug in einen anderen Ordner verschieben Sie die EXE zusammen mit Data und den benötigten externen Übersetzungen in Languages . Aktivieren Sie danach die Verarbeitung von .scmsg , .scx und Links erneut in den Einstellungen: Die Windows-Registrierung speichert den absoluten Pfad. Eine Einzeldatei-EXE kann native .NET-Bibliotheken in den Systemcache des Nutzers entpacken.

Welche Netzwerkanfragen die Anwendung stellt

Für Ver- und Entschlüsselung ist kein Server erforderlich. Secure Chat hat weder einen Nachrichtentransport noch ein Konto zum Schlüsselaustausch oder einen Dienst zum Zurücksetzen des Passworts. Die Zustellung der Container übernimmt Ihr gewählter Messenger, E-Mail oder ein anderer Kanal.

Über „Nach Updates suchen“ ruft die Anwendung ein kleines JSON-Dokument ab von https://itmsft.com/securechat/update/latest.json . Die Prüfung beim Start kann gesondert aktiviert werden und ist standardmäßig ausgeschaltet. Übertragen werden die üblichen Netzwerkdaten einer HTTPS-Anfrage und ein allgemeiner User-Agent mit der Programmversion. Passwort, Schlüssel, Profile, Verlauf und Dateiinhalte sind nicht Teil der Anfrage.

Der Client begrenzt die Antwort auf 64 KiB und die Lesezeit auf 10 Sekunden. Er prüft die Version und das Vorhandensein eines Pakets für seine Architektur. Bei Server-, Netzwerk- oder Formatfehlern meldet er, dass die Prüfung nicht möglich ist, und erklärt die installierte Version nicht für aktuell.

Die Download-Schaltfläche öffnet die zugelassene HTTPS-Paketadresse auf itmsft.com im normalen Browser. Die Anwendung installiert nichts automatisch und führt die heruntergeladene Datei nicht aus. Das Format des SHA-256-Felds wird geprüft, die Bytes des vom Browser heruntergeladenen ZIP-Archivs jedoch nicht. In Version 0.1.6 besitzt die EXE keine digitale Herausgebersignatur.

Wichtige Grenzen

• Gerätesicherheit. Schadsoftware, Keylogger, das Auslesen des Speichers, der Austausch der EXE oder Fernzugriff können den Text vor der Verschlüsselung und nach der Entschlüsselung offenlegen.
• Metadaten. Der unverschlüsselte Containerheader und die Netzwerkdaten des Übertragungskanals sind sichtbar. Das ist kein Werkzeug zur Anonymität.
• Statische Schlüssel. Forward Secrecy ist nicht implementiert: Mit einem gestohlenen privaten Schlüssel lassen sich zuvor abgefangene Container für diesen Schlüssel lesen.
• Wiederherstellung der Vertraulichkeit. Double Ratchet und Post-Compromise Security sind nicht vorhanden. Es handelt sich um ein eigenes Format und nicht um eine Implementierung des Signal-Protokolls.
• Wiederholung und Rollback. Ein gültiger Container kann erneut versendet werden. Eine gültige alte Tresorkopie ist nicht gegen Rollback geschützt: Integrität beweist nicht Aktualität.
• Passwort. Mindestlänge und Wartezeiten in der Oberfläche verhindern keine Offline-Angriffe auf einen gestohlenen Tresor. Entscheidend sind ein starkes Passwort und die KDF.
• Datenlöschung. Eine vollständige Löschung aus RAM, Auslagerung, Cloud-Zwischenablage und Datenträger wird nicht garantiert.
• Kryptografische Eigenschaften. Das Verfahren ist nicht postquantenfest. Dritte, die den Container erhalten, können die Signatur prüfen; kryptografische Abstreitbarkeit wird nicht geboten.
• Prüfstatus. Standardprimitive und automatische Tests ersetzen kein unabhängiges Audit von Protokoll und Implementierung.

Secure Chat gibt Ihnen zusätzliche Kontrolle über ausgewählte Inhalte. Der Einsatz für besonders sensible Daten erfordert die Bewertung Ihres Bedrohungsmodells, ein geschütztes Gerät und eine unabhängige fachkundige Prüfung der Implementierung.

Zugang zum Quellcode anfragen →