Deutsch

Entwicklertools · SHA-Hash-Rechner

Warum Web Crypto SHA-1 bis SHA-512 anbietet, aber nicht MD5 oder SHA-3

· Wie es funktioniert

Kryptographie Browser-APIs sha-256 Javascript

Vier Algorithmusfelder mit der Bezeichnung SHA-1 bis SHA-512 mit Häkchen und entsprechenden fehlenden Feldern für MD5 und SHA-3
Original-ToolAcre-Vektorillustration

Die Digest-API des Browsers unterstützt genau vier Algorithmen. In diesem Beitrag wird erklärt, warum MD5 weggelassen wurde, warum SHA-3 nicht hinzugefügt wurde und was das für ein Tool bedeutet, das sich weigert, das zu liefern, was die Plattform nicht bereitstellt.

Wo ist MD5? – die erste Frage von jedem, der einen alten Prüfsummen-Workflow migriert

Die Web Crypto API des Browsers liefert genau vier Digest-Algorithmen: SHA-1, SHA-256, SHA-384 und SHA-512. Wenn Sie zum ToolAcre SHA-Hash-Rechner greifen und MD5 oder SHA-3 erwarten, werden Sie diese nicht finden. Diese Besonderheit stellt keine Einschränkung des Tools dar; es spiegelt eine bewusste Plattformwahl wider. Wenn Sie verstehen, warum diese vier einbezogen wurden und warum zwei beliebte Alternativen weggelassen wurden, erfahren Sie viel über die Gestaltung von Browser-APIs.

Jeder große Browser stellt crypto.subtle.digest auf sicheren Ursprüngen bereit. Wenn Ihr JavaScript diese Methode aufruft, wird sie an die kryptografische Implementierung der Plattform weitergeleitet – nativer Code, der mit Sicherheits-Sandboxing und Leistungsoptimierung ausgeführt wird. Die angebotenen Digest-Algorithmen wurden von der W3C Web Crypto Working Group mit bestimmten Prioritäten ausgewählt: Kompatibilität mit bestehenden Sicherheitsstandards, verfügbare Unterstützung für alle kryptografischen Bibliotheken, Reife und die praktischen Sicherheitsanforderungen der Webplattform.

Die vier Algorithmen, die SubtleCrypto.digest unterstützt – SHA-1, SHA-256, SHA-384 und SHA-512 und sonst nichts

ToolAcre akzeptiert die gleichen vier von DigestBytes erzwungenen Bezeichner: SHA-1, SHA-256, SHA-384 und SHA-512. Ein unbekannter Name wird zurückgewiesen, bevor Web Crypto aufgerufen wird, und die Testsuite besteht ausdrücklich MD5, um diese Zurückweisung zu bestätigen. Der Picker beschreibt daher eher eine getestete Produktgrenze als eine Übersicht über jeden jemals standardisierten Digest.

SHA-1, das in dieser Liste erscheint, gibt nicht alle vier gleichwertigen Empfehlungen ab. Sein Ergebnisobjekt trägt ein defektes Flag und die Schnittstelle wiederholt eine Legacy-Warnung; Die anderen drei sind die verfügbaren SHA-2-Auswahlmöglichkeiten. Verfügbarkeit und Eignung müssen getrennt bleiben, wenn ein Kompatibilitätstool einen alten Wert reproduziert, ohne eine neue Abhängigkeit davon zu fördern.

MD5 fehlt in dieser Implementierung und Web Crypto; In diesem Artikel wird keine unbegründete Begründung für Standards hinzugefügt

MD5 ist eine kryptografische Hash-Funktion, die einen 128-Bit-Digest erzeugt, was ihn kürzer und rechentechnisch günstiger macht als SHA-256. Jahrzehntelang war es die Standardlösung für Prüfsummen und digitale Signaturen. Allerdings ist die Kollisionsresistenz von MD5 grundsätzlich gebrochen. In 2004 demonstrierten Kryptographen praktische Kollisionen – zwei verschiedene Eingaben mit demselben Digest – und der Algorithmus wurde durch akademische Arbeiten gründlich zerlegt. Die mathematische Verwundbarkeit ist absolut und dauerhaft.

Die W3C-Web-Crypto-Spezifikation hat sich bewusst dafür entschieden, MD5 nicht einzubeziehen. Die Begründung ist einfach: Die Auslieferung eines defekten Algorithmus an Millionen von Browserbenutzern würde seine Verwendung in neuen Anwendungen normalisieren, auch wenn er nur in älteren Kompatibilitätsszenarien auftauchen sollte. Wenn eine Anwendung tatsächlich MD5 für die Interoperabilität mit alten Systemen benötigt, gehört dieser Code in eine serverseitige Laufzeitumgebung, in der die Anforderung verstanden und geprüft wird, und nicht in den Browser. Die bequeme Zugänglichkeit eines defekten Algorithmus würde Sicherheitserwartungen in neuen Systemen wecken.

