Zuerst das Fazit: Ein ZIP-Passwort beweist nicht „die Cloud sieht die Dateien nicht“. Es zeigt nur, dass das Entpacken eine Passphrase braucht. Das ZIP-Verzeichnis ist standardmäßig lesbar, und klassisches ZipCrypto kann den internen Schlüssel preisgeben, sobald ein kurzes Stück Klartext bekannt ist. Vor dem Upload prüfen Sie zwei Dinge: Ist der Inhalt auf diesem Gerät schon mit authentisierter Verschlüsselung versiegelt – und hat genau diese HTTP-Anfrage Klartext oder die Passphrase mitgenommen?
Die Suchintention in einem Satz beantworten
Ein Passwort auf dem Archiv vor dem Cloud-Upload ist nicht dieselbe Schicht wie lokales AES-GCM. Das Archiv legt Dateien in einen ZIP-Behälter und sperrt den Inhalt dieser Dateien. Das eigene Verzeichnis des Behälters – Namen, Datum, Größe – ist zum Lesen gedacht. Lokales AES-256-GCM nutzt die Web Crypto API des Browsers auf den Bytes; Sie laden den Chiffretext herunter und erst dann hoch. Ohne Ihre Passphrase bleibt der Cloud-Speicher bei Rauschen.
Diese Notiz richtet sich an Entwicklung, Betrieb und alle, die vor einem Backup in Drive oder OneDrive „ich habe ein Passwort gesetzt“ von „die Gegenseite kann den Inhalt nicht lesen“ trennen wollen. Sie ersetzt nicht die Bedienung von Datei verschlüsseln und zählt nicht die Klicks bis zur .lock. Mitnehmen sollen Sie: was ZipCrypto und ZIP-AES jeweils abdecken, wer die Standardschlüssel der Cloud hält, was im lokalen Dateikopf stehen bleibt – und wie Sie Network plus Hexdump an diesem Lauf prüfen.
„Ich habe ein Passwort gesetzt“ heißt nicht „die Cloud sieht den Inhalt nicht“
Die Alltagssprache packt drei verschiedene Jobs in den Satz „diese Datei ist verschlüsselt“. Erstens die Übertragung: Browser und Cloud sprechen HTTPS; wer auf dem Weg mithört, kommt an die Bytes kaum heran. Zweitens die Ruhezustandsverschlüsselung des Anbieters: Blöcke auf der Platte sind mit Schlüsseln umhüllt, die der Anbieter verwaltet – das hilft, wenn eine Festplatte das Rechenzentrum verlässt. Drittens clientseitige Verschlüsselung mit einem Schlüssel, den Sie halten: Der Inhalt ist schon Chiffretext, bevor er hochgeladen wird; ohne Ihre Passphrase kommt der Anbieter nicht hinein.
Ein ZIP-Passwort sitzt in einer vierten Gewohnheit: Sie bauen auf diesem Rechner einen passwortgeschützten Behälter und laden ihn wie jede andere Datei hoch. Drive, OneDrive oder Dropbox behandeln ihn wie jedes .zip – Index nach Namen, Hash für den Sofort-Upload, Viren- oder Richtlinienscan, wenn die Policy das verlangt. Steckt im Inneren noch ZipCrypto oder ist das Verzeichnis Klartext, braucht ein Scanner Ihr Passwort nicht zu raten, um Dateinamen zu lesen – und manchmal, um am Inhalt mehr zu tun.
„Ich habe ein Passwort gesetzt“ trägt also nur einen engen Satz: Wer nicht entpackt oder die Passphrase nicht hat, öffnet die Dateien nicht leicht. Es trägt nicht „ein Mitarbeiter der Cloud sieht das nicht“, „ein Auskunftsersuchen holt den Klartext nicht“ oder „Dateinamen landen nie im Index“. Diese Sätze werden erst prüfbar, wenn Sie die Schicht wechseln: authentisierte Verschlüsselung auf diesem Gerät, dann Chiffretext hochladen.
Was ZipCrypto nicht aufhält
Die klassische ZIP-Verschlüsselung heißt Zip 2.0 oder ZipCrypto. WinZip schreibt das selbst klar: Das Format ist vergleichsweise schwach; wer ein spezielles Wiederherstellungswerkzeug hat, soll nicht daran scheitern; bei ernsthaftem Schutzbedarf AES nehmen. Das steht in den WinZip-Hinweisen zur Verschlüsselung, nicht in einem Forenbeitrag.
Schwach ist die Chiffre, nicht die Länge Ihres Passworts. 1994 veröffentlichten Eli Biham und Paul Kocher einen Known-Plaintext-Angriff auf die PKZIP-Stromchiffre: Mit etwa einem Dutzend passender Klartext- und Chiffretextbytes lassen sich die drei internen 32-Bit-Zustände und danach der Schlüsselstrom der restlichen Datei rekonstruieren. Die Passwortlänge fällt in diesem Schritt weg – kopiert wird der Schließzylinder, nicht ausprobiert die Schlüssel. Öffentliche Programme wie bkcrack machen aus dem Paper lauffähigen Code; Archive, die mit ZipCrypto nur gespeichert (Store) und nicht mit Deflate komprimiert sind, sind der direkteste Fall.
Woher kommt der bekannte Klartext? Ein PDF beginnt mit %PDF. Office-Dateien, viele Bilder und verschachtelte ZIPs haben feste Magic-Bytes. Packen Sie ein bekanntes Dokumentformat in ein ZipCrypto-Archiv und laden es hoch, haben Sie Chiffretext plus eine fast sichere Klartextprobe mitgeliefert. Das ist keine Anleitung zum Angriff. Es ist der Grund, „Rechtsklick, packen, Passwort setzen“ nicht mit AES-256-GCM zu verwechseln.
Unter Windows erzeugt „Senden an → ZIP-komprimierter Ordner“ oft gar kein Passwort – nur ein offenes Archiv. Sobald ein Packer ein ZIP-Passwort anbietet, etwa 7-Zip im Format ZIP, landet häufig ZipCrypto, weil fast jedes Entpackprogramm es öffnet. Nach dem Packen die Eigenschaften lesen: steht ZipCrypto oder Zip 2.0, taugt das Archiv nicht als Backup. Steht AES, weiter zum nächsten Abschnitt – die Inhaltsschicht ist stärker, das Verzeichnis oft weiter Klartext.
Experimentieren Sie nicht mit einem echten Vertrag, einem Ausweisscan oder einem ungeschwärzten Projektordner. Legen Sie eine wegwerfbare kleine Datei an. Dateiname und Textkörper bekommen je einen einmaligen Canary. Sie prüfen Verzeichnis, Dateikopf und Datenverkehr – Sie sollen Privates nicht noch einmal hochladen.
Auch ein AES-ZIP zeigt das Verzeichnis
WinZip bietet seit Version 9.0 AES-128 und AES-256 (AE-1 / AE-2). Der Schlüssel kommt aus der Passphrase über PBKDF2, mit 8, 12 oder 16 Byte Salt und 1000 Iterationen. Das ist ein großer Schritt gegenüber ZipCrypto – und trotzdem nicht „AES-256-GCM im Browser“. WinZip AES verschlüsselt und authentisiert danach (AES-CTR plus HMAC). Das ist nicht NIST-GCM. Tausend Iterationen liegen weit unter der heute üblichen Hunderttausender-Klasse der Passwortableitung. Die Hülle beschreibt WinZip auf der Seite zur AES-Verschlüsselung.
Das Verzeichnis übersieht man leichter. WinZip schreibt: Verschlüsselt wird nur der Inhalt der Dateien im Archiv. Name, Datum, Größe, Attribute und Kompressionsverhältnis liegen in einem unverschlüsselten Verzeichnis. Wer das ZIP hat, liest sie ohne Passwort. Es gibt sogar einen eigenen Hinweis „ein verschlüsseltes ZIP zeigt trotzdem Dateinamen“ und den Vorschlag, einmal unverschlüsselt zu packen und dieses Archiv in ein zweites, verschlüsseltes ZIP zu legen. Siehe WinZip zur Sichtbarkeit von Dateinamen.
7-Zip kann im Format .7z den Haken „Dateinamen verschlüsseln“ setzen. Das ist eine andere Produktlinie; vermischen Sie das nicht mit dem ZIP-Standardverhalten. „Kennwort erforderlich“ im Explorer heißt nur: Entpacken braucht eine Passphrase. Öffnen Sie dieselbe Datei in einem anderen Entpacker, steht die Liste oft sofort da: personalausweis-rueckseite.jpg, gehaltsliste-2026.xlsx, kundenliste.csv. Sofort-Upload, Vorschau und Richtlinienscan lesen genau diese Schicht.
„Verschlüsselt in der Cloud“ heißt meist: der Anbieter hält die Schlüssel
Legen Sie das ZIP – oder die Originaldatei – in Drive, schreibt die Hilfeseite Verschlüsselung bei der Übertragung, im Ruhezustand, AES-256. Diese Sätze können alle stimmen und trotzdem die Frage offenlassen, wer den Auspackschlüssel hält. Google schreibt zu Drive: Hochgeladene oder in Docs / Sheets / Slides erstellte Dateien sind standardmäßig unterwegs und ruhend mit AES-256 verschlüsselt. Soll Google selbst nicht entschlüsseln können, muss ein Workspace-Administrator die clientseitige Verschlüsselung einschalten; der Nutzer braucht ein Arbeits- oder Schulkonto und eine Identitätsprüfung. Eine private Datei, die Sie in „Meine Ablage“ ziehen, geht den Standardweg – nicht die clientseitige Verschlüsselung. Grundlage ist die Drive-Hilfe zu verschlüsselten Dateien.
Google Cloud beschreibt das Standardmodell im Ruhezustand noch deutlicher: Die Schlüssel gehören Google und werden von Google verwaltet. Datenschlüssel (DEK) auf der Platte werden von Schlüsselverschlüsselungsschlüsseln (KEK) umhüllt; das Entschlüsseln läuft in der Schlüsselverwaltung des Anbieters. Siehe Google Cloud: Standardverschlüsselung im Ruhezustand. Workspace-Whitepaper ziehen dieselbe Linie zwischen „Google verwaltet die Schlüssel“ und „nach clientseitiger Verschlüsselung kann Google nicht lesen“. Hash für den Sofort-Upload, Dokumentvorschau und Compliance-Scan setzen voraus, dass der Server Dateibytes sieht – oder mindestens einen Klartext-Hash. Ein lokales ZIP-Passwort macht daraus kein Zero-Knowledge.
Das Schloss am Cloud-Badge schützt also „eine Platte ist aus dem Rechenzentrum gewandert“ und „jemand horcht auf dem Weg“. Es schützt nicht „nachdem ich dieser Firma die Datei gegeben habe, sieht sie sie auch nicht“. Der zweite Satz wird erst zur Beobachtung, wenn der lesbare Klartext vor dem Upload verschwunden ist. OneDrive und Dropbox werben ähnlich mit Übertragung und Ruhezustand; ohne clientseitige Schicht bleibt die Schlüsselhoheit beim Anbieter.
Welche Schicht lokales AES-256-GCM wirklich schützt
AES-GCM ist authentisierte Verschlüsselung: Ein Durchlauf verbirgt die Bytes und bindet die Integrität. Wurde der Chiffretext geändert, abgeschnitten oder die Passphrase ist falsch, muss das Entschlüsseln scheitern – statt „Müll, der wie Klartext wirkt“ auszugeben. NIST SP 800-38D empfiehlt für interoperables GCM einen 96-Bit-IV (12 Byte); das Tag ist üblich 128 Bit (16 Byte). Derselbe IV unter demselben Schlüssel zerstört Vertraulichkeit und Authentizität gemeinsam.
Der korrekte Weg im Browser ist crypto.subtle.encrypt mit dem Algorithmusnamen AES-GCM. MDN schreibt, dass SubtleCrypto.encrypt nur in einem sicheren Kontext verfügbar ist – in Produktion HTTPS. Eine Passphrase ist kein 256-Bit-Schlüssel. Sie muss durch eine Funktion wie PBKDF2 mit Salt und vielen Iterationen. RFC 2898 definiert PBKDF2; die Iterationszahl bestimmt, wie lange ein Rateversuch dauert. Tausend und hunderttausend liegen nicht in derselben Klasse.
Ein Dateivorgang lässt sich als sichtbare Schritte schreiben: eine lokale Datei wählen, das Skript liest blockweise, jeder Block bekommt einen frischen Zufalls-IV und AES-256-GCM, danach löst der Browser den Download des Chiffretexts aus. Dieser Download entsteht auf diesem Gerät. Es ist keine Serverquittung. Eine Obergrenze von 5 GB pro Datei beschreibt das Streaming im Browser – nicht, dass ein entfernter Rechner 5 GB Klartext erhalten hat.
FastPwd Datei verschlüsseln folgt dieser Grenze: AES-256-GCM in Web Crypto; die Passphrase geht durch PBKDF2-HMAC-SHA256, 100000 Iterationen, 16 Byte Salt, 256-Bit-Schlüssel; Standardblöcke 1 MB, je 12 Byte IV, Chiffretext und 16-Byte-Tag; eine Datei höchstens 5 GB; Ausgabe .lock / .enc mit den Magic-Bytes CSLK. Alle Tools sind sofort nutzbar – kein Konto, kein Passwort-Tresor. Vergessen Sie die Passphrase, gibt es keine Wiederherstellung, weil sie nie hochgeladen wurde. Ein Versprechen bleibt ein Versprechen. Die Prüfliste unten enthält den Teil des Dateikopfs, der nicht verschlüsselt ist.
Was die Verschlüsselung beweist – und was der Dateikopf noch zeigt
Die Schlussfolgerung, die lokale Verschlüsselung trägt, ist ebenso eng. Sie aufzuschreiben verhindert eine Fehlannahme. Sie kann stützen: Bei diesem Lauf wurde der Dateiinhalt blockweise zu authentisiertem Chiffretext; ohne Passphrase muss das Entschlüsseln scheitern; findet Network den Canary nicht, sind Klartext und Passphrase nicht als beobachtete HTTP-Nutzdaten rausgegangen.
Sie kann nicht stützen: Die Cloud sieht gar keine Metadaten, keine Erweiterung hat die Zwischenablage gelesen, die Passphrase ist stark genug, oder wer den Chiffretext hat, rät offline nie. FastPwd Lock v1 legt Originaldateiname und MIME im Klartext in den Dateikopf, damit das Entschlüsseln den Namen wiederherstellen kann. Laden Sie personalausweis-rueckseite.lock hoch oder lassen personalausweis-rueckseite.jpg im Kopf, liest Drive – oder jeder mit einem Hex-Viewer – diese Wörter. Verschlüsselt sind die Inhaltsblöcke, nicht das Etikett, das der Behälter nach außen zeigt.
| Was Sie sehen | Was das stützt | Was das nicht stützt |
|---|---|---|
| ZIP verlangt zum Entpacken ein Passwort | Die Inhaltsschicht hat ein Schloss | Das Verzeichnis ist verborgen; der Algorithmus ist AES-GCM |
| Dateinamen ohne Entpacken sichtbar | Das ZIP-Verzeichnis ist Klartext (der übliche Default) | Der Inhalt lässt sich ebenfalls öffnen |
| Eigenschaften: ZipCrypto / Zip 2.0 | Klassische Stromchiffre; Known-Plaintext greift | Ein langes Passwort hält ein Spezialwerkzeug auf |
| Cloud zeigt „verschlüsselte Speicherung“ | Übertragung oder Ruhezustand sind wahrscheinlich da | Der Anbieter hat keine Schlüssel und sieht den Klartext nicht |
Dieses Gerät hat eine .lock / .enc heruntergeladen |
Der Browser hat eine Chiffretextdatei erzeugt | Der Originalname im Dateikopf ist ebenfalls versteckt |
| Network findet den Canary nicht | Diese Anfragen haben diese Felder nicht mitgenommen | Erweiterungen, Zwischenablage und die nächste Version sind sauber |
Vor Ort prüfen: Network, Dateikopf, Offline
Slogans sind kein Beweis. Legen Sie eine wegwerfbare kleine Datei an. In den Textkörper canary-fp-20260904-zip-vs-gcm, als Dateiname canary-fp-20260904.txt. Nutzen Sie eine einmalige lange Passphrase. Keine echte wiederverwenden.
- Zuerst die Kontrolle: Dieselbe Datei als passwortgeschütztes ZIP packen. Im Entpacker ohne Passwort öffnen. Notieren, ob Dateinamen sichtbar sind und ob die Eigenschaften ZipCrypto oder AES schreiben. Das ist die Reichweite eines ZIP-Passworts.
- Dann lokal im Browser verschlüsseln. DevTools Network öffnen, Preserve log aktivieren, Filter auf All. Nach dem Verschlüsseln den Canary ins Suchfeld legen. Er darf in Anfragezeile, Body und Statistik nicht erscheinen.
- Die heruntergeladene
.lockim Hex-Viewer öffnen. Die ersten vier Bytes sollenCSLKsein (43 53 4C 4B). Weiter hinten Salt, Blockgröße und der Originaldateiname, den Sie gelassen haben. Im Inhaltsbereich darf der Canary-Satz nicht mehr als Klartext stehen. - Wenn die Seite geladen ist, in Network Offline wählen oder das Systemnetz trennen und eine zweite wegwerfbare Datei verschlüsseln. Kommt trotzdem eine
.lockan, brauchte dieser Lauf keine Live-API. Offline muss bestehen; online den Canary noch einmal suchen.
Passphrase und Chiffretext nicht über denselben Kanal schicken. Die .lock in den Cloud-Speicher; die Passphrase über den Einmal-Link: Dieser Browser verschlüsselt mit AES-256-GCM, der Server speichert nur Chiffretext, der Schlüssel sitzt im #-Fragment als s.html?id={id}#{key}. Die volle Adresse des Einmal-Links in denselben Cloud-Ordner wie den Chiffretext zu legen heißt, den Schlüssel auf die Kiste zu kleben.
Benennen Sie die Quelle vor dem Verschlüsseln bedeutungslos um. Der Dateikopf schreibt diesen Namen unverändert; die Endung .lock / .enc steht auch in der Cloud-Liste. Das mindert nur „der Dateiname selbst hat verraten“. Es ist keine Steganographie.
Drei Fälle, die verschlüsselt wirken und trotzdem nicht halten
Erstens „verschlüsselt packen“ auf einer Website. Manche Clouds packen erst nach dem Upload oder legen um den Freigabelink einen Extra-Code. Der Code hält Leute auf, die den Link nicht anklicken. Er hält keinen Server auf, der den Klartext schon gespeichert hat. Die Gegenprobe: Geschah die Verschlüsselung, bevor Sie die Datei gewählt haben – oder nachdem der Fortschrittsbalken durch war? Der zweite Fall ist kein lokales AES-GCM.
Zweitens das Öffnungskennwort von Office oder PDF. Es schützt den Öffnungsdialog des passenden Readers. Im Dateiformat bleiben viele strukturierte Felder; Cloud-Vorschau, Volltextsuche und Konvertierung gehen oft um „beim Öffnen nach Passwort fragen“ herum. Das ist keine authentisierte Verschlüsselung der ganzen Datei.
Drittens nur die Endung ändern. .xlsx in .bin umbenennen und hochladen stoppt weder Sofort-Upload noch manchen Scanner, die am Inhaltshash arbeiten; die Magic-Bytes im Kopf bleiben. Eine Endung ist keine Kryptographie. Nach lokaler Verschlüsselung sollen diese Signaturen im Inhaltsbereich verschwunden sein. Stehen im Hexdump noch PK, %PDF oder ein Klartext-xlsx-Merkmal, ist dieser Lauf nicht bestanden.
FAQ
Reicht ein AES-256-Passwort auf dem ZIP, bevor ich es in die Cloud lege?
Die Inhaltsschicht ist stärker als ZipCrypto, aber Dateinamen, Datum und Größe im ZIP-Verzeichnis bleiben standardmäßig lesbar. Die Cloud und jeder, der das Archiv hat, kann die Liste sehen. Es ist auch kein AES-256-GCM im Browser: WinZip AES nutzt eine andere Hülle, PBKDF2 läuft 1000 Iterationen. Soll die Cloud nur Chiffretext sehen, zuerst den ganzen Inhalt lokal verschlüsseln, dann hochladen.
Wenn Drive „Verschlüsselung bei Übertragung und im Ruhezustand“ schreibt – reicht das?
Das ist meist die Standardverschlüsselung mit Schlüsseln des Anbieters. TLS schützt den Weg, Ruhezustandsverschlüsselung eine gestohlene Platte. Anbieter, Betrieb mit Schlüsselzugriff und ein rechtmäßiges Auskunftsersuchen können den Klartext weiter öffnen. Damit bei Google Drive „Google kann das nicht entschlüsseln“ zur Tatsache wird, muss ein Workspace-Administrator die clientseitige Verschlüsselung einschalten. Das ist nicht der Weg, wenn ein privates Konto eine Datei in „Meine Ablage“ zieht.
Sieht die Cloud nach dem Upload einer FastPwd-.lock noch den Originaldateinamen?
Ja. Sie sieht die Endung und liest Originalname sowie MIME aus dem Dateikopf. Verschlüsselt sind die Inhaltsblöcke zu je 1 MB – nicht die Metadaten des Behälters. Benennen Sie die Quelle vor dem Verschlüsseln bedeutungslos um. Legen Sie die Passphrase nicht in dieselbe Freigabe wie den Chiffretext.
Werden Datei und Passphrase bei FastPwd hochgeladen?
Laut Produktbeschreibung laufen Ver- und Entschlüsselung im aktuellen Tab über Web Crypto. Datei und Passphrase gehen nicht als fachliche Nutzdaten raus und nicht in die Analytics. Die Zugriffsstatistik speichert Aktionsnamen, nicht Datei oder Passphrase. Suchen Sie in Network einen Canary: Er darf in Anfragezeile und Body nicht stehen. Localhost sendet standardmäßig keine Zugriffsstatistik; auf dem Live-Hostnamen noch einmal prüfen, näher am echten Gebrauch.
Dieselbe wegwerfbare Datei an einem sofort nutzbaren Tool prüfen
Wenn Sie an einer Seite mit klar geschriebener Rechengrenze üben wollen, öffnen Sie FastPwd Datei verschlüsseln. Sofort nutzbar, keine Registrierung. Wählen Sie die Canary-Datei oben und eine einmalige lange Passphrase. Wird die Passphrase als schwach bewertet, fragt die Seite zuerst nach. Laden Sie die .lock herunter. Gleichzeitig Network im Blick: statische Ressourcen und vielleicht Zugriffsstatistik – nicht Originaldatei oder Passphrase als fachliche Felder.
Die Passphrase können Sie zuvor im Passwort-Generator lokal erzeugen. Zufallsmodus 6–128 Zeichen, Standard 16; unter 8 Zeichen warnt die Seite vor geringerer Sicherheit. Auch das Erzeugen wird nicht hochgeladen. Muss ein Kollege die Passphrase bekommen, wechseln Sie zum Einmal-Link. Nicht in die Cloud-Notiz. Eine einzeilige Geheimnis nicht in eine .lock als Transport stopfen – Datei verschlüsseln ist für Backup und Übergabe einer ganzen Datei, nicht für eine Zeile, die in den Chat gehört.
Vor dem nächsten Upload drei Dinge merken. Erstens: Ein ZIP-Passwort hält das Entpacken auf, nicht das Verzeichnis und nicht den Known-Plaintext-Angriff auf ZipCrypto. Zweitens: Die Standardverschlüsselung der Cloud lässt die Schlüssel meist beim Anbieter. Drittens: Lokales AES-256-GCM schützt Inhaltsblöcke; Dateikopf und Endung können weiter verraten, also Network und Hexdump selbst ansehen. Nur eine wiederholbare Beobachtung gehört in Ihre eigenen Backup-Notizen.
Weiterlesen
„Lokale Verschlüsselung, nichts hochgeladen“ ist kein Beweis, bis Sie in Network mit einem Canary suchen – siehe So prüfen Sie, dass browserlokale Verschlüsselung keinen Klartext sendet. Wenn Sie die Passphrase auf einem eigenen Kanal übergeben: warum der Teil hinter der Raute standardmäßig nicht in HTTP geht, in Warum sich ein Schlüssel hinter der URL-Raute eignet – und wann der Schutz fällt. Müssen Ausweisnummern in einem Ticket dieses Gerät erst maskiert verlassen, siehe Bevor Sie Tickets und Logs in eine KI einfügen: Welche Felder dieses Gerät verlassen.