Warum Sie den lokalen Chiffretext nicht öffnen, nachdem der Client den Workspace verschlüsselt hochgeladen hat

Die Suchintention in einem Satz

Verschlüsselung auf dem Weg und „Sie halten den Schlüssel“ liegen nicht auf derselben Schicht. Ein Client kann auf diesem Rechner AES laufen lassen, den Workspace zu Chiffretext machen und diesen Chiffretext in den Objektspeicher schicken. Kommt der öffentliche Schlüssel, der den Inhaltsschlüssel einwickelt, vom Server, und ist der private Schlüssel nie auf diesem Computer angekommen, ist die Datei kein Backup, das Sie wiederherstellen. Sie ist ein Umschlag, den nur die Cloud öffnet. Wer die Leitung abhört, sieht keinen Klartext. Der Server, der den privaten Schlüssel hält, sieht ihn.

Diese Notiz ist für Leute, die gerade eine Meldung gelesen haben, ein Client verschlüssele den Workspace vor dem Upload, und die „Chiffretext liegt auf der Platte“ von Zero-Knowledge trennen wollen. Sie ist auch für Entwickler, die ein Repository oder einen Schlüssel an eine Kollegin geben müssen, ohne das Entschlüsselungsrecht an einen Anbieter abzugeben. Sie ersetzt keine Hersteller-Mitteilung und ist keine Deinstallationsanleitung für einen Editor. Mitnehmen sollten Sie: wer bei der Umschlagverschlüsselung den Schlüssel hält, wie weit die Klartext-Dateiliste schon reichte, was „sofort löschen“ nicht belegt, und wie Sie auf diesem Gerät prüfen, ob Sie die Datei öffnen können.

Welche Schichten die Zerlegung festgenagelt hat

Am 18. September 2026 hat ferstar die Untersuchung veröffentlicht. Der Anfang war kein Wettbewerb im Paketmitschnitt, sondern Aufräumen auf der Platte. Lokal belegte ~/.zcode mehr als 700 MB. Unter v2/checkpoints/ lag eine .enc von etwa 313 MB. Die Statusdatei daneben nannte einen Workspace von etwa 345 MB, kind war baseline, failureCount war 564. Das Repository selbst war etwa 10 GB. Nach dem Weglassen der Abhängigkeiten waren die restlichen 345 MB fast nur Kerndateien des Projekts.

Er hat den Upload in zwei Schritte zerlegt. Zuerst rief der Client auf zcode.z.ai POST /api/v1/snapshot/upload-credential auf. Der Server lieferte eine Snapshot-Nummer, eine Formularsignatur für den Objektspeicher, eine Größengrenze und einen RSA-Schlüssel für diese Runde. Danach baute der Rechner ein tar.gz, verschlüsselte es mit einem einmaligen symmetrischen Schlüssel unter AES-256-CTR, wickelte diesen Schlüssel mit RSA-OAEP-SHA256 ein und schickte tar.gz.enc als Formular-POST direkt an Alibaba Cloud OSS. Ein Speicher-Callback trug das Objekt beim Backend des Anbieters ein. Der Anwendungsserver fasste die Chiffretext-Datei nicht an. Eintragungsrecht und privater Schlüssel lagen trotzdem in der Cloud.

Der Umfang war nicht der aktuelle Arbeitsbaum. Eine lokale Klartext-Liste nannte 42.411 Dateien: .git/lfs/ etwa 196,1 MB (56,8 %), .git/objects/ etwa 102,2 MB (29,6 %), .git/logs/ etwa 0,6 MB, Quelltext und Dokumente etwa 46,2 MB (13,4 %). .git machte 86,6 % des Pakets aus. Ein erfolgreicher Upload hätte der Cloud die Commit-Historie gegeben, Geheimnisse, die aus dem Baum gelöscht waren und trotzdem im Objektspeicher lagen, Namen von Branches, die nie gepusht wurden, und Intranet-Hosts in .git/config. Eine zweite Liste über mehrere Workspaces hinweg hashte die globale Konfiguration und nahm sie mit.

