Base32

Bytes in zweiunddreißig Zeichen, und die ausgelassenen Ziffern

Base32 schreibt Bytes als Text, in zweiunddreißig Zeichen, von denen jedes für fünf Bits steht, sodass je fünf Bytes — vierzig Bits — zu acht Zeichen werden. Hello besteht aus fünf Bytes und wird als JBSWY3DP geschrieben. Wählen Sie „Decodieren“ und fügen Sie Base32 ein, und die Seite gibt die Bytes zurück, für die es steht: als Text oder als Hexadezimalcode, wenn Sie „Bytes als“ auf „Hexadezimal“ stellen.

RFC 4648, die es definiert, verwendet die sechsundzwanzig Großbuchstaben und die Ziffern 2 bis 7. Die RFC nennt den Grund, warum 0 und 1 fehlen: Wer mit dem Text umgeht, kann leicht 0 mit O und 1 mit l oder I verwechseln, also behält das Alphabet die Buchstaben und lässt diese beiden Ziffern weg. Neben den Buchstaben braucht es sechs Ziffern, und die sechs, die es nimmt, sind 2 bis 7, also gehören auch 8 und 9 nicht dazu. Beim Decodieren in diesem Alphabet lehnt die Seite eine 0, 1, 8 oder 9 dort ab, wo sie steht, statt eine 0 als O oder eine 1 als I zu lesen: Die RFC erlaubt einem Decoder, sie so zu lesen, und sagt, dass er es standardmäßig nicht tun sollte.

Groß- und Kleinschreibung gehört nicht zum Wert. RFC 4648 hat Base32 für Text entworfen, der ohne Rücksicht auf Groß- und Kleinschreibung gelesen werden muss, also ist jbswy3dp ebenso Hello wie JBSWY3DP. Die RFC schreibt ihr Alphabet in Großbuchstaben, und diese Seite tut das ebenfalls, sofern Sie nicht „kleinschreibung“ einschalten. Beim Lesen wird außerdem Leerraum an jeder Stelle übergangen, Zeilenumbrüche eingeschlossen, sodass Base32, das in Gruppen oder auf mehrere Zeilen verteilt ist, gelesen wird, als wäre es in einem Stück geschrieben.

Auffüllung, und die Längen, in denen Base32 vorkommt

Bytes kommen selten in ganzen Fünfergruppen. Bleiben am Ende ein bis vier übrig, belegen sie zwei, vier, fünf oder sieben Zeichen, und RFC 4648 füllt diese letzte Zeichengruppe mit = auf acht auf: mit sechs davon, vier, drei oder einem. So ist f MY======, fo MZXQ====, foo MZXW6=== und foob MZXW6YQ=, während fooba, fünf Bytes, seine acht Zeichen als MZXW6YTB genau füllt.

Zu je acht gezählt, lassen die Zeichen vor einem etwaigen = also immer 0, 2, 4, 5 oder 7 übrig und nie 1, 3 oder 6, da keine Anzahl von Bytes diese übrig lässt; die Seite lehnt einen solchen Text an seinem letzten Zeichen ab, statt ihn als etwas Kürzeres zu lesen. Die Auffüllung sagt nichts, was die Länge nicht sagt, also liest die Seite Base32, dessen Auffüllung weggelassen ist — JBUQ ist ebenso Hi wie JBUQ==== —, und lehnt eine Auffüllung nur ab, wo sie vorhanden und falsch ist: ein = in der Mitte, auf das noch mehr vom Text folgt, oder die falsche Anzahl von = am Ende, wo die Ablehnung sagt, wie viele dorthin gehören.

Beim Codieren entscheidet der Schalter „Auffüllung“, ob die = geschrieben werden. Er ist anfangs eingeschaltet, weil RFC 4648 eine Auffüllung vorsieht, sofern die Spezifikation, die Base32 verwendet, nichts anderes sagt, und mehrere tun das: Das Key Uri Format, das die otpauth:// URI in einem QR-Code für 2FA beschreibt, sagt, dass die Auffüllung eines Geheimnisses weggelassen werden sollte, und NSEC3-Einträge und IPFS schreiben keine. Der Schalter „kleinschreibung“ daneben schreibt die Buchstaben klein; die Ziffern und das = haben keine Groß- und Kleinschreibung, die sich ändern ließe. Beide Schalter gibt es nur beim Codieren, da das Lesen jede Kombination von ihnen annimmt.

