Entwicklertools · SHA-Hash-Rechner
Hex, Base64 und Rohbytes: Drei Möglichkeiten, denselben SHA-Digest zu schreiben
· Wie es funktioniert
sha-256 base64 Kodierung Dateiformate
sha256sum gibt Hex aus, package-lock.json speichert Base64 und Docker verwendet ein sha256:-Präfix. Sie können alle die gleichen 32 Bytes sein. In diesem Beitrag werden die einzelnen Darstellungen und die Konvertierung zwischen ihnen erläutert.
Die Hashes, die unterschiedlich aussehen, aber übereinstimmen – eine Sperrdateizeichenfolge und eine Terminalprüfsumme für dieselbe Datei
Ein SHA-256-Digest besteht grundsätzlich aus 32 Bytes. Wie Sie diese Bytes schreiben, bestimmt, wie der Digest aussieht. Ein Digest, 32 identische Bytes, erscheint als 64 Hexadezimalzeichen (zwei pro Byte) oder 44 Base64-Zeichen (ungefähr vier pro drei Bytes) oder je nach Codierung in unterschiedlichen Längen und Formaten. Die Verwirrung entsteht, weil eine Sperrdatei möglicherweise eine Darstellung und ein Terminal eine andere anzeigt, beide für dieselben zugrunde liegenden 32 Bytes.
Das Verstehen der Kodierung ist der Schritt, der die Frage stellt: „Warum sehen diese anders aus?“ in „Ich kann bestätigen, dass sie gleich sind.“ Alle drei Darstellungen sind gleichwertig, sobald Sie sie wieder in Bytes dekodieren.
Ein Digest besteht aus Bytes – 20, 32, 48 oder 64, je nach Algorithmus, vor jeglicher Textkodierung
Bevor eine Textdarstellung existiert, ist das Ergebnis ein ArrayBuffer mit Digest-Bytes. ToolAcre umschließt diesen Puffer mit Uint8Array und schreibt dann entweder jedes Byte als zwei hexadezimale Ziffern oder konvertiert jedes Byte in ein Binärzeichen, bevor es btoa aufruft. Keiner der Formatierer führt den Hash erneut aus und keiner ändert ein einziges Digest-Bit.
Die Bytebreite folgt dem in diesem Tool ausgewählten Algorithmus: SHA-1 gibt zwanzig Bytes zurück, SHA-256 zweiunddreißig, SHA-384 achtundvierzig und SHA-512 vierundsechzig. Hierbei handelt es sich um unterstützte Ausgaben, die durch die Metadaten und Tests des Algorithmus überprüft werden. Rohbytes eignen sich für den programmatischen Vergleich. Hex und Base64 sind Transportnotationen für Kanäle, die Text erwarten.
Hex – zwei Zeichen pro Byte, warum es Befehlszeilentools dominiert und die Frage nach der Groß-/Kleinschreibung
verwendet die Ziffern 0-9 und die Buchstaben A-F (oder a-f), um die 16 möglichen Werte eines 4-Bit-Nibbles darzustellen. Zwei Hexadezimalziffern repräsentieren ein Byte. Der SHA-256-Digest des Eingabe-ABC umfasst 32 Bytes und wird daher als 64 Hexadezimalzeichen angezeigt: ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad. Dies ist das Format, das die meisten Befehlszeilentools drucken. Hexadezimal ist für Menschen lesbar und eindeutig; Jedes Byte wird jedes Mal durch genau die gleichen zwei Zeichen dargestellt.
Hexadezimal ist das Standardformat für Prüfsummen und Hashes in der Dokumentation und in der Befehlszeile. Es ist leicht zu lesen und zu kopieren, und es gibt keine Auffüllung, keine Berücksichtigung der Groß-/Kleinschreibung bei der Interpretation (obwohl die Konvention durchgängig Klein- oder Großschreibung vorschreibt) und keine Sonderzeichen, die in URLs oder JSON maskiert werden müssen. Der Nachteil ist, dass es doppelt so viele Zeichen wie Rohbytes benötigt, weshalb es andere Formate gibt.
Base64 und base64url – ungefähr vier Zeichen pro drei Bytes, Auffüllung und wo sie jeweils vorkommen (SRI, npm, SSH-Fingerabdrücke)
Base64 kodiert drei Bytes als vier Zeichen, die aus einem 64-Zeichenalphabet stammen: A-Z, a-z, 0-9, +, /. Die drei Bytes 61 62 63 (die ASCII-Codes für abc) werden als YWJj in base64 kodiert. Ein vollständiger 32-Byte SHA-256-Digest kodiert als ungefähr 44 Base64-Zeichen. Das Auffüllen mit =-Zeichen bringt die Ausgabelänge auf ein Vielfaches von 4, also 44 Zeichen plus 0 Auffüllen (da 32 ein Vielfaches von 3 ist, ist kein Auffüllen erforderlich). Beim Dekodieren wird der Vorgang umgekehrt: Vier Base64-Zeichen werden in drei Bytes dekodiert.
Base64 erscheint in package-lock.json-Dateien, npm Shrinkwrap, SRI-Attributen (Subresource Integrity) in HTML und SSH-Schlüsselfingerabdrücken. Es ist kompakt – ungefähr 33 % länger als Rohbytes, verglichen mit 100 % länger im Hexadezimalformat. Der Nachteil besteht darin, dass nicht alle Textdarstellungen gleich gut lesbar sind; Base64 sieht für das menschliche Auge eher durcheinander aus als Hex.
Präfixformen – sha256: in Container-Digests, sha384- in Integritätsattributen, SHA256: in SSH
Base64url ist eine in RFC 4648 definierte Variante, die + und /. durch - und _ ersetzt. Das Alphabet wird zu A-Z, a-z, 0-9, -, _. JWTs verwenden base64url, da + und / in URLs eine besondere Bedeutung haben (+ kann als Leerzeichen in Abfragezeichenfolgen gelesen werden, / ist ein Pfadtrennzeichen). Ein JWT-Segment ist immer base64-URL-codiert, und ein Decoder, der auf Standard-Base64 besteht, wird es ablehnen. Umgekehrt schlägt ein Base64-URL-Decoder, der das Standardalphabet nicht akzeptiert, bei Standard-Base64 fehl.
Auffüllen ist in base64url optional. Standardmäßige Base64-Pads mit =, um sicherzustellen, dass die Ausgabelänge ein Vielfaches von 4 ist. Bei Base64url wird das Auffüllen häufig weggelassen, da = selbst URL-umständlich ist. Ein Decoder sollte base64url mit oder ohne Auffüllung akzeptieren, und der Encoder sollte explizit angeben, was er erzeugt. Das Base64-Tool ToolAcre akzeptiert beide Alphabete, toleriert fehlende Auffüllungen bei der Eingabe und lässt Sie das Format bei der Ausgabe auswählen.
Funktioniertes Beispiel – ein Digest, der von Hex in Base64 und zurück konvertiert wurde, wobei die Bytegrenzen markiert waren
Vorangestellte Formulare fügen dem Digest eine Schema-ID hinzu. Docker-Image-Digests verwenden sha256:ba7816bf..., wobei sha256: das Präfix ist. SSH-Fingerabdrücke verwenden SHA256: mit einem Doppelpunkt. Einige Tools verwenden sha256= oder SHA256= (mit einem Gleichheitszeichen). Das Präfix dient rein informativen Zwecken; Hier erfahren Sie, welcher Algorithmus den Digest erstellt hat. Durch das Entfernen des Präfixes verbleiben dieselben Bytes in derselben Codierung.
Beim Vergleich von Digests ist das Präfix „Noise“. Wenn ein Tool SHA256:ba78... und ein anderes ba78... ausgibt, handelt es sich um denselben Digest; Das Präfix enthält lediglich Metadaten zum Format. Ebenso sind Präfixe wie sha256:- (in einigen Containerkontexten verwendet) oder sha384- (in Integritätsattributen verwendet) Formatierungskonventionen, die die Bytes nicht ändern. Ziehen Sie sie zum Vergleich aus.
Was dies nicht abdeckt – welche Codierung ein bestimmtes Tool ausgibt; Überprüfen Sie vor dem Vergleich das Ausgabeformat
Ein Digest, der SHA-256 des Eingabe-ABC, erscheint in mehreren Formen: Hex (64 Zeichen), Base64 mit Auffüllung (44 Zeichen), Base64url mit Auffüllung (44 Zeichen, mit - und _ anstelle von + und /), oder mit verschiedenen Präfixen. Um zu bestätigen, dass sie gleich sind, dekodieren Sie sie jeweils wieder in Bytes und vergleichen Sie die Bytes. Die Hex-Darstellung ba7816bf... dekodiert in die Bytes 0xba 0x78 0x16 0xbf 0x8f 0x01 0xcf 0xea ... Die Base64-Darstellung wird beim Dekodieren in die gleiche Byte-Sequenz konvertiert.
Der ToolAcre SHA-Hash-Rechner gibt standardmäßig hexadezimal aus. Wenn Sie Base64 benötigen, können Sie ein separates Tool zum Konvertieren des Hexadezimalwerts in Base64 verwenden oder das Base64-Dienstprogramm auf derselben Site verwenden, um den Text direkt zu codieren. Tools, die für bestimmte Kontexte entwickelt wurden (npm für package-lock.json, Docker für Image-Digests), geben in dem Format aus, das ihr Kontext erwartet. Wenn man versteht, dass es sich hierbei um dieselben 32 Bytes in unterschiedlicher Aufmachung handelt, wird Verwirrung vermieden, wenn sich die Tools über das Format nicht einig sind.
Fazit: Vergleichen Sie Bytes, keine Zeichenfolgen – berechnen Sie den Digest mit dem ToolAcre SHA-Hash-Rechner und konvertieren Sie ihn dann in die Darstellung, gegen die Sie prüfen
Um einen Hex-Digest manuell in Base64 zu konvertieren, gruppieren Sie die Hex-Ziffern in Bytes, konvertieren Sie jedes Byte in Dezimalzahlen und kodieren Sie dann mit dem Base64-Alphabet. Das Byte 0xba (hex ba) ist dezimal 186; 0x78 ist 120; 0x16 ist 22; 0xbf ist 191. Die Gruppierung dieser vier Bytes und die Kodierung als Base64 ergeben die Zeichen w (0 + 22 im Alphabet), as (Kodierung 186), AA (Kodierung 120), vw (Kodierung 191). Für den vollständigen Digest ist es erforderlich, dies 10 Mal durchzuführen und bei Bedarf aufzufüllen. Dieser manuelle Vorgang ist lehrreich, aber langwierig; Ein Base64-Konverter-Tool macht es sofort möglich.
Die wichtigste Erkenntnis ist, dass ein Digest zuerst aus Bytes besteht und die Textdarstellung zweitrangig ist. Jede Kodierung derselben Bytes wird wieder in dieselben Bytes dekodiert und ist daher zum Zweck der Integritätsüberprüfung austauschbar. Unterschiede in der Groß-/Kleinschreibung im Hexadezimalformat, Füllunterschiede in Base64, Präfixe und Abstände sind Formatierungsoptionen, die sich nicht auf den tatsächlichen Wert auswirken. Wenn Sie die Fähigkeit zum Konvertieren zwischen Darstellungen beherrschen, werden Nichtübereinstimmungen im Digest-Format zu Debugging-Problemen, die Sie lösen können, statt zu Rätseln.