Um 17:44 Uhr am 18. September schrieb der Anbieter in seiner Nutzer-Community, der Upload stamme aus einem standardmäßig eingeschalteten Code-Index für Sitzungs-Checkpoints, Versionsrücklauf und Repo Wiki, und die Daten würden gelöscht, sobald das Wiki erzeugt sei. Am 21. September berichtete die National Business Daily: ZCode kündigte Open Source an; die China Academy of Information and Communications Technology nannte den Bucket zcode-prod leer; NSFOCUS sagte, Bucket und Objekte seien gelöscht; Client v3.14.0 habe Snapshot-Erzeugung und Upload-Pfad entfernt. ferstar ergänzte die Spaltung: Die 313 MB des kommerziellen Projekts lagen über der Größengrenze, wurden 564-mal wiederholt und verließen das LAN nicht. Ein anderer Workspace, ein öffentliches Repository mit 538 Dateien, war nach Kompression und Verschlüsselung etwa 15 KB groß, der Status lautete vom Server angenommen. Ob irgendetwas diesen Rechner verlassen hat: wenigstens diese kleine Datei hat ihn verlassen.

Warum Umschlagverschlüsselung keine Datei ist, die Sie öffnen

AES-256-CTR plus RSA-OAEP ist der Lehrbuch-Umschlag. Der Inhalt wird mit einem kurzlebigen symmetrischen Schlüssel verschlüsselt. Dieser Schlüssel wird dann mit einem öffentlichen Schlüssel eingewickelt. Die Algorithmusnamen wirken hart. Wer die Datei lesen kann, hängt davon ab, woher der öffentliche Schlüssel kam und wo der private Schlüssel liegt. Die Untersuchung schreibt es fest: Der öffentliche Schlüssel wurde ausgegeben, als der Client ein Upload-Credential anfragte; der passende private Schlüssel kam nie auf diesen Computer; den Umschlag mit privaten Schlüsseln zu öffnen, die schon auf dem Rechner lagen, schlug fehl. Der Client selbst konnte den Chiffretext auf der Platte nicht öffnen.

Das ist das Gegenteil eines Backups, das Sie wiederherstellen. Time Machine, lokale Git-Objekte und eine Datei, die Sie mit einer Passphrase verschlüsseln und dann wegkopieren, lassen das Entschlüsselungsmaterial bei Ihnen: eine Passphrase, ein lokaler Schlüssel oder ein Schlüsselbund, den Sie öffnen. Hält allein der Server den privaten Schlüssel, wechselt das Ziel der Konstruktion. Eine dritte Stelle auf dem Weg soll die Bytes nicht sehen. Nach der Ankunft soll die Cloud sie öffnen können. ferstars eigener Satz nagelt den Zweck fest: Ein Schlüssel, den nur der Server benutzen kann, dient dem Server, der Ihren Code liest. Er dient nicht Ihrem Rollback.

He Yuan vom Data Law Research Center der Shanghai Jiao Tong University sagte der National Business Daily einen engeren Satz. Verschlüsselung ist eine Sicherheitsmaßnahme. Sie ist keine Anonymisierung und ersetzt weder Hinweis noch Datenminimierung. Hält der Anbieter die Fähigkeit zu entschlüsseln, lassen sich verschlüsselte Daten weiter wiederherstellen und verarbeiten. „Sofort nach der Nutzung löschen“ senkt nur die lange Aufbewahrung. Es beantwortet nicht, ob die erste Erhebung nötig war. Beide Sätze zusammen: Die Stärke des Algorithmus belegt nicht, wem der Schlüssel gehört, und eine Löscherklärung belegt nicht den Umfang der Erhebung.

Die Klartext-Liste hat den Umfang schon aufgeschrieben