Andere Werkzeuge lesen weniger als diese Seite. GNU coreutils schreibt Base32 mit base32 und das zweite Alphabet, base32hex, mit basenc --base32hex; das Modul base64 von Python hat für jedes eine Funktion. Alle schreiben, was diese Seite beim Öffnen schreibt, mit Auffüllung und in Großbuchstaben. Aber base32 -d lehnt Base32 ab, dessen Auffüllung fehlt oder dessen Buchstaben kleingeschrieben sind, und auch b32decode von Python lehnt beides ab und liest Kleinbuchstaben nur, wenn ihm casefold=True übergeben wird:

# Schreiben: das voreingestellte Alphabet, dann das andere
printf 'Hi' | base32                          # JBUQ====
printf 'Hi' | basenc --base32hex              # 91KG====

# Zurücklesen: mit Auffüllung, dann ohne Auffüllung, dann in Kleinbuchstaben
printf 'JBUQ====' | base32 -d                 # Hi
printf 'JBUQ' | base32 -d                     # base32: invalid input
printf 'jbuq====' | base32 -d                 # base32: invalid input

# Dasselbe in einem Skript
import base64
base64.b32encode(b'Hi')                       # b'JBUQ===='
base64.b32hexencode(b'Hi')                    # b'91KG===='
base64.b32decode('JBUQ')                      # binascii.Error: Incorrect padding
base64.b32decode('jbuq====', casefold=True)   # b'Hi'

Zwei Alphabete: base32 und base32hex

RFC 4648 definiert ein zweites Alphabet, base32hex: die Ziffern 0 bis 9, dann die Buchstaben A bis V, sodass seine Zeichen der Reihenfolge der Werte folgen, für die sie stehen, von 0 für null bis V für einunddreißig. Das gibt ihm eine Eigenschaft, die dem ersten fehlt und auf die die RFC hinweist: Zeichen für Zeichen verglichen, sortiert sich sein Text in der Reihenfolge der Bytes, für die er steht. Das Byte 00 ist in base32 AA====== und in base32hex 00======, und das Byte FF ist 74====== und VS======; beim Sortieren als Text stellt base32 FF an den Anfang, da Ziffern vor Buchstaben einsortiert werden, während base32hex die Bytes in ihrer Reihenfolge lässt.

Die NSEC3-Einträge von DNSSEC verwenden es. Der Name eines solchen Eintrags beginnt mit dem Hash eines Domainnamens, geschrieben in base32hex ohne Auffüllung, und RFC 5155 merkt an, dass die gehashten Namen, so geschrieben, in derselben Reihenfolge sortiert werden wie die Hashes nach ihrem Wert. Die Beispielzone dieser RFC selbst hasht example zu 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom. Ist base32hex gewählt, liest die Seite diese 32 Zeichen als die 20 Bytes des Hashes; ist base32 gewählt, lehnt sie die 0 ab — und ein Hinweis sagt, dass sich der Text in base32hex ganz lesen lässt, neben einer Schaltfläche, die umschaltet.

Da dieselben Bytes in jedem einen anderen Text ergeben — Hi ist in base32 JBUQ==== und in base32hex 91KG==== —, gilt das Alphabet, das Sie wählen, in beiden Richtungen, und die Seite ändert es nie an Ihrer Stelle. Enthält ein Text, den Sie decodieren, ein Zeichen, das das gewählte Alphabet nicht hat, oder endet er auf Restbits, die nicht null sind — ein Begriff, den die Fragen weiter unten erklären —, während das andere Alphabet ihn ganz liest, wie ein Encoder ihn schreiben würde, dann sagt das ein Hinweis neben einer Schaltfläche, die umschaltet; das Alphabet wechselt nur, wenn Sie diese Schaltfläche drücken oder es selbst wählen. Ein Text, den beide einwandfrei lesen, etwa ABCDEFGH, wird in dem gewählten gelesen, da nichts an ihm sagt, welches gemeint war.

