Zertifikatspaket, exportierte Personalliste, Config mit privatem Schlüssel: Irgendwann landet die Datei in OneDrive, Google Drive, Nextcloud oder im Firmenlaufwerk. Die Upload-Seite schreibt «Transportverschlüsselung», «Verschlüsselung im Ruhezustand», «Tresor». Diese Wörter beschreiben Platte und Leitung des Anbieters, nicht «außer dir kann niemand öffnen». Ein früherer Text erklärt, wie du im Network prüfst, dass kein Klartext hochgeladen wurde: Slogans beweisen nichts. Hier geht es um den konkreten Fall — die Datei verlässt diesen Rechner und liegt danach auf fremdem Speicher. Zuerst klären, wer den Klartext sieht. Dann, welchen Weg das Passwort nehmen darf.
Das ist keine Feature-Liste «Datei online verschlüsseln» und kein Vergleich, welchen Cloud-Anbieter du wählen sollst. Drei Fragen reichen: Ist der Klartext schon Geheimtext, bevor er das Gerät verlässt? Kann der Anbieter oder der nächste Download die Datei danach noch direkt öffnen? Liegt das Passwort in derselben Mail wie die .lock oder .enc? Die Dateiverschlüsselung von MyPassGen arbeitet an dieser Grenze: AES-256-GCM im Browser, Ergebnis als Download; Datei und Passwort gehen nicht als Geschäftsdaten raus, ohne Konto. Die Tabelle und die Schritte unten kannst du selbst nachvollziehen.
«Verschlüsselt» meint oft eine andere Schicht
HTTPS schützt Mithörer auf dem Weg. Sobald die Datei auf dem Cloud-Server ankommt, kann der Anbieter sie im Klartext oder als «für sich selbst entschlüsselbaren» Geheimtext ablegen. Viele Produkte nennen genau diese anbieterverwalteten Schlüssel «Ihre Dateien sind verschlüsselt». Für den Betrieb hilft das gegen eine gestohlene Festplatte. Für «der Cloud-Betreiber soll den Ausweisscan nicht lesen können» reicht es nicht.
Clientseitig zuerst verschlüsseln, dann hochladen, ist eine andere Schicht: Browser oder lokales Programm leitet den Schlüssel aus einem Passwort ab, das du hältst. In der Cloud bleibt Geheimtext. Rclone Crypt, Cryptomator, manche Sync-Clients und Web Crypto im Tab gehören hierher. Sie beantworten «der Speicherort bekommt keinen nutzbaren Klartext». Sie beantworten nicht ein schwaches Passwort, Passwort und Datei in einer Nachricht oder einen Dateinamen, der den Inhalt schon verrät.
Art. 9 DSGVO stellt Gesundheitsdaten, biometrische Daten und andere besondere Kategorien unter einen engeren Rahmen. Ein unverschlüsselter Ausweisscan im privaten Cloud-Ordner, den du dann in den Team-Chat wirfst, gibt die Identifizierbarkeit mit weiter. Art. 32 DSGVO nennt Verschlüsselung als mögliche technische Maßnahme — «gegebenenfalls», risikobasiert, nicht als Freibrief. Das BSI IT-Grundschutz OPS.2.2 (A17) verlangt bei Cloud-Nutzung, Verschlüsselung und Schlüsselhaltung zu klären: vom Anbieter oder selbst. Lokal zuerst zu verschlüsseln verringert, dass Speicherort und Zufallsfund die Datei direkt öffnen. Es ist keine Anonymisierung und ersetzt nicht die Frage, ob die Datei diesen Rechner überhaupt verlassen darf. Eine Produktseite «DSGVO-konform» ist das nicht.
Zuerst fragen, wer öffnen kann — dann nach dem Algorithmus
Anbieter verschlüsselt: Der Anbieter öffnet, du öffnest. Lokal zuerst: Wer das Passwort nicht hat — einschließlich der Cloud-Seite — öffnet den Inhalt nicht. Passwort und Geheimtext in einer Nachricht: Jeder, der diese Nachricht sieht, fällt auf Fall eins zurück. «AES» auf der Seite macht Fall drei nicht zu Fall zwei.
Wer den Klartext sieht: drei Ablagen
Dieselbe certs.zip in der Cloud ergibt mindestens drei Lagen. Der Unterschied steht nicht im Marketingtext, sondern bei wem der Schlüssel liegt und ob der Klartext den Browser schon verlassen hat.
| Vorgehen | Was die Cloud-Seite bekommt | Download ohne Passwort |
|---|---|---|
| Originaldatei direkt hochladen | Vollständiger Klartext (plus TLS) | Sofort zu öffnen |
| Cloud-Tresor / Ruhezustand | Für den Anbieter lösbarer Geheimtext oder Klartext | Nach Login meist weiter zu öffnen |
Lokal zuerst, dann .lock / .enc |
Geheimtext; der Kopf kann den alten Namen noch tragen | Ohne Passwort kein Inhalt |
Nur die dritte Lage beantwortet «der Speicherort soll den Inhalt nicht sehen». Dafür muss die Verschlüsselung vor dem Upload fertig sein, und der Schlüssel darf nicht auf derselben Maschine liegen. Der vorige Text hat das schon festgehalten: Die Web Crypto API erlaubt die Rechnung im Browser. Sie verbietet der Seite nicht, zuerst hochzuladen und danach zu rechnen. «Lokal zuerst» prüfst du am Traffic, nicht am Werbesatz.
Was AES-256-GCM an dieser Stelle leistet
MyPassGen nutzt in der ersten Fassung nur AES-256-GCM. NIST SP 800-38D beschreibt GCM als authentisierte Verschlüsselung: Wurde der Geheimtext verändert, muss die Entschlüsselung scheitern — nicht einen Müllblock als Inhalt ausgeben. RFC 5116 definiert AEAD_AES_256_GCM mit 32-Byte-Schlüssel, 12-Byte-Nonce und 16-Byte-Tag. MDN empfiehlt in AesGcmParams ebenfalls eine 96-Bit-IV; unter demselben Schlüssel muss jede Verschlüsselung eine neue IV bekommen. Die IV selbst ist kein Geheimnis und darf neben dem Geheimtext liegen.
Das Passwort wird nicht direkt als AES-Schlüssel verwendet. Die Dateibox leitet mit PBKDF2, 100.000 Iterationen, SHA-256 und 16 Byte Salt einen 256-Bit-Schlüssel ab; das Salt steht im Dateikopf, damit die Entschlüsselung dieselbe Rechnung wiederholen kann. RFC 8018 verweist auf NIST SP 800-132: Die Iterationszahl soll im akzeptablen Wartefenster möglichst hoch liegen. OWASP empfiehlt für «Passwort-Hashes auf einem Server» derzeit mindestens 600.000 Durchläufe von PBKDF2-HMAC-SHA256. Bei einer Datei-Passphrase bleibt die erste Linie ein ausreichend langes Zufallspasswort — Iterationen bremsen Offline-Suche, nicht 123456 in der Cloud-Notiz.
Passwort und Geheimtext nicht denselben Weg
Der häufigste Bruch ist nicht der falsche Algorithmus, sondern: backup.lock und «Passwort ist Sommer plus Personalnummer» in derselben Gruppenchat-Nachricht, derselben Mail, derselben readme.txt im Cloud-Ordner. Dann hat die Cloud-Seite oder jedes Gruppenmitglied beide Hälften. Die lokale Verschlüsselung ist wirkungslos.
Die robuste Trennung: Geheimtext über Cloud oder Mail-Anhang; Passwort über einen anderen Kanal — persönlich, telefonisch oder als Einmal-Link (Schlüssel hinter # in der URL, Leseseite ohne Konto). Schreib das Passwort nicht in den Dateinamen, nicht in den ZIP-Kommentar und nicht in eine «nur ich»-Notiz unter demselben Cloud-Konto.
Das Passwort selbst solltest du im Passwortgenerator lokal erzeugen: Zufallsmodus 6–128 Zeichen, Standard 16; unter 8 Zeichen gilt als schwach. Ein vergessenes Passwort ist nicht wiederherstellbar: kein Klartext-Backup auf dem Server, keine Sicherheitsfrage. Das ist der Preis einer Ablage, bei der die Gegenseite den Inhalt nicht kennt — kein fehlendes Feature.
Gib die Originaldatei keiner unbekannten «Online-Verschlüsselung»
Ein ganzes Zertifikatspaket per POST an eine Seite zu schicken, die «für dich rechnet», schreibt den Klartext in fremde Logs. Die Verschlüsselung muss im aktuellen Tab fertig sein, und im Network darfst du sehen: keine Datei im Geschäftskörper, kein Passwortfeld. Der Download ist eine .lock oder .enc von diesem Gerät — kein Link auf eine «schon verschlüsselte Kopie» irgendwo anders.
Was im .lock noch lesbar ist
Geheimtext heißt nicht «die ganze Datei ist unkenntliches Rauschen». Öffentliche Containerköpfe tragen oft noch Metadaten. MyPassGen schreibt standardmäßig .lock, wahlweise .enc — dasselbe Format, andere Endung, damit andere Werkzeuge sich leichter einordnen. Der Kopf beginnt mit vier Byte CSLK, danach Version, 16-Byte-Salt, Blockgröße sowie ursprünglicher Dateiname und MIME-Typ im Klartext. Der Inhalt läuft in Blöcken von etwa 1 MB durch AES-GCM; jeder Block hat eigene 12-Byte-IV und 16-Byte-Tag.
Wenn du ausweis-scan.pdf zu ausweis-scan.pdf.lock machst und hochlädst, stehen in der Cloud-Liste und im Dateikopf weiterhin «das ist ein Ausweisscan». Geschützt sind die Bytes des Inhalts, nicht der Name. Ist der Name selbst heikel, benenne die Datei vorher bedeutungslos um; die hochgeladene .lock soll ebenfalls keinen lesbaren Titel tragen.
Eine Datei höchstens 5 GB. Beim Verschlüsseln schneidet die Seite per Blob.slice etwa 1 MB und übergibt das Stück an crypto.subtle.encrypt. Web Crypto nimmt pro encrypt() genau eine BufferSource; die ganze Datei auf einmal würde den Tab-Speicher sprengen. Die Schnitte vermeiden «den kompletten Klartext in einem Rutsch an die API». Das Ergebnis wird trotzdem lokal zur Downloaddatei zusammengesetzt. Die aktuelle Entschlüsselung liest die ganze .lock zuerst — sehr große Dateien brauchen also mehr RAM. Das siehst du im Task-Manager, das steht nicht nur auf der Seite.
Sofort prüfen: Network, Dateikopf, lässt sich nicht öffnen
Die folgenden Schritte hängen an keiner Markenaussage. Nimm eine wegwerfbare kleine Textdatei. Keinen echten Ausweis zum Üben.
- Lege eine
probe.txtmit ein paar Dutzend Byte an und schreib einen Satz hinein, den nur du kennst, etwaorange-lake-7. Kein echtes Passwort, kein Ausweis. - Öffne die Entwicklertools, Tab Network, «Protokoll beibehalten». Öffne die Dateiverschlüsselung, wähle die Datei, setze ein Passwort, starte.
- Gehe Fetch / XHR durch: In Zeile und Körper darf
orange-lake-7nicht stehen, auch nicht das gerade eingegebene Passwort. Analytics darf den Klartext ebenfalls nicht mitnehmen. Erlaubt sind Skripte, Styles und Zählungen ohne Dateikörper. - Öffne die heruntergeladene
.lockoder.encin einem Hex-Viewer. Die ersten vier Byte sollen43 53 4C 4Bsein (ASCIICSLK). Weiter hinten steht der Klarnameprobe.txt— nicht der Testsatz selbst. - Zieh denselben Geheimtext zurück auf dieselbe Seite. Mit dem richtigen Passwort kommt der Testsatz; ein geändertes Zeichen muss scheitern, nicht einen Müllblock als Inhalt liefern.
- Erst danach die
.lockin die Cloud. Das Passwort in einer anderen Nachricht. In der Cloud-Vorschau ohne Passwort: Original nicht lesbar.
Die Dateiverschlüsselung von MyPassGen hält diese Grenze: AES-256-GCM, PBKDF2 100.000 mal, eine Datei bis 5 GB, Ausgabe .lock / .enc. Die Rechnung läuft im aktuellen Tab, ohne Konto. Vertrauen sollst du Network und Dateikopf, nicht den fünf Wörtern «wird nicht hochgeladen» auf der Seite.
Kurze Geheimnisse nicht als ganze Datei
Ein API-Key, ein Recovery-Code, ein Datenbankpasswort muss nicht erst in eine Datei. Der ganze Dateiweg passt zu Zertifikatspaketen, Exporttabellen, Image-Schnitten. Kurzer Text gehört in einen Einmal-Link: Klartext höchstens 32 KB, der Server hält nur Geheimtext, der Schlüssel steht hinter #, Abrufe und TTL sind setzbar. Erzeugen und Lesen ohne Login.
Beim Weiterleiten von Anleitungen ist die URL eine eigene Arbeit. Adressen mit utm_source behandelst du nach welchen Parametern du streichen darfst; Telefon und Ausweisnummer im Ticket nach welchen Feldern du maskieren musst. Eine verschlüsselte Datei beantwortet «der Speicherort öffnet den Inhalt nicht», nicht «im Chat steht keine volle Nummer».
Häufige Irrtümer
«Die Cloud schreibt verschlüsselt, also sehe nur ich die Datei.» Hält der Anbieter den Schlüssel, bleiben Betrieb, Herausgabe und ein geklautes Konto bei einer nutzbaren Datei. Lokal zuerst engt «wer öffnen kann» auf die Person mit Passwort ein.
«HTTPS schützt den ganzen Weg.» HTTPS endet am Eingang des Anbieters. Danach wechselt, wer die abgelegte Kopie schützt. Weniger Klartext willst du in genau dieser Kopie.
«Endung auf .lock reicht.» Umbenennen ohne authentisierte Verschlüsselung: Der Editor findet den Originalsatz weiter. Der Kopf braucht die vereinbarte Magie, der Inhalt darf sich nicht öffnen lassen. Nur die Endung zu ändern ist nichts.
«Vergessenes Passwort holt der Support zurück.» Bei dieser Ablage gibt es keine Serverkopie des Passworts. Im Footer steht auch keine Adresse, über die sich ein «Reset» holen ließe. Das Passwort lebt in deinem eigenen Manager oder auf einem zweiten Kanal, den du selbst hältst.
Wo du anfängst
Nimm die Datei, die heute hoch soll. Lauf die sechs Schritte mit einer wegwerfbaren Kleindatei: Network ohne Original, Kopf CSLK, falsches Passwort scheitert. Dann die echte Datei. Ist der Name heikel, zuerst umbenennen.
Geheimtext in die Cloud oder als Anhang; Passwort persönlich, telefonisch oder als Einmal-Link. Kein Passwort in einer Textdatei daneben. Danach kannst du die Ausgangsfrage beantworten: Die Cloud-Seite soll keinen Klartext bekommen; das Passwort soll nicht denselben Weg nehmen wie der Geheimtext; der Dateikopf kann den alten Namen noch zeigen — das behandelst du extra.
Häufige Fragen
Was unterscheidet den Cloud-Tresor vom lokalen Verschlüsseln?
Den Tresor hält oder verwaltet meist der Anbieter; dasselbe Konto öffnet die Datei. Nach lokalem Verschlüsseln hat die Cloud-Seite kein Passwort für den Inhalt. Bei Konto-Diebstahl lädt jemand ohne Passwort nur Geheimtext.
Geht Entschlüsseln noch, wenn das Passwort weg ist?
Nein. Kein Klartext und kein Passwort-Backup auf dem Server. Nimm ein langes Zufallspasswort und lege es getrennt in deinem eigenen Manager ab. Das ist der symmetrische Preis dafür, dass der Speicherort den Inhalt nicht sieht.
Worin unterscheiden sich .lock und .enc?
Auf dieser Seite derselbe Container, andere Endung. Beide Suffixe lassen sich zurück auf die Seite ziehen. Geh nicht davon aus, dass ein fremdes .enc denselben Kopf versteht.
Brauche ich ein Konto? Wird die Datei hochgeladen?
Kein Konto. Das Log-Risiko beginnt, wenn du das Original einer Seite gibst, die «für dich» rechnet. Lokal bleiben Datei und Passwort im aktuellen Tab. Zu prüfen ist: Steht im Network ein Dateikörper oder ein Passwort — und findest du den Testsatz noch in der .lock?