Sie können den Chiffretext nicht öffnen. Der Umfang ist deshalb kein Rätsel. Die Dateiliste, die beim Packen entstand, blieb lokal, und sie war Klartext. Die 42.411 Zeilen trennen „den aktuellen Quellbaum“ vom „Leben des Repositorys“. Der aktuelle Baum war etwa 13,4 %. Der Rest war LFS-Cache, der volle Objektspeicher und das Reflog. Ein API-Schlüssel, den Sie aus dem Arbeitsbaum schon gelöscht haben, kann in .git/objects liegen, sobald er einmal committet wurde. Ein nie gepushter Branch-Name kann ein Feature verraten, das noch nicht öffentlich ist. Ein Intranet-Git-Hostname steht in .git/config. Sie müssen den Chiffretext nicht öffnen, um von der Liste her zu sehen, dass er eingepackt wurde.

Zwei Schalter auf der Oberfläche sehen aus wie Hauptschalter. Im Code waren sie es nicht. Nach dem Abgleich der Untersuchung steuerte „Erlebnis verbessern“ nur, ob Daten für Modelltraining genutzt werden dürfen, und „Repository-Snapshot-Index“ nur, ob die Cloud einen Index baut. Packen und Direktupload liefen weiter, solange das Login-JWT gültig war. Aufzeichnungspunkte lagen vor jedem Prompt und bei repo-wiki-update am Ende einer Aufgabe. Eine aktive Sitzung kam auf bis zu 62 Aufzeichnungen. Etwa eine halbe Stunde nach dem manuellen Löschen des wartenden Pakets erschien eine neue Datei von 313 MB, der Fehlerzähler ging von 564 auf 565. Eine Datei zu löschen ist kein ausgeschalteter Schalter.

Die am 18. September archivierte Datenschutzerklärung trug als letzte Aktualisierung noch 2026-06-15. Der beschriebene Erhebungsumfang war Text, Dateien und Code, die in einem Gespräch abgeschickt wurden. Sie schrieb nicht: „Nach der Anmeldung den ganzen Workspace und die Git-Historie automatisch packen.“ Die Erklärung trägt eine Aussage: Der Anbieter sagte, er erhebe, was Sie in einer Sitzung abschicken. Sie trägt eine andere Aussage nicht: dass ein Vollsnapshot schon auf der Seite stand, der Sie zugestimmt haben. Schalter und Datenschutzerklärung müssen am Artefakt geprüft werden. Liegt lokal eine neue .enc? Zeigt workspacePath in der Statusdatei auf das kommerzielle Projekt, an dem Sie gerade schreiben?

Was „verschlüsselt“ und „sofort gelöscht“ jeweils belegen

Teilen Sie die Sätze aus der Meldung in „das trägt“ und „das trägt nicht“. Das ist ruhiger, als den Adjektiven zu folgen. Chiffretext auf der Platte trägt nur dies: Die gepackten Bytes sind kein Klartext-Verzeichnisbaum. Sofortiges Löschen trägt nur dies: Der Anbieter sagt, er behalte das Objekt nach der Wiki-Erzeugung nicht lange. Eine Suche im Open-Source-Baum, die /api/v1/snapshot/upload-credential nicht findet, trägt nur dies: Der Pfad fehlt im Baum, der jetzt öffentlich ist. Ein Bucket, der bei der Prüfung leer war, trägt nur dies: Dieser Bucket war zum Prüfzeitpunkt leer.

Keiner dieser Sätze deckt die andere Seite. Chiffretext trägt nicht „Sie können den Workspace wiederherstellen“. Sofortiges Löschen trägt nicht „vor dem Löschen hielt niemand den privaten Schlüssel“, und es trägt nicht „der Erhebungsumfang entsprach der Option, die Sie angekreuzt haben“. Ein Open-Source-Baum, der auf zwei Commits flachgedrückt wurde, taugt nicht zum Vergleich, wie der alte Sidecar geschrieben war. Ein nachträglich geleerter Bucket lässt sich nicht zurückdrehen auf die Frage, wer Objekte entschlüsselt oder kopiert hat, die vor dem 18. September schon angenommen waren. ferstar hat die Spannung notiert: Brauchte der Checkpoint-Rücklauf wirklich einen vollen Upload in die Cloud, steht das zeitlich gegen „sofort nach der Erzeugung löschen“. Die Checkpoint-Umsetzung im Open-Source-Baum ist ein lokales Git-Diff. Metadaten liegen als JSON unter ~/.zcode/checkpoints/. Sie hängen nicht an diesem Upload-Pfad.