Der ToolAcre SHA-Hash-Rechner liefert ebenfalls keine MD5-Implementierung aus. Ebenso wie die von ihr verwendete Plattform-API weigert sie sich, einen defekten Algorithmus bequem zugänglich zu machen. Wenn Ihre Anwendung unbedingt MD5 erfordert – was außerhalb älterer Git-Systeme selten vorkommt –, gehört die Implementierung in Ihre eigene Codebasis mit dem klaren Hinweis, dass es sich um ein Kompatibilitätsmodul handelt. Zugänglichkeit weckt Erwartungen, und kaputte Algorithmen verdienen keine Erwartungen.

SHA-3 liegt außerhalb der Browser-API und des Tools; Seine Adoptionsgeschichte liegt außerhalb des Repository-Beweises

SHA-3 wurde von NIST in 2015 nach einem langen öffentlichen Wettbewerb standardisiert und ist kryptografisch solide. Es verwendet eine grundlegend andere Konstruktion als SHA-2, einen sogenannten Schwamm, der je nach Hardware interessante theoretische Eigenschaften und Leistungskompromisse bietet. Auf modernen Systemen kann SHA-3 schneller sein als SHA-256. Doch die Browser-Plattform macht dies heute noch nicht sichtbar, und diese Verzögerung spiegelt praktische Entscheidungen über die Reife der Plattform und das Tempo der Einführung wider.

Die Verzögerung beim Versand von SHA-3 spiegelt die Realität wider: Web Crypto wurde entwickelt, um Algorithmen abzudecken, die im Web und in HTTPS am weitesten verbreitet sind./TLS. Bei der API-Finalisierung war SHA-2 (256, 384, 512) der überwältigende Konsens für neue Systeme. und die Umstellung auf SHA-3 erfolgt viel langsamer als die Umstellung von MD5 oder SHA-1. Die meisten Anwendungen benötigen SHA-3 noch nicht. Die Kosten für die Erweiterung der API und deren Tests auf allen Browsern und Plattformen waren durch die Nachfrage beim Start nicht gerechtfertigt.

Dies ist keine dauerhafte Ablehnung. Die Web Crypto API kann weiterentwickelt werden. Wenn sich die Einführung von SHA-3 beschleunigt, könnte die Arbeitsgruppe es hinzufügen. Der aktuelle Satz stellt die ausgereiften, weitgehend standardisierten Algorithmen dar, die Web Crypto benötigt, um den unmittelbaren Sicherheitsanforderungen der Plattform gerecht zu werden. Browser-APIs müssen stabil sein und sorgfältig gewartet werden; Das überstürzte Hinzufügen von Funktionen, bevor ein allgemeiner Bedarf besteht, führt zu Wartungsaufwand und Kompatibilitätsrisiken für die kommenden Jahre.

Warum es SHA-1 immer noch gibt – Legacy-Verifizierungsanforderungen und der Unterschied zwischen Anbieten und Empfehlen

SHA-1 ist in Web Crypto enthalten, obwohl es kryptografisch fehlerhaft ist. Diese kontraintuitive Wahl überrascht Entwickler oft. Der Algorithmus erzeugt einen 160-Bit-Digest, und Kollisionsangriffe gegen SHA-1 sind jetzt praktisch – zwei verschiedene Dokumente können so erstellt werden, dass sie denselben Digest teilen. Kollisionen mit ausgewählten Präfixen ermöglichen es Angreifern, während der Kollision zwei Dokumente zu erstellen, die beide von Bedeutung sind, wodurch Signaturen und Zertifikate beschädigt werden. Dennoch bleibt es in der Plattform.

SHA-1 bleibt aus einem notwendigen Grund in Web Crypto: Legacy-Kompatibilität. Git-Objektkennungen basieren auf SHA-1, und während das Git-Projekt auf SHA-256 übergeht, geben Millionen bestehender Repositorys, Referenzen und Build-Systeme immer noch SHA-1-Hashes aus. TLS-Zertifikat-Fingerabdrücke von älteren Systemen enthalten SHA-1-Digests. APIs, die vor Jahren HMAC-SHA1-Signaturen ausgegeben haben, müssen noch validiert werden. Diese bereitgestellten Systeme müssen überprüft oder migriert werden. Die Plattform umfasst SHA-1, um diese notwendige Arbeit zu ermöglichen.

