Base32- / Base58-Konverter

Beide sind zwei Antworten auf dieselbe Frage: Ein Kanal, der Text transportiert, soll Bytes transportieren. Base32 und Base58 sind weder Verschlüsselung noch Hashing — sie verbergen nichts und verkürzen nichts. Sie schreiben eine Bytefolge mit einem festen Satz lesbarer Zeichen um, und wer den verwendeten Satz kennt, kann sie sofort zurückrechnen. Der einzige Grund, das eine dem anderen vorzuziehen, ist, was die empfangende Seite mit den Zeichen tut.

Zwei Familien schreiben auf völlig verschiedene Weise um, und dieser Unterschied erklärt fast jede Überraschung auf dieser Seite:

• Bitpackung — Base32, Base32 Hex, Crockford Base32, z-base-32. Die Bytes werden in feste Gruppen zerlegt, und je fünf Bit ergeben ein Zeichen. Die Ausgabelänge ist aus der Eingabelänge vorhersagbar; die letzte, nur teilweise gefüllte Gruppe wird entweder mit Auffüllzeichen markiert oder bleibt kurz.
• Umwandlung großer Zahlen — jede Base58-Tabelle. Die gesamte Bytefolge wird als eine riesige Zahl zur Basis 256 gelesen und zur Basis 58 wieder ausgegeben. Es gibt keine Gruppen und keine Auffüllung; die Länge teilt sich in nichts auf, und jedes führende Nullbyte wird zu einem führenden Nullsymbol.

Jedes Alphabet wird vollständig ausgeschrieben statt nur beschrieben, denn zwei Werkzeuge, die unter demselben Namen verschiedene Zeichen ausgeben, werden sich nicht einig, egal was das Etikett sagt. Die Zeilen nach RFC 4648 sind verbindlich; die Zeilen für Crockford und z-base-32 folgen dem, was der Autor des Formats veröffentlicht hat; die drei Base58-Zeilen sind verbreitete Konventionen und keine Normen, deshalb stehen sie gesondert.

Das Alphabet lässt I, L, O und U weg, damit kein Symbol mit einem anderen verwechselt werden kann. Was übrig bleibt, ist beim Eingeben groß-/kleinschreibungsunabhängig: i und l werden als Ziffer 1 gelesen, o als Ziffer 0, und Bindestriche dienen nur dazu, eine lange Zeichenkette leichter lesbar zu machen. Außerdem definiert das Format ein optionales Prüfzeichen: den Wert der Symbolkette, gelesen als Zahl zur Basis 32, modulo 37 genommen und mit fünf zusätzlichen Symbolen für die Werte 32 bis 36 geschrieben.

Das Prüfzeichen wird über die Zeichenkette berechnet, nicht über die Bytes: Da der Kodierer die letzte Gruppe mit Nullen auffüllt, ergibt das Dekodieren derselben Zeichen immer denselben Wert. Deshalb lässt sich der Prüfwert aus der Tabelle allein aus der kodierten Spalte von Hand nachrechnen. Die fünf zusätzlichen Symbole sind *, ~, $, = und U für die Werte 32, 33, 34, 35 und 36; ein Prüfzeichen ist also nicht immer eine Ziffer oder ein Buchstabe.

z-base-32 behält die Fünf-Bit-Packung von RFC 4648 Base32 bei und ändert nur die Reihenfolge der zweiunddreißig Zeichen. Die Reihenfolge ist so gewählt, dass die Zeichen, die ein Mensch am ehesten aufschreiben muss, am leichtesten zu schreiben und am schwersten zu verwechseln sind. Es gibt keine Auffüllung, deshalb muss ein Leser wissen, wie viele Symbole ein Wert haben soll; das ist der Preis eines Formats, das zuerst von Hand gelesen werden soll.

Base58 allein kann eine verschriebene Zeichenkette nicht von einer richtigen unterscheiden, denn fast jede Kombination seiner achtundfünfzig Zeichen ist eine gültige Zahl. Base58Check behebt das, indem es die Daten in eine Hülle packt: ein Versionsbyte, dann die Nutzlast, dann die ersten vier Bytes von SHA-256, zweimal angewendet auf die ersten beiden Teile. Ein empfangendes Programm berechnet diese vier Bytes neu und weist die Zeichenkette zurück, wenn sie nicht übereinstimmen. Das Versionsbyte sagt einer Wallet, ob es eine Zahlungsadresse, eine Skriptadresse oder einen privaten Schlüssel vor sich hat.

