Entwicklertools · SHA-Hash-Rechner
Kryptografischer Hash vs. Prüfsumme: Was CRC32 und xxHash nicht versprechen können
· Hintergrund
sha-256 Kryptographie Sicherheit
CRC32, FNV und xxHash sind ebenfalls Hashes, aber sie geben keine Versprechung gegenüber einem Gegner ab. In diesem Beitrag wird erklärt, was kryptografische Hashes von Prüfsummen unterscheidet und wie man sie pro Anwendungsfall auswählt.
Welcher Hash für welchen Job? — die Wahl zwischen Geschwindigkeit und gegnerischer Sicherheit
Hash-Funktionen gibt es in drei Kategorien: Prüfsummen zur Erkennung versehentlicher Fehler, nicht-kryptografische Hashes für Verteilung und Leistung sowie kryptografische Hashes für die Sicherheit. Jede Kategorie hat unterschiedliche Garantien und unterschiedliche Kompromisse in Bezug auf Geschwindigkeit und Digest-Größe. Eine Prüfsumme wie CRC32 ist schnell und kurz (4 Bytes, 8 Hexadezimalzeichen), bietet aber keinen Schutz vor absichtlicher Änderung. Ein nicht-kryptografischer Hash wie xxHash oder MurmurHash ist ebenfalls schnell und nützlich für Hash-Tabellen und die Datenverteilung, bietet aber keinen Schutz vor einem Gegner, der eine Kollision verursachen möchte. Ein kryptografischer Hash wie SHA-256 ist langsamer und erzeugt einen längeren Digest (32 Bytes, 64 Hexadezimalzeichen), bietet aber Preimage-Resistenz und Kollisionsresistenz – Sicherheitseigenschaften, die vor einem Angreifer schützen.
Die Wahl der falschen Hash-Funktion für Ihren Anwendungsfall ist ein häufiger Sicherheitsfehler. Die Verwendung von CRC32 zur Überprüfung von Dateidownloads von einer nicht vertrauenswürdigen Quelle ist wirkungslos. Ein Angreifer kann die Datei leicht ändern und den CRC32 neu berechnen. Die Verwendung von SHA-256 als schnelle Hash-Funktion in einer Hochfrequenz-Hash-Tabelle ist verschwenderisch; CRC32 oder ein schneller nicht-kryptografischer Hash ist ausreichend und günstiger.
Prüfsummen für versehentliche Fehler – CRC-Design zur Erkennung von Bit-Flips bei der Übertragung
Prüfsummen dienen der Fehlererkennung bei der Übertragung oder Speicherung, wobei davon ausgegangen wird, dass Fehler zufällig und zufällig sind. CRC (Cyclic Redundancy Check) wurde ursprünglich zur Erkennung von Bit-Flips in der Kommunikation entwickelt. Ein CRC32 erzeugt einen 32-Bit-Digest. Wenn ein Frame durch zufällige Bitwechsel während der Übertragung beschädigt wird, ändert sich mit ziemlicher Sicherheit der CRC32 und weist den Empfänger darauf hin, eine erneute Übertragung anzufordern. CRC kann je nach Polynom bis zu einer bestimmten Anzahl von Bitfehlern erkennen; In den meisten Anwendungsfällen wird ein einzelner Bit-Flip oder eine Reihe von Bit-Flips zuverlässig erkannt.
CRC ist deterministisch, aber nicht kryptografisch. Anhand einer Datei und ihres CRC32 kann ein Angreifer die Datei ändern und den CRC32 neu berechnen, um ihn an den erwarteten Wert anzupassen. Für einen Gegner mit Kenntnissen des CRC-Polynoms ist es einfach, eine Kollision herbeizuführen. CRC war nie dazu gedacht, absichtlichen Änderungen zu widerstehen; Es dient lediglich der zufälligen Fehlererkennung. Historische Systeme wie ZIP-Dateien und JPEG-Dateien verwenden CRC für diesen Zweck. Moderne Protokolle nutzen CRC zur schnellen Fehlererkennung innerhalb verschlüsselter oder authentifizierter Kanäle und nicht als eigenständige Integritätsprüfung.
Nicht-kryptografische Hashes zur Verteilung – FNV, MurmurHash und xxHash in Hash-Tabellen und Partitionierung
Nicht-kryptografische Hashes wie FNV-1a, MurmurHash und xxHash sind auf Geschwindigkeit und Einheitlichkeit bei Hash-Tabellen und Datenpartitionierung ausgelegt. Sie haben eine sehr geringe Latenz und werden in Situationen verwendet, in denen Sie Daten auf mehrere Server oder Buckets verteilen müssen, ohne sich um Sicherheitseigenschaften zu kümmern. Wenn Sie einen Cache erstellen und einen Schlüssel einer Bucket-Nummer zuordnen müssen, ist ein schneller Hash geeignet. MurmurHash wurde explizit für die Verwendung von Hash-Tabellen entwickelt und ist auf den meisten Hardwaregeräten schneller als SHA. xxHash ist neuer und optimiert für moderne CPUs mit großen Caches und Vektorisierung.
Diese Hashes sind nicht kryptografisch, da sie Preimage-Angriffen (Suchen einer Eingabe, die einen bestimmten Digest erzeugt) oder Kollisionsangriffen (Suchen zweier verschiedener Eingaben, die denselben Digest erzeugen) nicht widerstehen. Ein Angreifer kann den Hash-Algorithmus berechnen und Eingaben finden, die kollidieren oder eine Zielausgabe erzeugen. In einer vertrauenswürdigen Umgebung (einem Cluster, in dem alle Knoten unter Ihrer Kontrolle stehen) ist dies akzeptabel. Wenn ein nicht vertrauenswürdiger Benutzer die Eingabe kontrollieren kann, ist ein nicht kryptografischer Hash anfällig für Kollisionsangriffe, die die Leistung beeinträchtigen (der schlimmste Fall einer Hash-Tabelle ist die lineare Suche, wenn alle Schlüssel kollidieren) oder andere Nebenwirkungen hervorrufen.
Was kryptografische Hashes hinzufügen – Vorbild- und Kollisionsresistenz gegen einen vorsätzlichen Angreifer
Kryptografische Hashes wie SHA-256, SHA-384 und SHA-512 bieten Widerstand gegen Vorbilder: Bei einem gegebenen Digest ist es rechnerisch unmöglich, Eingaben zu finden, die diesen Digest erzeugen. Sie bieten außerdem Kollisionsresistenz: Es ist rechnerisch unmöglich, zwei verschiedene Eingaben zu finden, die denselben Digest erzeugen. Diese Eigenschaften schützen vor einem Angreifer, der einen Download fälschen, ein gefälschtes Zertifikat erstellen oder eine Nachricht manipulieren möchte. Der Preis ist die Geschwindigkeit: SHA-256 ist auf den meisten Hardwaregeräten langsamer als CRC32 und langsamer als xxHash.
SHA-1 ist kryptografisch fehlerhaft (Kollisionen sind praktisch) und sollte nicht für neue Sicherheitszwecke verwendet werden, wird aber dennoch aus Gründen der Legacy-Kompatibilität berechnet. SHA-256, SHA-384 und SHA-512 bleiben stark und sind die Standardauswahl für kryptografisches Hashing. Das „2“ in SHA-2 weist auf die zweite Familie von SHA-Algorithmen hin (der erste ist der ursprüngliche SHA-1; SHA-3 ist eine neuere Familie, wird aber selten für diesen Zweck verwendet).
Kryptografische Hashes fügen kontroverse Eigenschaften hinzu; Dieser Artikel vermeidet nicht unterstützte Relativgeschwindigkeitsbehauptungen
Zuordnung von fünf Szenarien zur richtigen Hash-Familie: Erstens: Netzwerkrahmen, die über einen zuverlässigen Kanal übertragen werden, der mit AES verschlüsselt ist: CRC32 ist geeignet. Die Verschlüsselung schützt vor Änderungen und der CRC erkennt versehentliche Beschädigungen. Zweitens Hash-Tabellen oder konsistentes Hashing für den Lastausgleich: Ein nicht-kryptografischer Hash wie xxHash ist geeignet. Geschwindigkeit ist wichtig und der Umwelt vertraut man. Drittens ist die Überprüfung der Download-Integrität von einer nicht vertrauenswürdigen Quelle erforderlich: SHA-256. Ein Angreifer könnte die Datei und die Prüfsumme ändern, nicht jedoch den kryptografischen Hash, ohne SHA-256 zu beschädigen.
Viertens digitale Signaturen und Zertifikate: SHA-256 ist erforderlich und wird mit einem asymmetrischen Algorithmus wie RSA oder ECDSA kombiniert. Die Signatur beweist, dass der Hash nach der Signatur nicht verändert wurde. Fünftens ist die Deduplizierung der vom Benutzer hochgeladenen Dateien: SHA-256 erforderlich, da Benutzer absichtlich Dateien hochladen könnten, die so gestaltet sind, dass sie mit vorhandenen Dateien in einem nicht-kryptografischen Hash kollidieren. Wenn die Deduplizierung auf xxHash basiert, kann ein Angreifer eine Datei mit demselben Hash wie eine andere Datei, aber unterschiedlichem Inhalt hochladen, was dazu führt, dass das System den Upload fälschlicherweise verwirft.
Ausgearbeitetes Beispiel – Zuordnung von fünf Szenarien (Netzwerk-Frames, Hash-Maps, Download-Verifizierung, Signaturen, Deduplizierung von Benutzer-Uploads) zur richtigen Familie
Die Kosten für die Auswahl eines kryptografischen Hashs für jeden Anwendungsfall sind ein Leistungsaufwand. SHA-256 ist langsamer als CRC und langsamer als xxHash. In einer Hot-Loop – einem Code, der Millionen Mal pro Sekunde ausgeführt wird – ist dieser Mehraufwand spürbar. In einer Einrichtungsphase oder im Batch-Betrieb ist es vernachlässigbar. Der Entscheidungsrahmen lautet: Hat ein Gegner einen Anreiz, eine Kollision zu verursachen? Wenn ja, verwenden Sie SHA-256. Wenn nein und wenn Geschwindigkeit wichtig ist, verwenden Sie einen schnelleren Hash. Wenn Sicherheit wichtiger ist als Geschwindigkeit, verwenden Sie trotzdem SHA-256.
Ein häufiger Fehler ist die Verwendung von MD5, einem älteren kryptografischen Hash, der jetzt fehlerhaft ist. MD5 wurde in 1992 entworfen und Kollisionen wurden in 2004 demonstriert. Die Verwendung von MD5 aus Sicherheitsgründen ist unsicher. Man sieht es manchmal in älteren Systemen und in Situationen, in denen Geschwindigkeit Priorität hat, aber es gibt kein Szenario, in dem MD5 heute die richtige Wahl ist: Wenn Sie Geschwindigkeit benötigen, verwenden Sie xxHash; Wenn Sie Sicherheit benötigen, verwenden Sie SHA-256. Verwenden Sie niemals MD5.
Die Szenariozuordnung bleibt qualitativ, da Durchsatz und Kollisionsverhalten umsetzungsspezifische Beweise erfordern
Passwort-Hashing ist eine vierte Kategorie, die sich sowohl von Prüfsummen als auch von allgemeinen kryptografischen Hashes unterscheidet. Verwenden Sie SHA-256 nicht zum Hashen von Passwörtern. Verwenden Sie stattdessen eine Passwort-Hashing-Funktion wie bcrypt, scrypt oder Argon2, die bewusst langsam sind und einen Salt enthalten. Ein schneller kryptografischer Hash wie SHA-256 macht das Erraten von Passwörtern kostengünstig: Ein Angreifer kann Millionen von Raten pro Sekunde versuchen. Eine Passwort-Hashing-Funktion soll dafür sorgen, dass jedes Erraten viel CPU- und Speicheraufwand verursacht, sodass das Erraten eines sicheren Passworts immer noch länger dauert, als ein Angreifer warten kann. Passwort-Hashing ist ein spezieller Anwendungsfall mit eigenen Anforderungen.
Der ToolAcre SHA-Hash-Rechner unterstützt kein Passwort-Hashing und bietet bewusst kein MD5, keine benutzerdefinierten Parameter und keine schnellen Hashes. Es handelt sich um ein Tool zur Berechnung von Standard-SHA-Digests zur Verifizierung und Integritätsprüfung, nicht zur Authentifizierung oder Passwortspeicherung.
Fazit: Gegner hin oder her – greifen Sie zum ToolAcre SHA-Hash-Rechner, wenn jemand die Daten manipulieren könnte
Die Wahl des Hash-Algorithmus ist eine grundlegende Entscheidung, die sich sowohl auf die Leistung als auch auf die Sicherheit im gesamten System auswirkt. Ein Digest ist nur so vertrauenswürdig wie der Algorithmus, der ihn erstellt hat. Wenn Sie CRC32 für die Dateiüberprüfung wählen, bietet der Digest keinen Schutz vor absichtlichen Änderungen. Wenn Sie SHA-256 für eine Hash-Tabelle wählen, verschwenden Sie Ressourcen. Wenn Sie die Eigenschaften und Kompromisse jeder Kategorie kennen, können Sie die richtige Auswahl treffen.
Der ToolAcre SHA-Hash-Rechner liefert SHA-1 bis SHA-512 und deckt damit die kryptografischen Hashes ab, die für die meisten Anwendungsfälle wichtig sind. CRC32, xxHash oder MD5 werden nicht angeboten, da jedes davon in bestimmten Kontexten die richtige Wahl ist (CRC für Fehlererkennung in einem vertrauenswürdigen Kanal, xxHash für Leistung in einer kontrollierten Umgebung, nichts für MD5), und wenn sie angeboten werden, ohne zu betonen, wann sie jeweils verwendet werden sollen, würden Fehler gefördert. Der Rechner dient zur Berechnung standardmäßiger kryptografischer Digests. Verwenden Sie die Befehlszeile mit `crc32`, `xxh64` oder gleichwertigen Tools, wenn Sie diese Hashes benötigen. Für Download-Verifizierung, Zertifikat-Fingerabdrücke, Git-Commits und ähnliche Anwendungsfälle, bei denen ein Angreifer die Daten manipulieren könnte, greifen Sie über den ToolAcre SHA-Hash-Rechner nach SHA-256.