Wo Base32 auftaucht: 2FA-Geheimnisse, Onion-Adressen und IPFS

Im Key Uri Format, das die otpauth:// URI beschreibt, die ein QR-Code zur Einrichtung enthalten kann, ist Base32 die Form, in der das Geheimnis hinter den Codes einer Authenticator-App geschrieben wird: Der secret-Parameter der URI ist Base32, und die Auffüllung sollte weggelassen werden. Fügen Sie ein solches Geheimnis in Groß- oder Kleinbuchstaben ein, in Gruppen, die durch Leerzeichen getrennt oder auf mehrere Zeilen verteilt sind, mit oder ohne = — ein Bindestrich zwischen Gruppen wird dort abgelehnt, wo er steht —, oder fügen Sie die ganze URI ein, und die Seite liest das Geheimnis daraus und sagt das. Was die übrigen Parameter der URI bedeuten und wie aus einem Geheimnis die Codes werden, die eine App anzeigt, gehört zum TOTP-/2FA-Code-Debugger: Sein Leitfaden erklärt die URI und ihre Parameter, und seine Seite berechnet die Codes. Das Label und der Aussteller in der URI sind prozentcodiert, wie es das Key Uri Format vorsieht, und der URL-Encoder / -Decoder liest sie.

Auch eine Onion-Adresse in Version 3 von Tor ist Base32. Die 56 Zeichen vor .onion sind das Base32 von 35 Bytes: dem öffentlichen Schlüssel des Dienstes aus 32 Bytes, einer Prüfsumme aus zwei Bytes und einem Versionsbyte, 03. Die Spezifikation von Tor schreibt ihre Beispieladressen in Kleinbuchstaben, und 35 Bytes füllen ganze Gruppen, also gibt es keine Auffüllung, die sich weglassen ließe. Fügen Sie die 56 Zeichen ohne .onion ein, stellen Sie „Bytes als“ auf „Hexadezimal“, und das letzte Byte lautet 03.

IPFS schreibt seine Inhaltskennungen, die CIDs, ab Version 1 standardmäßig in Base32: kleingeschrieben und ohne Auffüllung, nach einem Buchstaben, b, der nicht zum Base32 gehört, sondern es benennt — dem Präfix von multibase, das entfernt wird, bevor der Rest decodiert wird. So wird bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi, das Beispiel aus der eigenen Dokumentation von IPFS, hier als Ganzes abgelehnt, als eine Länge, die keine Bytes ergeben; ohne sein b wird es als 36 Bytes gelesen, die binäre CID, die mit 01 für ihre Version beginnt.

Ein 2FA-Geheimnis besteht aus Bytes, nicht aus Text

Das Beispielgeheimnis im Key Uri Format ist JBSWY3DPEHPK3PXP, und dieses Dokument schreibt seinen Wert als zehn Bytes aus: die Zeichen von Hello!, dann DE AD BE EF. Seine ersten acht Zeichen, JBSWY3DP, sind für sich allein Hello. Hier decodiert, mit „Bytes als“ auf „Text“, wie die Seite voreingestellt ist, kommt es als Hello! heraus, dann U+07AD — DE AD ergeben zufällig ein Zeichen, ein kombinierendes Zeichen der Thaana-Schrift — und dann zweimal U+FFFD, das jeweils für eine Folge steht, die kein Text ist. Ein Hinweis unter dem Ergebnis zählt die ersetzten Folgen, sagt, dass die erste bei Byte 9 beginnt, dessen Bits im Zeichen in Zeile 1, Spalte 13 beginnen, der 3, und sagt, dass die Bytes womöglich gar kein Text sind.