Der Generator unter dem Konverter nimmt das Versionsbyte und die Nutzlast als Hexadezimalzahlen und schreibt die Base58Check-Zeichenkette; der Prüfer liest eine ein, trennt die vier Prüfsummenbytes ab, berechnet sie neu und meldet sowohl die gefundene als auch die erwartete. Eine falsche Prüfsumme bedeutet hier, dass die Zeichenkette verschrieben oder verändert wurde — sie bedeutet nie, dass die Nutzlast selbst falsch ist, denn die Nutzlast wird nie interpretiert.

• „Base64 ist Verschlüsselung.“ Nein. Es gibt keinen Schlüssel und kein Geheimnis; die Ausgabe kann jeder zurückrechnen. Base32 und Base58 stehen genauso da, und auch das Durchschleusen eines Werts durch alle drei fügt keinen Schutz hinzu.
• „Eine Base58-Zeichenkette ist eine Bitcoin-Adresse.“ Nur wenn sie auch die Base58Check-Prüfsumme besteht und ein Versionsbyte trägt, das die empfangende Software kennt. Base58-Zeichenketten tauchen an vielen anderen Stellen auf, auch als einfache Kennungen ganz ohne Prüfsumme.
• „Die drei Base58-Alphabete sind austauschbar.“ Sie verwenden dieselben achtundfünfzig Zeichen in drei verschiedenen Reihenfolgen, daher ergeben dieselben Bytes drei verschiedene Zeichenketten. Ein Werkzeug muss angewiesen werden, welches es verwenden soll; diese Seite nennt immer, welches sie benutzt hat.
• „Die Auffüllung gehört zum Wert.“ Die Zeichen = markieren nur die letzte Gruppe. Zwei Base32-Zeichenketten, die sich nur durch ihre Auffüllung unterscheiden, beschreiben dieselben Bytes; deshalb akzeptiert der Decoder auch eine Zeichenkette, bei der die Auffüllung fehlt.
• „Beliebige Zeichen funktionieren.“ Jedes Alphabet ist eine feste Menge. Ein Zeichen von außerhalb hat keinen Wert; der Decoder hält deshalb an und nennt das Zeichen und seine Position, statt zu raten.

Warum verwendet Base32 2-7 und nicht 0-9? Weil RFC 4648 das Alphabet so gewählt hat, dass es innerhalb der Zeichen bleibt, die ein Domainname enthalten darf, und dass es sich leicht laut vorlesen lässt. Base32 Hex verwendet stattdessen 0-9 A-V, wenn die natürliche Sortierung wichtiger ist.

Warum beginnt eine Base58-Zeichenkette so oft mit 1? Jedes führende Nullbyte der Eingabe wird zu einer führenden 1 (dem ersten Zeichen des Bitcoin- und des Flickr-Alphabets). Ein Versionsbyte 0x00 ist ein Nullbyte, daher beginnen die meisten Bitcoin-Mainnet-Adressen mit genau einer 1.

Was lädt die Schaltfläche Beispiel? Das Beispiel, das zum gerade angezeigten Schema und zur Richtung gehört, niemals einen festen Text. Der Kodierer bekommt den Text des eigenen Beispiels des Schemas — die Vektoren aus RFC 4648, Abschnitt 10, für Base32 und Base32 Hex, Crockfords 12345, die oben gedruckten z-base-32-Zeilen — und der Decoder bekommt die kodierte Zeichenkette für das gewählte Alphabet. Genau das macht das Beispiel in beide Richtungen brauchbar. Die drei Base58-Zeilen tragen absichtlich denselben Text, damit man beim Wechsel des Schemas und erneutem Drücken von Beispiel die drei Reihenfolgen derselben achtundfünfzig Zeichen nebeneinander sieht. Ist das Crockford-Prüfzeichen angehakt, bekommt der Decoder den Wert mit dem Zeichen am Ende, und nur so kann man sehen, wie der Prüfer eines akzeptiert.

Sendet diese Seite meine Daten irgendwohin? Nein. Jede Umwandlung findet in diesem Browser-Tab statt, und die Seite enthält keinerlei Netzwerkaufrufe. Deshalb funktioniert sie auch mit der Datei direkt von der Festplatte.

Welches sollte ich für ein Geheimnis verwenden? TOTP- und HOTP-Geheimnisse von Authentifizierungs-Apps sind meist Base32 im Alphabet nach RFC 4648, weil das Geheimnis von Hand eingetippt werden muss. Verwenden Sie das, was Ihre empfangende Software verlangt, und verlassen Sie sich niemals auf die Kodierung selbst für die Geheimhaltung.