Was Sie auf diesem Gerät prüfen können

Ein Slogan ist kein Beleg. Die Prüfungen unten decken nur drei Schichten ab, die Sie steuern: ob ein wartendes Artefakt schon auf diesem Gerät liegt, ob eine Anfrage Klartext aus dem Workspace mitnahm, und ob Sie diesen Chiffretext selbst öffnen. Schieben Sie keinen weiteren „Test-Upload“ in ein Produktiv-Repository.

1. Sehen Sie zuerst ins lokale Datenverzeichnis, nicht zuerst auf die Produktseite. Im Checkpoint- oder Cache-Ordner eines KI-Coding-Clients bedeuten eine .enc von hunderten Megabyte und eine Statusdatei mit workspacePath, encryptedSizeBytes und failureCount, dass das Packen schon gelaufen ist. Ein Pfad, der zu dem Projekt passt, an dem Sie schreiben, wiegt schwerer als „wir schicken nur den Gesprächskontext“.
2. Öffnen Sie die Entwicklertools oder einen Netzbeobachter des Systems und schalten Sie Preserve log ein. Lesen Sie nur Anfragezeile und Hostnamen: Gibt es einen Aufruf, der ein Upload-Credential anfragt, und gibt es einen Formular-POST direkt zum Objektspeicher? Sie prüfen, ob Chiffretext diesen Rechner verlassen hat, nicht, ob Sie das Repository noch einmal schicken. Stehen im Body Quelltext, eine Passphrase oder ein .pem im Klartext, ist diese Schicht schon durchgefallen.
3. Stellen Sie eine Frage, die Sie zu Ende bringen können: Kann ich diesen lokalen Chiffretext mit meiner eigenen Passphrase oder einem privaten Schlüssel auf diesem Gerät öffnen? Wenn Sie es nicht können und der Anbieter ebenfalls sagt, der Client könne es nicht, liegt der Schlüssel nicht bei Ihnen. Erst wenn Sie die Datei öffnen, ist „das ist ein Backup für mich“ eine faire Bezeichnung.
4. Schalten Sie jeden Schalter aus, dessen Name nach Datenschutz, Index oder Verbesserung klingt. Warten Sie einen Sitzungszyklus. Sehen Sie dann nach: Liegt im Checkpoint-Verzeichnis ein neues Paket zum Hochladen, und ist der Fehlerzähler weiter gestiegen? Die Beschriftung eines Schalters belegt keinen Hauptschalter. Eine neue Datei belegt es.
5. Brauchen Sie eine Datei, die Sie selbst noch öffnen, wechseln Sie auf einen Kanal, dessen Rechengrenze aufgeschrieben ist. Öffnen Sie Datei verschlüsseln, nehmen Sie eine wegwerfbare Canary-Datei und nennen Sie sie canary-fp-20260922-vendor-key.txt. Die Passphrase bleibt auf diesem Computer. Öffnen Sie Network, schalten Sie Preserve log ein und verschlüsseln Sie. Anfragezeile und Body sollen weder den Dateiinhalt noch die Passphrase noch den vollen Dateinamen als Geschäftsfeld enthalten. Die Ausgabe ist .lock oder .enc. Eine Datei ist auf 5 GB begrenzt. Entschlüsseln Sie auf diesem Gerät mit derselben Passphrase. Die Canary soll zurückkommen. Sie können sie öffnen, weil die Passphrase bei Ihnen liegt, nicht weil im Algorithmusnamen AES steht.

