Eine Datei braucht mehr als ein geheimes Aussehen.
Du möchtest einer Kollegin eine interne Projektdatei schicken. Niemand auf dem Transportweg soll sie lesen können. Die Kollegin muss außerdem erkennen, ob die Datei verändert wurde und ob sie tatsächlich von dir stammt. Drei ähnliche Wünsche führen zu drei verschiedenen Sicherheitsfragen: Vertraulichkeit schützt den Inhalt vor Unbefugten, Integrität macht unerlaubte Veränderungen erkennbar, Authentizität betrifft die überprüfbare Herkunft beziehungsweise die beteiligte Gegenstelle.
Eine unlesbar aussehende Datei beantwortet diese Fragen noch nicht. Sie könnte nur anders codiert sein, unbemerkt manipuliert werden oder von einer völlig anderen Person kommen. Kryptografie bietet mathematische Bausteine für konkrete Schutzziele. Damit daraus ein sicherer Ablauf wird, müssen Schlüssel, Programme, Übertragungswege und die Prüfung beim Empfänger zusammenpassen. Dieser Artikel erklärt die Aufgabenverteilung. Er baut bewusst kein eigenes Verschlüsselungsprogramm.
Die Begriffe begegnen dir später bei HTTPS und Zertifikaten, VPNs, Passkeys und verschlüsselten Backups wieder. Dort werden die Bausteine in Protokolle und betriebliche Verfahren eingebettet. Ein korrektes Verfahren löst jeweils einen bestimmten Teil des Problems.
Symmetrische Verschlüsselung braucht ein gemeinsames Geheimnis.
Bei symmetrischer Verschlüsselung verwenden Sender und Empfänger denselben geheimen Schlüssel. Der Sender verarbeitet Klartext mit einem geeigneten Verfahren zu Chiffretext. Der Empfänger kann mit dem passenden Schlüssel wieder Klartext erhalten. Moderne Verfahren sind für große Datenmengen geeignet: Eine lange Datei muss nicht mit einem langsamen öffentlichen Schlüsselverfahren vollständig verarbeitet werden.
Der Schlüssel ist keine beliebig gewählte kurze Zeichenfolge. Anwendungen erzeugen kryptografische Schlüssel mit einem geeigneten Zufallszahlengenerator. Ein menschliches Passwort besitzt andere Eigenschaften und muss bei passwortbasierter Verschlüsselung zunächst durch eine geeignete Schlüsselableitung verarbeitet werden. Base64 ist dagegen nur eine Darstellung von Bytes; jeder kann sie ohne Geheimnis zurückwandeln. Codierung schafft keine Vertraulichkeit.
Die schwierige Frage lautet deshalb: Wie erhalten beide Seiten den Schlüssel, ohne ihn einem Mitleser zu geben? Ein Schlüssel neben dem verschlüsselten Anhang in derselben ungeschützten Nachricht beseitigt den Schutz. Ein gesonderter, überprüfter Kanal oder ein etabliertes Verfahren zur Schlüsselvereinbarung kann diese Aufgabe übernehmen. Auch die Berechtigung zählt: Wer denselben Schlüssel besitzt, kann normalerweise entschlüsseln und gültig geschützte Nachrichten erzeugen.
AEAD verbindet Verschlüsselung mit Integritätsschutz.
Eine reine Verschlüsselungsfunktion garantiert nicht automatisch, dass Veränderungen erkannt werden. Deshalb verwenden moderne Protokolle Authenticated Encryption with Associated Data, kurz AEAD. Beispiele sind AES-GCM und ChaCha20-Poly1305. Neben verschlüsselten Daten entsteht ein Authentifizierungstag. Die empfangende Implementierung prüft diesen Tag und darf bei fehlgeschlagener Prüfung keinen vermeintlich brauchbaren Klartext zur weiteren Verarbeitung freigeben.
AES-GCM kombiniert das Blockchiffreverfahren AES mit dem Galois/Counter Mode. ChaCha20-Poly1305 verbindet eine Stromchiffre mit einem Authentifikator. Die genaue Auswahl hängt unter anderem von Bibliothek, Plattform und Protokoll ab. Eine selbst zusammengestellte Reihenfolge aus „irgendwie verschlüsseln, dann einen Hash anhängen“ ersetzt diese geprüften Konstruktionen nicht. Für Anwendungen sind gepflegte, höher abstrahierende Bibliotheken oder bestehende Dateiformate der sinnvollere Einstieg.
AEAD benötigt außerdem eine Nonce, einen pro Schlüssel passend behandelten Einmalwert. Bei AES-GCM und der IETF-Variante von ChaCha20-Poly1305 darf dieselbe Nonce unter demselben Schlüssel nicht wiederverwendet werden. Eine Wiederverwendung kann Vertraulichkeit und Authentizität schwer beschädigen. Die Nonce ist üblicherweise nicht geheim, muss aber die Vorgaben des Verfahrens erfüllen. Zufällige Werte, Zähler und Neustarts benötigen deshalb ein durchdachtes Gesamtkonzept; „zufällig“ allein beweist keine garantierte Einzigartigkeit.
Die zusätzlichen authentifizierten Daten werden geschützt, aber nicht verschlüsselt. Ein Protokoll kann darüber beispielsweise eine Formatversion an den Chiffretext binden. Metadaten bleiben dabei lesbar. Ein gültiger Tag verhindert außerdem nicht automatisch die erneute Zustellung einer alten gültigen Nachricht. Gegen Wiederholungen braucht das umgebende Protokoll passende Zustände, Sequenznummern oder Frischeprüfungen.
Öffentliche Schlüssel lösen andere Aufgaben als gemeinsame Schlüssel.
Asymmetrische Kryptografie arbeitet mit zusammengehörigen öffentlichen und privaten Schlüsseln. Der öffentliche Teil darf verteilt werden; der private Teil bleibt ausschließlich unter Kontrolle seines Besitzers. Bei einem geeigneten Verschlüsselungsverfahren wird für den Empfänger mit dessen öffentlichem Schlüssel verschlüsselt. Zum Entschlüsseln benötigt er seinen privaten Schlüssel. Daraus folgt nicht, dass jedes asymmetrische Schlüsselpaar für Verschlüsselung geeignet ist: Ein Signaturschlüssel erfüllt eine andere Aufgabe.
Bei einer Schlüsselvereinbarung berechnen zwei Seiten aus eigenen privaten und ausgetauschten öffentlichen Beiträgen ein gemeinsames Geheimnis. Ephemeres Diffie-Hellman auf elliptischen Kurven ist ein wichtiges Beispiel. Der spätere symmetrische Verkehrsschlüssel wird daraus über eine definierte Ableitung gewonnen; er wird nicht einfach offen verschickt. Authentifizierung muss die Beiträge an die richtige Gegenstelle binden, sonst könnte ein Vermittler zwei getrennte Verbindungen aufbauen.
Asymmetrisch bedeutet deshalb nicht pauschal sicherer. Hybride Verfahren verbinden geeignete asymmetrische Operationen mit effizientem symmetrischem Schutz. Entscheidend sind Sicherheitsniveau, authentische Schlüssel und korrekte Verwendung. Bei vorwärtsgeheimen Protokollen können kurzlebige Vereinbarungsgeheimnisse nach Gebrauch gelöscht werden. Ein später gestohlener langfristiger Identitätsschlüssel soll dann nicht automatisch früher aufgezeichnete Sitzungen entschlüsselbar machen.
Ein Hash ist ein Fingerabdruck ohne Absendernachweis.
Eine kryptografische Hashfunktion verarbeitet Daten zu einem Wert fester Länge. SHA-256 liefert 256 Bit, dargestellt oft als 64 hexadezimale Zeichen. Derselbe Byteinhalt ergibt denselben Hash. Bereits ein anderer Zeilenumbruch kann einen anderen Wert erzeugen. Der Hash beschreibt also Bytes, nicht die inhaltliche Bedeutung eines Dokuments. Man kann ihn nicht mit einem geheimen Schlüssel wieder zum ursprünglichen Dokument entschlüsseln.
Gute kryptografische Hashfunktionen erschweren unter anderem das Finden verschiedener Eingaben mit gleichem Hash und das Finden einer Eingabe zu einem vorgegebenen Wert. Weil beliebig viele Eingaben auf endlich viele Ausgaben treffen, existieren mathematisch trotzdem Kollisionen. Die praktische Sicherheitsfrage ist, ob Angreifer relevante Kollisionen mit vertretbarem Aufwand finden können. Ein Hash ist kein Beweis dafür, dass eine Datei harmlos ist.
Für den Downloadvergleich benötigst du einen vertrauenswürdigen Referenzwert. Ersetzt ein Angreifer auf derselben kompromittierten Seite sowohl die Datei als auch ihren angezeigten SHA-256-Wert, stimmt der Vergleich mit der manipulierten Version überein. Ein unabhängig authentifizierter Referenzkanal oder eine überprüfte Signatur löst eine andere Aufgabe als die reine Berechnung. Bei kurzen, erratbaren Eingaben kann ein Angreifer außerdem Kandidaten hashen und vergleichen; Einwegfunktion bedeutet nicht Unerratbarkeit.
HMAC und Signaturen beantworten unterschiedliche Vertrauensfragen.
HMAC kombiniert eine geeignete Hashfunktion mit einem gemeinsamen geheimen Schlüssel. Beide Seiten können einen Authentifizierungscode berechnen und prüfen. Ein gültiger Code belegt unter den Sicherheitsannahmen die Unverändertheit und Herkunft aus dem Kreis der Schlüsselinhaber. Besitzen fünf Dienste denselben Schlüssel, kann jeder dieser Dienste gültige HMACs erzeugen. Der Code beweist dann nicht, welcher einzelne Dienst eine Nachricht geschrieben hat.
Eine digitale Signatur wird dagegen mit dem privaten Signaturschlüssel erzeugt und mit dem zugehörigen öffentlichen Schlüssel geprüft. Der Prüfer muss den privaten Schlüssel nicht besitzen. Das ist für Softwareveröffentlichungen nützlich: Viele Empfänger können eine Freigabe prüfen, ohne selbst Freigaben im Namen des Herausgebers erzeugen zu können. Signaturverfahren verwenden definierte Verarbeitungsschritte; „mit dem privaten Schlüssel verschlüsseln“ ist keine allgemein richtige Erklärung.
Eine gültige Signatur bindet Daten an einen Schlüssel, nicht von selbst an einen vertrauenswürdigen Menschen. Du musst den öffentlichen Schlüssel authentisch erhalten, beispielsweise über eine überprüfte Organisationsfreigabe. Außerdem muss klar sein, welche Datei, Version und Verwendung signiert wurden. Eine korrekt signierte veraltete Anwendung kann bekannte Schwachstellen besitzen. Ein gestohlener Signaturschlüssel kann bis zu wirksamen Gegenmaßnahmen scheinbar gültige Freigaben erzeugen.
Passwörter benötigen absichtlich aufwendige Verarbeitung.
SHA-256 ist für schnelles Hashen großer Datenmengen ausgelegt. Für Passwortspeicherung ist genau diese Geschwindigkeit nach einem Datenbankdiebstahl ungünstig: Angreifer können sehr viele Passwortkandidaten berechnen. Ein Salt macht aus einem schnellen Hash noch kein geeignetes Passwortverfahren. Passwörter sollten mit einer dafür vorgesehenen Passwort-KDF verarbeitet werden, etwa Argon2id. KDF steht für Key Derivation Function, also Schlüsselableitungsfunktion; solche Funktionen können auch Passwortverifikatoren erzeugen.
Argon2id verursacht gezielt Rechen- und Speicheraufwand. Ein zufälliger, individueller Salt sorgt dafür, dass gleiche Passwörter nicht einfach überall denselben gespeicherten Verifikator ergeben und vorberechnete Tabellen weniger nützen. Der Salt darf zusammen mit Algorithmus, Version, Parametern und Ergebnis gespeichert werden. Er ist kein geheimer zweiter Faktor. Ein zusätzlich separat geschütztes Geheimnis, häufig Pepper genannt, hat andere Anforderungen und ersetzt keinen Salt.
Die Parameter müssen zum Dienst passen: zu billig erleichtert Offline-Raten, zu teuer kann Anmeldungen unter Last überfordern. Gepflegte Bibliotheken stellen geprüfte APIs, sichere Salt-Erzeugung und Möglichkeiten zur späteren Parameteranhebung bereit. Beim erfolgreichen Login kann ein veralteter Verifikator nach Bibliotheksvorgaben erneuert werden. Auch Argon2id rettet kein bekanntes oder sehr leicht erratbares Passwort. Einzigartige Passwörter, Begrenzung von Online-Versuchen und geeignete MFA bleiben erforderlich.
Plane die Dateiübertragung als vollständigen Ablauf.
Für unsere Projektdatei klären beide Seiten zuerst, welcher freigegebene Austauschdienst beziehungsweise welches etablierte Dateiverschlüsselungswerkzeug eingesetzt wird. Die Empfängeridentität und ihr öffentlicher Schlüssel werden über einen bereits überprüften Weg bestätigt. Ein neuer Schlüssel aus derselben unbekannten Nachricht genügt dafür nicht. Das Werkzeug übernimmt anschließend Schlüsselerzeugung, Dateiformat, AEAD und Nonce-Verwaltung. Es gibt hier keine kopierbare Eigenbau-Krypto.
- Empfänger festlegen: Stimmt die adressierte Person, und ist ihr Schlüssel aktuell und authentisch?
- Vertraulich übertragen: Ein geeignetes etabliertes Verfahren verschlüsselt für den Empfänger und prüft Manipulationen.
- Herkunft bei Bedarf zusätzlich belegen: Eine überprüfte Signatur mit getrenntem Signaturschlüssel bindet die freigegebene Dateiversion an den Absender.
- Ergebnis kontrollieren: Fehlgeschlagene Prüfungen führen zum Abbruch. Die Datei wird nicht trotz Warnung geöffnet oder weiterverarbeitet.
- Aufbewahrung planen: Berechtigte Empfänger, temporäre Klartextkopien, Backups und spätere Schlüsselverluste werden berücksichtigt.
Die Verschlüsselung schützt den Transport und gegebenenfalls die gespeicherte Datei. Sobald die Kollegin sie auf einem kompromittierten Gerät öffnet, kann Schadsoftware den Klartext lesen. Ein versehentlich falsch berechtigtes Ziel bleibt ebenfalls falsch berechtigt. Kryptografie ersetzt deshalb weder eine Empfängerprüfung noch Betriebssystemschutz, nachvollziehbare Freigaben oder sichere Lösch- und Aufbewahrungsverfahren.
Schlüsselverwaltung entscheidet über den praktischen Schutz.
Schlüssel gehören weder in öffentliche Repositories noch in Chatverläufe oder gemeinsam genutzte Konfigurationskopien. Zugriffe sollten auf die tatsächlich benötigten Prozesse und Personen begrenzt sein. Je nach Einsatz helfen Betriebssystem-Schlüsselspeicher, Hardwaremodule und getrennte Berechtigungen. Ein geplanter Schlüsselwechsel benötigt eine Verteilung neuer Schlüssel, einen kontrollierten Übergang und eine Behandlung alter Daten. Einfaches Löschen des alten Schlüssels kann verschlüsselte Archive dauerhaft unlesbar machen.
Dokumentiere deshalb, wer Schlüssel erzeugt, wer sie nutzen darf, wie ihre Echtheit geprüft wird und wie im Verlustfall reagiert wird. Eine Sicherung der Daten ohne erreichbaren Entschlüsselungsschlüssel reicht nicht. Eine Schlüsselsicherung direkt neben allen verschlüsselten Backups kann dagegen die Trennung aufheben. Verfügbarkeit und Vertraulichkeit müssen gemeinsam geplant und mit harmlosen Testdaten überprüft werden.
Typische Fehlannahmen lassen sich nun einordnen: Ein Hash ist keine Verschlüsselung, eine Signatur verbirgt keinen Inhalt und HMAC identifiziert innerhalb einer Schlüsselgruppe keinen einzelnen Absender. Ein langer Algorithmusname kompensiert keine Nonce-Wiederverwendung. Und „militärisch verschlüsselt“ sagt ohne überprüfbares Verfahren und Schlüsselkonzept wenig aus. Für den nächsten Schritt zeigt TLS, wie diese Aufgaben in einem etablierten Protokoll zusammenkommen.
Ordne Schutz und Vertrauensannahmen zu.
Aufgabe 1: Eine Downloadseite zeigt neben einer Datei deren SHA-256-Wert. Beide werden vom selben kompromittierten Server geliefert. Der berechnete Hash stimmt. Ist die Herkunft damit bewiesen? Was würde eine Signatur zusätzlich benötigen?
Lösung: Der Vergleich bestätigt nur den angebotenen Referenzwert.
Der Angreifer kann Datei und Hash gemeinsam ersetzen. Der passende Hash beweist keine Absenderidentität. Eine Signatur kann die Herkunft an einen Signaturschlüssel binden, wenn der Empfänger den richtigen öffentlichen Schlüssel unabhängig authentifiziert und die Signatur korrekt prüft. Auch dann muss die signierte Version für den Einsatzzweck geeignet und aktuell sein. Verschlüsselt ist die Datei durch Hash oder Signatur weiterhin nicht.
Aufgabe 2: Drei Dienste teilen einen HMAC-Schlüssel. Ein gültiger Code liegt vor. Ein Entwickler möchte außerdem AES-GCM mit fester Nonce verwenden und Passwörter als SHA-256 plus individuellem Salt speichern. Welche drei Schlussfolgerungen beziehungsweise Änderungen sind nötig?
Lösung: Gruppenherkunft, Nonce-Eindeutigkeit und Passwort-KDF getrennt betrachten.
Der HMAC kann von jedem der drei Schlüsselinhaber stammen und ordnet die Nachricht keinem einzelnen Dienst zu. Bei AES-GCM darf die Nonce unter demselben Schlüssel nicht wiederverwendet werden; eine geeignete Bibliothek und ein passendes Format müssen ihre Verwaltung übernehmen. Für Passwörter ist eine geeignete Passwort-KDF wie Argon2id mit individuellem Salt und angemessenen Parametern erforderlich. Ein Salt beseitigt die hohe Rate möglicher SHA-256-Rateversuche nicht.
Quellen und fachlicher Stand.
Fachlich geprüft am . Diagramme und Dateiübertragung sind eigene didaktische Modelle, keine Implementierungsanleitung. Sicherheitsparameter gehören zum konkreten aktuellen Protokoll beziehungsweise zur gepflegten Bibliothek.
- NIST FIPS 180-4 – SHA-256 und kryptografische Hashfunktionen; Überarbeitung angekündigt.
- RFC 2104 – HMAC-Konstruktion; historische Algorithmusbeispiele sind keine aktuelle Auswahlhilfe.
- NIST FIPS 186-5 und libsodium: Signaturen – Signieren und öffentliches Prüfen.
- NIST SP 800-38D, RFC 8439 und libsodium: AEAD – AES-GCM, ChaCha20-Poly1305 und Nonce-Anforderungen; NIST-Überarbeitung angekündigt.
- RFC 9106 und libsodium: Passwort-Hashing – Argon2id, Salt und parametrierbare Passwortableitung.
- RFC 9846 – TLS 1.3 als Beispiel authentifizierter Schlüsselvereinbarung und hybrider Nutzung.
- NIST SP 800-63B-4 – Passwortverifikatoren und ergänzende Anmeldeschutzmaßnahmen.
- libsodium: Authenticated encryption – Kombination öffentlicher und privater Schlüssel in einer definierten Konstruktion.