Kann ich aus einem SHA-256-Hash den ursprünglichen Text rekonstruieren?

Nein, nicht durch Rückrechnung. Eine kryptografische Hash-Funktion ist als Einwegfunktion entworfen, mathematisch existiert kein inverser Algorithmus. Was angreiferseitig funktioniert, sind Wörterbuch-Angriffe und Rainbow-Tables: Wer den Hash eines kurzen oder vorhersagbaren Inputs sucht (etwa eines Passworts ohne Salt), kann durchprobieren. Für zufällige Eingaben mit ausreichender Entropie bleibt SHA-256 praktisch nicht umkehrbar. Wenn Vertraulichkeit das Ziel ist, verwenden Sie eine Verschlüsselung wie AES-GCM, kein Hash.

Warum ist eine digitale Signatur nicht einfach ein Hash?

Ein Hash beweist Integrität, aber nicht Urheberschaft. Jeder kann ihn berechnen. Eine Signatur kombiniert den Hash mit asymmetrischer Verschlüsselung: Der Signierende verschlüsselt den Hash mit seinem privaten Schlüssel, jeder andere kann mit dem öffentlichen Schlüssel verifizieren. Wer den privaten Schlüssel nicht besitzt, kann die Signatur nicht erzeugen. Deshalb verlangt eIDAS für qualifizierte Signaturen ein Schlüsselpaar, nicht nur einen Hash-Wert.

Welche Web-Crypto-API-Methode brauche ich wofür?

SubtleCrypto.digest erzeugt einen Hash, also einen Fingerabdruck ohne Schlüssel. SubtleCrypto.encrypt und SubtleCrypto.decrypt arbeiten mit symmetrischen Schlüsseln (AES-GCM, AES-CBC) oder asymmetrischen Schlüsseln (RSA-OAEP). SubtleCrypto.sign und SubtleCrypto.verify erzeugen und prüfen Signaturen (RSA-PSS, ECDSA, HMAC). Wer einfach nur einen Hash will, ruft digest auf. Wer Daten geheim halten will, encrypt. Wer Urheberschaft nachweisen will, sign.

Ist HMAC eine Signatur?

Nein, technisch ist HMAC ein Message Authentication Code mit symmetrischem Schlüssel. Sender und Empfänger teilen denselben Schlüssel. HMAC beweist Integrität und Authentizität gegenüber dem Schlüssel-Partner, aber nicht gegenüber Dritten, weil jeder Schlüsselinhaber den HMAC erzeugen könnte. Eine echte digitale Signatur (RSA, ECDSA) bindet die Urheberschaft an einen einzelnen privaten Schlüssel, den nur der Signierende kennt. HMAC eignet sich für API-Authentifizierung, Signaturen für rechtsverbindliche Erklärungen.

Reicht ein Hash für Passwort-Speicherung?

Nein. SHA-256 ist zu schnell, eine GPU rechnet Milliarden Hashes pro Sekunde. Für Passwörter brauchen Sie eine spezialisierte Funktion wie bcrypt, scrypt oder Argon2, die einen Cost-Faktor und einen pro-Nutzer-Salt eingebaut haben. SHA-256 ist für Integritätsprüfungen, Checksums und HMAC gedacht, nicht für Passwörter. Die OWASP empfiehlt aktuell Argon2id mit 19 MiB Memory, t=2, p=1 als Default.

Hash, Verschlüsselung, Signatur: was sie unterscheidet

Drei Probleme, drei Werkzeuge

In Code-Reviews tauchen die drei Begriffe Hash, Verschlüsselung und Signatur regelmäßig in derselben Diskussion auf, und regelmäßig redet jemand am Ziel vorbei. Hash, Verschlüsselung und Signatur lösen drei klar voneinander getrennte Probleme. Wer sie sauber trennt, baut robustere Systeme.