Schritt fünf verlangt nicht, dass Datei verschlüsseln den Coding-Client ersetzt. Er liefert einen Vergleich. Dieselbe Wendung, „auf diesem Gerät verschlüsselt“, kann heißen: Schlüsselableitung und AES-256-GCM bleiben im aktuellen Tab, Datei und Passphrase gehen nicht als Geschäftsdaten hoch. Den Chiffretext nehmen Sie mit, und Sie öffnen ihn. Eine frühere Notiz deckte eine andere Schicht: HTTPS schützt nur den Hop bis zum Router. Die zusätzliche Schicht hier ist, wer den Umschlag öffnet, nachdem der Chiffretext das Gerät verlassen hat.

Drei Arten, „lokale Verschlüsselung“ zu weit zu lesen

Die erste liest „AES wurde auf diesem Gerät aufgerufen“ als „nur ich kann entschlüsseln“. Ein lokaler Aufruf heißt nur: Der Klartext war noch auf diesem Computer, während er gepackt wurde. Kommt der öffentliche Schlüssel vom Server und landet der private Schlüssel nie, liegt das Entschlüsselungsrecht in der Cloud. Die Algorithmusliste, die Schlüssellänge und CTR gegen GCM beantworten nicht, in wessen Prozess der private Schlüssel liegt.

Die zweite liest „direkt in den Objektspeicher, nicht über den Anwendungsserver“ als „der Anbieter sieht es nicht“. Die Datei kann den Anwendungsserver überspringen. Der Registrierungs-Callback und der private Schlüssel liegen weiter auf der Seite des Anbieters. Den Anwendungsraum zu überspringen verringert eine Klartextkopie in Anwendungslogs. Es verschiebt das Entschlüsselungsrecht nicht. Die Router-Notiz zeigte, dass HTTPS einen Proxy auf der Anwendungsschicht nicht aufhält. Was diese Notiz nicht aufhält, ist das Ende, das den privaten Schlüssel hält.

Die dritte liest „sofort gelöscht / Open Source / der Bucket ist leer“ als „nie erhoben“. Löschen senkt die Aufbewahrung. Open Source lässt Sie den Baum prüfen, der jetzt öffentlich ist. Ein leerer Bucket heißt: Zum Prüfzeitpunkt lag kein Objekt darin. Keines davon heißt automatisch, historische Objekte seien nie geöffnet worden, oder die Schalter von damals hätten eine volle Git-Historie abgedeckt. In eine Übergabenotiz gehört, ob dieses Gerät noch Pakete zum Hochladen erzeugt, und ob Sie den Chiffretext öffnen, den Sie gleich verschicken. Eine Überschrift „behoben“ ist diese Notiz nicht.

Häufige Fragen

Wenn auf der Platte schon Chiffretext liegt, ist das dann Zero-Knowledge auf diesem Gerät?

Nein. Chiffretext heißt nur: die gepackten Bytes sind kein Klartext-Workspace. Kommt der RSA-Schlüssel, der den Inhaltsschlüssel einwickelt, in diesem Moment vom Server, und landet der passende private Schlüssel nie auf dem Gerät, öffnen weder Sie noch der Client die Datei. Das ist ein Umschlag für die Cloud, kein Backup, das Sie selbst wiederherstellen.

Der Anbieter sagt, Uploads würden sofort gelöscht. Was lässt sich danach noch prüfen?

„Sofort löschen“ senkt die Aufbewahrungsdauer. Es beantwortet nicht, ob das erste Paket über den Schalter hinausging, den Sie angeklickt haben, und auch nicht, wer vor dem Löschen den privaten Schlüssel hielt. Ein nachträglich geleerter Bucket zeigt nicht, wer Objekte entschlüsselt oder kopiert hat, die vor dem 18. September schon angenommen waren.

Stoppt der Upload, wenn ich „Erlebnis verbessern“ und „Repository-Index“ ausschalte?

Im zerlegten älteren Client steuerte der eine Schalter die Trainingsfreigabe, der andere, ob die Cloud einen Index baut. Keiner von beiden hat Packen und Direktupload abgeschnitten. Suchen Sie einen eigenen Schalter, der Snapshots stoppt, und prüfen Sie, ob danach lokal noch neuer Chiffretext zum Hochladen erscheint.

Wie gebe ich einer Kollegin eine Datei, die ich selbst noch öffnen kann?

