Convertitore Base32 / Base58

Sono due risposte alla stessa domanda: a un canale che trasporta testo viene chiesto di trasportare byte. Base32 e Base58 non sono crittografia né hashing — non nascondono nulla e non accorciano nulla. Riscrivono una sequenza di byte usando un insieme fisso di caratteri leggibili, e chiunque conosca l'insieme usato può riportarla indietro direttamente. L'unico motivo per preferire l'una all'altra è ciò che il destinatario fa con i caratteri.

Due famiglie compiono questa riscrittura in modi del tutto diversi, e la differenza spiega quasi ogni sorpresa di questa pagina:

• Impacchettamento di bit — Base32, Base32 Hex, Base32 di Crockford, z-base-32. I byte vengono tagliati in gruppi di lunghezza fissa e ogni cinque bit diventano un carattere. La lunghezza dell'output è prevedibile dalla lunghezza dell'input, e l'ultimo gruppo, parzialmente pieno, viene segnalato con caratteri di riempimento oppure lasciato corto.
• Conversione di numeri grandi — tutte le tabelle Base58. L'intera sequenza di byte viene letta come un unico numero enorme in base 256 e riscritta in base 58. Non ci sono gruppi né riempimento; la lunghezza non si divide in nulla, e ogni byte zero iniziale diventa un simbolo zero iniziale.

Ogni alfabeto è stampato per intero invece di essere descritto, perché due strumenti che stampano caratteri diversi con lo stesso nome non saranno d'accordo tra loro, qualunque sia l'etichetta. Le righe RFC 4648 sono normative; quelle di Crockford e z-base-32 seguono ciò che l'autore del formato ha pubblicato; le tre righe Base58 sono convenzioni diffuse e non standard, ed è per questo che sono elencate a parte.

L'alfabeto elimina I, L, O e U perché nessun simbolo possa essere letto come un altro. Ciò che resta non distingue tra maiuscole e minuscole in ingresso: i e l si leggono come la cifra 1, o si legge come la cifra 0, e i trattini servono solo a rendere più leggibile una stringa lunga. In più il formato definisce un simbolo di controllo facoltativo, che è il valore della stringa di simboli letta come numero in base 32, preso modulo 37, e scritto con cinque simboli extra per i valori da 32 a 36.

Il simbolo di controllo viene calcolato sulla stringa di simboli, non sui byte: poiché il codificatore estende a zero l'ultimo gruppo, decodificare gli stessi caratteri riporta sempre allo stesso valore. Per questo il valore di controllo nella tabella può essere riprodotto a mano partendo solo dalla colonna codificata. I cinque simboli extra sono *, ~, $, = e U per i valori 32, 33, 34, 35 e 36, quindi un simbolo di controllo non è sempre una cifra o una lettera.

z-base-32 mantiene l'impacchettamento a cinque bit della Base32 RFC 4648 e cambia solo l'ordine dei trentadue caratteri. L'ordine è scelto in modo che i caratteri che una persona ha più probabilità di dover scrivere a mano siano quelli più facili da scrivere e più difficili da confondere. Non ha riempimento, quindi chi legge deve sapere quanti simboli ci si aspetta per un valore; è il prezzo di un formato pensato per essere letto a mano prima di tutto.

La sola Base58 non ha modo di distinguere una stringa digitata male da una corretta, perché quasi qualsiasi combinazione dei suoi cinquantotto caratteri è un numero valido. Base58Check risolve il problema mettendo i dati dentro un involucro: un byte di versione, poi il carico utile, poi i primi quattro byte di SHA-256 applicato due volte in fila alle prime due parti. Un programma ricevente ricalcola quei quattro byte e rifiuta la stringa quando non coincidono. Il byte di versione è ciò che dice a un portafoglio se sta guardando un indirizzo di pagamento, un indirizzo di script o una chiave privata.

Il generatore sotto il convertitore prende il byte di versione e il carico utile in esadecimale e scrive la stringa Base58Check; il verificatore ne legge una, separa i quattro byte di checksum, li ricalcola e segnala sia quello trovato sia quello atteso. Un checksum sbagliato significa che la stringa è stata digitata male o alterata — non significa mai che il carico utile sia sbagliato, perché il carico utile non viene mai interpretato.

• "Base64 è crittografia." No. Non c'è una chiave né un segreto; l'output è reversibile da chiunque. Base32 e Base58 sono nella stessa posizione, e far passare un valore attraverso tutti e tre non aggiunge protezione.
• "Una stringa Base58 è un indirizzo Bitcoin." Solo quando supera anche il checksum Base58Check e ha un byte di versione che il software ricevente riconosce. Le stringhe Base58 compaiono in molti altri posti, anche come identificatori semplici senza alcun checksum.
• "I tre alfabeti Base58 sono intercambiabili." Usano gli stessi cinquantotto caratteri in tre ordini diversi, quindi gli stessi byte producono tre stringhe diverse. Uno strumento deve essere istruito su quale usare, e questa pagina dice sempre quale ha usato.
• "Il riempimento fa parte del valore." I caratteri = segnano solo l'ultimo gruppo. Due stringhe Base32 che differiscono solo per il riempimento descrivono gli stessi byte, ed è per questo che il decodificatore accetta una stringa con il riempimento tagliato.
• "Qualsiasi carattere va bene." Ogni alfabeto è un insieme fisso. Un carattere che ne sta fuori non ha valore, quindi il decodificatore si ferma e indica il carattere e la sua posizione invece di tirare a indovinare.

Perché Base32 usa 2-7 e non 0-9? Perché la RFC 4648 ha scelto l'alfabeto in modo che resti tra i caratteri consentiti in un nome di dominio e che sia facile da leggere a voce alta. Base32 Hex usa invece 0-9 A-V quando conta di più l'ordinamento naturale.

Perché una stringa Base58 comincia spesso con 1? Ogni byte zero iniziale dell'input diventa una 1 iniziale (il primo carattere degli alfabeti di Bitcoin e Flickr). Un byte di versione 0x00 è un byte zero, quindi la maggior parte degli indirizzi Bitcoin di mainnet comincia con esattamente un 1.

Che cosa carica il pulsante Esempio? L'esempio che appartiene allo schema e alla direzione attualmente sullo schermo, mai un testo fisso. Al codificatore viene dato il testo dell'esempio dello schema — i vettori della sezione 10 della RFC 4648 per Base32 e Base32 Hex, 12345 di Crockford, le righe z-base-32 stampate sopra — e al decodificatore viene dato la stringa codificata per l'alfabeto selezionato, che rende l'esempio utilizzabile in entrambe le direzioni. Le tre righe Base58 hanno intenzionalmente lo stesso testo, così cambiando schema e premendo di nuovo Esempio si vedono affiancati i tre ordinamenti degli stessi cinquantotto caratteri. Con il simbolo di controllo Crockford spuntato, al decodificatore viene passato il valore con il simbolo alla fine, che è l'unico modo per vedere il verificatore accettarne uno.

Questa pagina invia i miei dati da qualche parte? No. Ogni conversione avviene in questa scheda del browser, e la pagina non contiene alcuna chiamata di rete. È anche per questo che funziona con il file aperto direttamente dal disco.

Quale usare per un segreto? I segreti degli autenticatori TOTP e HOTP sono di solito in Base32 con l'alfabeto della RFC 4648, perché il segreto deve essere digitato a mano. Usi quello che chiede il suo software ricevente, e non faccia mai affidamento sulla codifica per la segretezza.