Ein Hash beantwortet die Frage: Hat sich diese Datei verändert? Eine Hash-Funktion nimmt beliebig lange Eingabe und produziert einen Fingerabdruck fester Länge (256 Bit bei SHA-256, 512 Bit bei SHA-512). Sie ist deterministisch (gleiche Eingabe, gleicher Hash), schnell und einseitig. Aus dem Hash lässt sich die Eingabe nicht zurückrechnen. Typische Anwendungen: Checksums beim Download, Git-Object-IDs, Merkle-Trees in Blockchain und IPFS.

Eine Verschlüsselung beantwortet die Frage: Wie halte ich diese Daten geheim? Sie ist reversibel, der Empfänger entschlüsselt mit dem passenden Schlüssel zurück zum Klartext. Symmetrische Verfahren wie AES-256 verwenden denselben Schlüssel für Encrypt und Decrypt, asymmetrische Verfahren wie RSA-OAEP arbeiten mit einem öffentlichen Schlüssel zum Verschlüsseln und einem privaten zum Entschlüsseln.

Eine digitale Signatur beantwortet die Frage: Stammt diese Nachricht wirklich vom angegebenen Absender? Sie kombiniert eine Hash-Funktion mit asymmetrischer Kryptografie: Der Hash der Nachricht wird mit dem privaten Schlüssel verschlüsselt, der Empfänger entschlüsselt mit dem öffentlichen Schlüssel und vergleicht mit einem selbst berechneten Hash der Nachricht. Stimmen beide überein, ist die Nachricht unverfälscht und stammt nachweisbar vom Inhaber des privaten Schlüssels.

Eigenschaften im Direktvergleich

Die drei Funktionen unterscheiden sich in vier zentralen Eigenschaften: Schlüssel-Bedarf, Reversibilität, Output-Länge und Schutzziel.

Eine Hash-Funktion braucht keinen Schlüssel. Jeder Beteiligte kann sie für jede Eingabe berechnen. Der Output ist immer gleich lang, unabhängig von der Eingabegröße (32 Byte bei SHA-256). Schutzziel ist Integrität, also der Nachweis, dass sich eine Datei nicht verändert hat. Wenn zwei Parteien dasselbe Dokument haben und beide den SHA-256 berechnen, müssen sie identisch sein. Eine Abweichung in einem Bit ändert den kompletten Hash (Avalanche-Effekt).

Eine symmetrische Verschlüsselung braucht einen geteilten Schlüssel, der beiden Kommunikationspartnern bekannt sein muss. Asymmetrische Verschlüsselung umgeht das Schlüsselaustausch-Problem mit einem Schlüsselpaar. Der Output ist mindestens so lang wie die Eingabe, plus Initialisierungsvektor und ggf. Authentication Tag (bei AEAD-Modi wie AES-GCM). Schutzziel ist Vertraulichkeit. Bei AES-GCM kommt Integrität durch den Authentication Tag dazu.

Eine Signatur braucht ein Schlüsselpaar, privater Schlüssel beim Signierenden, öffentlicher Schlüssel beim Verifizierenden. Der Output (die Signatur) ist fester Länge: 256 Byte bei RSA-2048, 64 Byte bei ECDSA mit P-256. Schutzziel ist Authentizität (Urheberschaft) plus Integrität. Wenn ein Bit der Nachricht verändert wurde, schlägt die Signaturprüfung fehl.

Vergleich der drei kryptografischen Primitive nach Schlüssel-Bedarf, Reversibilität und Schutzziel.

Web Crypto API: was wofür

Die im Browser eingebaute SubtleCrypto-Schnittstelle bietet für jede der drei Aufgaben eine eigene Methode. Die Trennung ist im API-Design absichtlich, sie verhindert, dass jemand einen Hash zum Verschlüsseln umzweckt.

Ein Hash entsteht mit crypto.subtle.digest('SHA-256', data). Die Methode akzeptiert ein ArrayBuffer und liefert ein ArrayBuffer zurück. Schlüssel sind nicht vorgesehen, denn ein Hash hat keinen. Unterstützt sind SHA-1 (nur noch für Altlast-Kompatibilität), SHA-256, SHA-384 und SHA-512. MD5 ist absichtlich nicht enthalten, weil RFC 6151 MD5 für kryptografische Zwecke für ungeeignet erklärt hat.