Die Plattform-API enthält SHA-1 mit dem klaren Verständnis, dass es der Kompatibilität und nicht der Empfehlung dient. Die Benutzeroberfläche des Browsers kennzeichnet SHA-1 mit einer Warnung. Der ToolAcre SHA-Hash-Rechner zeigt neben dem SHA-1-Ergebnis „Kryptografisch fehlerhaft“ an und stellt so sicher, dass jeder, der ihn verwendet, versteht, dass er mit Legacy-Material arbeitet. Transparenz ist unerlässlich; Benutzer dürfen die SHA-1-Kompatibilität niemals mit der SHA-1-Befürwortung verwechseln.

Wenn die Kompatibilität MD5 erfordert, verwenden Sie eine überprüfte Implementierung außerhalb dieses Tools und verwechseln Sie niemals Kompatibilität mit Sicherheit

Die vier Algorithmen in Web Crypto sind auf das TLS-Cipher-Suite-Ökosystem und die wichtigsten Sicherheitsstandards abgestimmt. SHA-256 ist der aktuelle Standard für allgemeines Hashing, das bei Integritätsprüfungen von Unterressourcen, bei der Inhaltsadressierung und bei neuen Sicherheitssystemen verwendet wird. SHA-512 ist auf 64-Bit-Hardware schneller und bietet einen breiteren Digest. SHA-384 ist vor allem für seine Verwendung in TLS-Verschlüsselungssammlungen bekannt.

SHA-1 wird aus Gründen der Interoperabilität aufbewahrt, nicht weil jemand damit ein neues System starten sollte. Wenn Sie eine vorhandene SHA-1-Prüfsumme überprüfen, einen alten Zertifikatsfingerabdruck abgleichen oder eine Git-Commit-ID reproduzieren möchten, können Sie dies mit SHA-1 in ToolAcre tun. Wenn Sie ein neues System entwerfen, ist SHA-256 die offensichtliche Wahl. Der von Ihnen ausgewählte Algorithmus signalisiert Ihr Verständnis des Sicherheitsmodells.

Was dies nicht abdeckt – serverseitige Laufzeiten, die normalerweise viel mehr Digest-Algorithmen verfügbar machen

Wenn Ihre Anwendung wirklich MD5, SHA-3 oder einen anderen Algorithmus benötigt, ist die Wahl klar: Behalten Sie diesen Code in der serverseitigen Laufzeit und stellen Sie dem Browser nur das Endergebnis zur Verfügung. Versenden Sie nicht Ihre eigene JavaScript-Implementierung eines kryptografischen Algorithmus für die Verwendung im Browser. Die native Web-Verschlüsselung des Browsers ist schneller, sicherer und auf eine Art und Weise geprüft, mit der eine handgeschriebene JavaScript-Funktion nicht mithalten kann. Die Delegierung an die Plattform ist immer dann die richtige Wahl, wenn die Plattform das bereitstellt, was Sie benötigen.

Dies gilt auch für „einfache“ Algorithmen. Eine selbst geschriebene MD5-Implementierung mag harmlos erscheinen, da MD5 sowieso kaputt ist, aber kaputte Algorithmen haben keine Abstufungen – sie sind einfach kaputt. Mit der Auslieferung wird die Praxis der Implementierung von Kryptografie in Anwendungscode normalisiert. Der Browser stellt bereit, was die Plattform benötigt; nutzen, was es bietet. Handgefertigte Kryptografie ist die größte Einzelquelle für Sicherheitslücken in Webanwendungen, da Entwickler die Subtilität und Grenzfälle unterschätzen.

Takeaway: Einschränkungen sind Teil des Produkts – der ToolAcre SHA-Hash-Rechner bietet die vier Algorithmen, die der Browser nativ implementiert, und dokumentiert diese Grenze

Der ToolAcre SHA-Hash-Rechner zeigt diese Einschränkung direkt an: Sie sehen genau die vier Algorithmen, die Web Crypto bereitstellt, nicht mehr und nicht weniger. Wenn Sie einen Wert einfügen und denken: „Ich brauche MD5“, ist das Fehlen beabsichtigt. Wenn Sie es benötigen, ist das ein Signal dafür, dass Ihr System über eine Legacy-Komponente verfügt, die sorgfältig behandelt werden muss – genau das, wofür ein spezielles serverseitiges Migrationstool gedacht ist, kein Browser-Dienstprogramm. Die Ehrlichkeit des Tools darüber, was es bietet und was nicht, ist an sich schon eine wertvolle Information.

Das Design von Web Crypto spiegelt jahrzehntelange kryptografische Praxis wider: Algorithmen, die standardisiert, geprüft und im breiten Einsatz bewährt sind. SHA-256 und SHA-512 sind die sinnvollen Standardeinstellungen. SHA-384 trägt seine TLS-Abstammung. SHA-1 ist vorhanden, weil das Web über SHA-1 Digests verfügt, die jahrelang überprüft werden müssen. MD5 und SHA-3 sind nicht vorhanden, da MD5 defekt ist und SHA-3 noch nicht kritisch für die Plattform ist.