Ein echtes Geheimnis besteht aus zufälligen Bytes, die selten Text ergeben, also ist es, als Text decodiert, ein Durcheinander verirrter Zeichen und U+FFFD, das Ihnen nichts darüber sagt, ob das Geheimnis stimmt. Dafür gibt es die Option „Hexadezimal“ unter „Bytes als“. Wählen Sie sie oder drücken Sie die Schaltfläche neben dem Hinweis, und dasselbe Geheimnis wird vollständig als 48 65 6C 6C 6F 21 DE AD BE EF angezeigt: die Bytes selbst, also das, was ein Server speichert und woraus jeder Code berechnet wird. Die Seite wechselt nie von sich aus zu Hexadezimal, sodass auf dem Bildschirm immer steht, was Sie gewählt haben.

Andersherum ist es dieselbe Wahl, beim Codieren getroffen. Ein Schlüssel, den ein Server als Hexadezimalcode aufbewahrt, besteht aus Bytes: Wählen Sie „Codieren“, stellen Sie „Bytes als“ auf „Hexadezimal“ und fügen Sie ihn ein — mit Leerzeichen oder zusammengeschrieben, mit 0x vor den Bytes, als Array von Zahlen oder als Hexdump im Layout von hexdump -C oder von xxd —, und die Seite schreibt das Base32, das eine Authenticator-App annimmt. 48656C6C6F21DEADBEEF ergibt JBSWY3DPEHPK3PXP, das Geheimnis von oben; zehn Bytes füllen ganze Gruppen, und ein Schlüssel, der das nicht tut, etwa einer aus sechzehn Bytes, kommt mit = dahinter heraus, sofern Sie den Schalter „Auffüllung“ nicht ausschalten, wie es das Key Uri Format vorsieht. Hexadezimalcode, der beim Decodieren versehentlich eingefügt wurde — eine gerade Anzahl von Hexadezimalziffern und außer Leerraum sonst nichts, in einer Form, die sich beim Codieren als Bytes lesen lässt —, bekommt einen Hinweis, dass er nach Hexadezimalcode aussieht, neben einer Schaltfläche, die zum Codieren dieses Hexadezimalcodes wechselt. Und beim Decodieren speichert „Herunterladen“ die Bytes selbst als Datei namens bytes.bin.

Base32 oder Base64, und warum nicht Crockfords Alphabet

Base64 erledigt dieselbe Aufgabe mit vierundsechzig Zeichen, vier für je drei Bytes, wodurch sein Text um ein Drittel länger ist als die Bytes, während der von Base32 um drei Fünftel länger ist. Dafür gibt Base64 auf, dass die Groß- und Kleinschreibung keine Rolle spielt: In seinem Alphabet sind Groß- und Kleinbuchstaben verschiedene Werte, dazu kommen + und /, also ist SGk= Hi und sgk= zwei andere Bytes. Base32 eignet sich für Text, der durch etwas hindurchgeht, das Groß- und Kleinschreibung ignoriert, oder den ein Mensch auf einem Bildschirm abliest und auf einem anderen eintippt. Enthält hier eingefügtes Base64 ein + oder ein /, das kein Base32 schreibt, und ist es durchweg wie Base64 gebaut, wird es abgelehnt, mit einem Hinweis, dass es wie Base64 aussieht, und einem Link zum Base64-Werkzeug, das Base64 als Text liest.

Es gibt andere Alphabete aus zweiunddreißig Zeichen, und diese Seite bietet die beiden von RFC 4648 an und kein anderes. Eines davon ist das von Douglas Crockford, das alle zehn Ziffern behält und I, L, O und U weglässt und das vom Format ULID verwendet wird. Crockford hat es zum Schreiben von Zahlen definiert, und für Bytes hat es zwei Antworten: Die sechzehn Bytes 00 bis 0F, fünf Bits auf einmal gepackt, wie RFC 4648 Bytes packt, sind 000G40R40M30E209185GR38E1W, und als eine 128-Bit-Zahl gelesen, wie die sechsundzwanzig Zeichen einer ULID gelesen werden, sind sie 00041061050R3GG28A1C60T3GF. Eine Seite, die Bytes darin schreibt, würde eine der beiden für Sie wählen, ohne dass Sie es sehen.