Verschlüsselt wird mit crypto.subtle.encrypt(algorithm, key, data). Vorher erzeugen oder importieren Sie einen Schlüssel mit crypto.subtle.generateKey oder crypto.subtle.importKey. Für symmetrische Verschlüsselung empfehlen aktuelle Best Practices AES-GCM mit 256-Bit-Schlüssel und einem pro Nachricht zufälligen 96-Bit-Nonce. AES-GCM ist ein AEAD-Verfahren, das Vertraulichkeit und Integrität in einem Schritt liefert.

Eine Signatur entsteht mit crypto.subtle.sign(algorithm, privateKey, data) und wird mit crypto.subtle.verify(algorithm, publicKey, signature, data) geprüft. Üblich sind RSA-PSS mit 2048 oder 3072 Bit Schlüssel oder ECDSA mit Kurve P-256 oder P-384. ECDSA-Signaturen sind kürzer und schneller, RSA-Signaturen sind weiter verbreitet in Legacy-Systemen.

Wo die Verwechslung wehtut

Drei typische Architekturfehler, die wir in Code-Reviews wiederholt sehen.

Fehler 1: “Wir hashen die Passwörter, das reicht.” Reicht nicht. Ein einfacher SHA-256 ohne Salt erlaubt Rainbow-Table-Angriffe, auch ein gesalzener SHA-256 fällt einer modernen GPU in Stunden bis Tagen. Passwörter brauchen bcrypt, scrypt oder Argon2 mit kalibriertem Cost-Faktor.

Fehler 2: “Wir verschlüsseln den Token mit dem Server-Secret, dann ist er authentisch.” Symmetrische Verschlüsselung beweist Authentizität nur gegenüber dem Schlüsselinhaber, nicht gegenüber Dritten. Wer eine signierte Behauptung gegenüber Externen braucht (z.B. ein JWT für Single-Sign-On), verwendet eine echte Signatur, etwa RS256 oder ES256 im JOSE-Format.

Fehler 3: “Wir berechnen einen Hash der Nachricht und schicken ihn mit.” Ein Hash neben der Nachricht schützt nicht vor einem Man-in-the-Middle, der beides verändert. Wer Integrität gegen aktive Angreifer braucht, signiert die Nachricht (RSA, ECDSA) oder verwendet HMAC mit einem gemeinsamen Schlüssel.

Empfehlung aus der Praxis

Wenn Sie eine Datei verschicken und der Empfänger soll prüfen können, dass sie unterwegs nicht beschädigt wurde, reicht ein SHA-256 als Checksum. Wenn Sie die Datei vertraulich halten wollen, verschlüsseln Sie zusätzlich. Wenn der Empfänger sicher sein soll, dass die Datei wirklich von Ihnen stammt, signieren Sie zusätzlich. In der Praxis kombinieren TLS, S/MIME und PGP alle drei Bausteine in einer Architektur.

Für die Auswahl der konkreten Algorithmen lohnt der Blick in unsere Methodik und die Autorenseite Mateusz, wo wir die Defaults dokumentieren, die wir für AKARA-Tools verwenden. Hinweise auf Fehler oder veraltete Empfehlungen gehen an die Korrekturen-Adresse.

Was hängenbleibt

Hash ist kein Ersatz für Verschlüsselung, Verschlüsselung kein Ersatz für Signatur. Die drei lösen Integrität, Vertraulichkeit und Authentizität, und keines davon ersetzt das andere. In der Web Crypto API sind die Funktionen sauber getrennt: digest für Hash, encrypt/decrypt für Verschlüsselung, sign/verify für Signatur. Wer in der Architekturdiskussion mit dem richtigen Begriff einsteigt, erspart sich später die Lücken-Diskussion.