Verschlüsseln Sie im aktuellen Tab mit AES-256-GCM und nennen Sie die Passphrase nur einer Person, die Sie schon geprüft haben. Öffnen Sie Datei verschlüsseln. Eine Datei ist auf 5 GB begrenzt. Die Ausgabe ist .lock oder .enc. Datei und Passphrase werden standardmäßig nicht hochgeladen. Sofort nutzbar, kein Konto. Kurze Geheimnisse gehen über den Einmal-Link, der Schlüssel steht hinter #. Die Form ist s.html?id={id}#{key}. Stehen in einem Ticket oder Log noch Telefon oder Ausweisnummer, maskieren Sie zuerst in der Schwärzung nach Regeln. Der Ausgangstext geht nicht als Geschäftsdaten hoch.

Wenn Sie selbst öffnen müssen, nehmen Sie einen Kanal, der sofort bereitsteht

Wollen Sie eine Seite, die die Rechengrenze offen hinschreibt, und wollen Sie üben „ich öffne den Chiffretext, und die Passphrase geht nicht in Network“, öffnen Sie bei FastPwd Datei verschlüsseln. Keine Anmeldung. Nehmen Sie die Canary von oben und lassen Sie AES-256-GCM im aktuellen Tab laufen, dann folgen Sie den Prüfungen im Abschnitt darüber: Die Anfrage soll weder Dateiinhalt noch Passphrase enthalten, und dieselbe Passphrase soll die Datei auf diesem Gerät zurückholen. .lock oder .enc können Sie auf ein Laufwerk kopieren. Schreiben Sie die Passphrase nicht in denselben Chat und nicht in ein KI-Feld.

Müssen Sie trotzdem einen Repository-Ausschnitt an ein Cloud-Modell geben, nehmen Sie an, die empfangende Seite sieht den ganzen Text, den Sie einfügen. Ein Router lässt dort ein Klartext-Aufrufpaket, wo HTTPS endet. Die frühere Notiz hat das schon geschrieben. Diese Notiz fügt eine Frage hinzu: Verschlüsselt der Client erst und lädt dann hoch, liegt der private Schlüssel, der den Umschlag öffnet, bei Ihnen? Fallen beide Schichten durch, legen Sie keinen lebenden Cloud-Schlüssel, keinen privaten SSH-Schlüssel und keine Kundendaten in einen Workspace, den ein Werkzeug packt. Regelbasierte Schwärzung maskiert gängige Felder. Ein ganzer Schlüssel geht über den Einmal-Link, oder er verlässt das Gerät gar nicht.

Wenn Sie das nächste Mal lesen „wir verschlüsseln lokal und laden dann hoch“, merken Sie sich drei Dinge. Erstens: Fragen Sie, wer den privaten Schlüssel oder die Passphrase hält. Bleiben Sie nicht beim Algorithmusnamen stehen. Zweitens: Fragen Sie, ob die Liste eine .git-Historie abdeckt, die nicht die aktuellen Dateien ist. Drittens: Vergleichen Sie mit einem Chiffretext, den Sie selbst öffnen, nicht mit einer Löscherklärung. Diese drei Sätze können Sie in eine Übergabenotiz schreiben. „Auf der Platte liegt Chiffretext, also sieht die Cloud ihn nicht“ gehört nicht hinein.

Weiterlesen

Ein Passwort auf dem Archiv vor dem Cloud-Upload versteckt keine Dateinamen und ist kein lokales AES-GCM: Was ein ZIP-Passwort vor dem Cloud-Upload abdeckt – und warum das kein lokales AES-GCM ist. HTTPS verschlüsselt nur den Hop bis zum Router und hält einen SSH-Schlüssel im Prompt nicht auf: Warum in einem 6TB-LLM-Router-Dump SSH-Schlüssel auftauchen – und welche Schicht HTTPS nicht hält. Wie Sie eine Seite mit „lokaler Verschlüsselung“ selbst in Network prüfen: So prüfen Sie, dass browserlokale Verschlüsselung keinen Klartext sendet.