base32/

Base32 schreibt je 5 Bytes als 8 Zeichen aus einem Alphabet von nur 32 Zeichen (in der Standardform A-Z und 2-7); die Ausgabe ist daher etwa 60 % länger als die Eingabe, während Base64 nur etwa ein Drittel hinzufügt. Dafür unterscheidet Base32 nicht zwischen Groß- und Kleinschreibung und enthält die Ziffern 0, 1, 8 und 9 nicht, sodass es sich kaum mit den Buchstaben O, I und B verwechseln lässt. Das eignet sich zum Abschreiben von Hand, zum Vorlesen und für Stellen, an denen Groß- und Kleinschreibung egal ist, etwa bei 2FA-Schlüsseln und Dateinamen.

Das Base32, dem du im Alltag begegnest, einschließlich 2FA-Schlüsseln und der Standardausgabe der meisten Bibliotheken, ist die Standardvariante (RFC 4648, Abschnitt 6, Alphabet A-Z und 2-7). Bei Base32Hex (Abschnitt 7, Alphabet 0-9 und A-V) entspricht die Sortierreihenfolge des kodierten Textes der Sortierreihenfolge der ursprünglichen Bytes; deshalb verwendet DNSSEC es für NSEC3. Beide lassen sich nicht gegenseitig dekodieren: Bei der falschen Wahl erscheint oft die Meldung „kein Base32-Zeichen“, manchmal kommt auch nur Zeichensalat heraus.

Ja. Ein TOTP-Secret (der Parameter secret im otpauth://-Link eines QR-Codes oder der Schlüssel, den du von Hand eingibst) ist normalerweise Standard-Base32, meist in Großbuchstaben und ohne =, manchmal in Vierergruppen mit Leerzeichen angezeigt; das alles wird beim Dekodieren hier erkannt. Das Ergebnis sind zufällige Bytes und kein Text, deshalb musst du „Ergebnis als Hex anzeigen“ aktivieren, um es zu sehen. JBSWY3DPEHPK3PXP ist zum Beispiel 48 65 6c 6c 6f 21 de ad be ef. Zum Erzeugen von Einmalcodes nimm das 2FA-Tool dieser Seite.

„Ungültige Länge“ bedeutet, dass die Zeichenzahl nach dem Entfernen von = bei der Division durch 8 den Rest 1, 3 oder 6 lässt; gültiges Base32 lässt nur 0, 2, 4, 5 oder 7, daher sind beim Kopieren sehr wahrscheinlich Zeichen verloren gegangen. „Kein Base32-Zeichen“ nennt die Position des Zeichens: Die Standardvariante enthält weder die Ziffern 0, 1, 8 und 9 noch Satzzeichen oder Vollbreite-Zeichen; enthält der Inhalt 0-9 und A-V, ist es möglicherweise Base32Hex, wechsle dann die Variante. „= darf nur am Ende stehen“ bedeutet, dass nach einem = noch weiterer Inhalt folgt, vielleicht wurden mehrere Zeichenketten zusammengefügt, die du getrennt dekodieren musst. Leerzeichen, Zeilenumbrüche, Kleinbuchstaben und ein fehlendes = führen nie zu einem Fehler.

Das = füllt die Länge auf ein Vielfaches von 8 auf und gehört nicht zu den Daten. Beim Dekodieren funktioniert es mit und ohne; beim Kodieren ist „= als Padding anhängen“ standardmäßig aktiviert, deaktiviere es, wenn du es nicht brauchst. Ob du es weglassen darfst, hängt vom Empfänger ab: Das Format des otpauth-Links von Google Authenticator sagt, dass das Secret kein Padding braucht, und meist wird es weggelassen; base64.b32decode in Python verlangt es dagegen und wirft ohne Padding den Fehler Incorrect padding.

Dann sind die dekodierten Bytes kein UTF-8-Text. 2FA-Schlüssel, Hashwerte und verschlüsselte Daten sind von Haus aus binär; aktiviere „Ergebnis als Hex anzeigen“, um die Rohbytes zu sehen. Dieses Tool zeigt Text nur als UTF-8 an. Wurde der Originaltext in GBK oder einer anderen Kodierung gespeichert, aktiviere zuerst Hex und wandle die Bytes dann mit dem Text-/Hex-Tool dieser Seite und der Auswahl GBK wieder in Text um.

Prüfe drei Dinge. Erstens, ob die Eingabe mit einem zusätzlichen Zeilenumbruch oder Leerzeichen endet: Dieses Tool kodiert sie genau wie eingegeben als UTF-8 und entfernt nichts. Zweitens, ob die Variante übereinstimmt: In Python ist die Standardform base64.b32encode und Base32Hex base64.b32hexencode (ab Version 3.10). Drittens, ob das Padding mit = aktiviert ist. Varianten mit anderem Alphabet wie Crockford und z-base-32 werden nicht unterstützt und liefern andere Ergebnisse.

Nein. Kodieren und Dekodieren laufen in deinem Browser, sie senden keine Anfragen und speichern nichts; ein 2FA-Schlüssel verlässt deinen Browser nie.