Conversor Base32 / Base58

São duas respostas a uma mesma pergunta: um canal que transporta texto tem de transportar bytes. O Base32 e o Base58 não são encriptação nem hash — não escondem nada e não encurtam nada. Reescrevem uma cadeia de bytes usando um conjunto fixo de caracteres legíveis, e quem souber qual conjunto foi usado consegue reverter diretamente. A única razão para preferir um ou outro é o que o destinatário faz com os caracteres.

Duas famílias fazem essa reescrita de formas completamente diferentes, e a diferença explica quase todas as surpresas desta página:

• Empacotamento de bits — Base32, Base32 Hex, Crockford Base32, z-base-32. Os bytes são cortados em grupos fixos e cada cinco bits tornam-se um carácter. O comprimento do resultado é previsível a partir do comprimento da entrada, e o último grupo, parcialmente preenchido, ou é marcado com caracteres de preenchimento ou fica curto.
• Conversão de número grande — todas as tabelas Base58. A cadeia de bytes inteira é lida como um número enorme em base 256 e escrita de novo em base 58. Não há grupos nem preenchimento; o comprimento não se divide em nada, e cada byte zero inicial torna-se um símbolo zero inicial.

Cada alfabeto é impresso por completo em vez de descrito, porque duas ferramentas que imprimem caracteres diferentes com o mesmo nome nunca vão concordar, seja qual for o rótulo. As linhas RFC 4648 são normativas; as linhas Crockford e z-base-32 seguem o que o autor do formato publicou; as três linhas Base58 são convenções difundidas e não normas, por isso aparecem separadas.

O alfabeto deixa de fora I, L, O e U, para que nenhum símbolo possa ser lido como outro. O que sobra não distingue maiúsculas na entrada: i e l são lidos como o dígito 1, o é lido como o dígito 0, e os hífenes existem apenas para tornar uma cadeia longa mais fácil de ler. Por cima disso o formato define um símbolo de verificação opcional, que é o valor da cadeia de símbolos lida como número base 32, tomado módulo 37, e escrito com cinco símbolos extra para os valores 32 a 36.

O símbolo de verificação é calculado sobre a cadeia de símbolos, não sobre os bytes: como o codificador põe a zero à esquerda o último grupo, descodificar os mesmos caracteres volta sempre ao mesmo valor. É por isso que o valor de verificação da tabela pode ser reproduzido à mão só a partir da coluna codificada. Os cinco símbolos extra são *, ~, $, = e U para os valores 32, 33, 34, 35 e 36, por isso um símbolo de verificação nem sempre é um dígito ou uma letra.

O z-base-32 mantém o empacotamento de cinco bits do Base32 da RFC 4648 e só muda a ordem dos trinta e dois caracteres. A ordem foi escolhida para que os caracteres que uma pessoa mais provavelmente terá de escrever sejam os mais fáceis de escrever e os mais difíceis de confundir. Não tem preenchimento, por isso quem lê tem de saber quantos símbolos um valor deve ter; esse é o preço de um formato desenhado para ser lido à mão em primeiro lugar.

O Base58 sozinho não tem forma de distinguir uma cadeia com erro de uma correta, porque quase qualquer combinação dos seus cinquenta e oito caracteres é um número válido. O Base58Check resolve isso pondo os dados dentro de um invólucro: um byte de versão, depois a carga útil, depois os primeiros quatro bytes do SHA-256 aplicado duas vezes seguidas às duas primeiras partes. Um programa recetor recalcula esses quatro bytes e recusa a cadeia quando diferem. O byte de versão é o que diz a uma carteira se está a olhar para um endereço de pagamento, um endereço de script ou uma chave privada.

O gerador por trás do conversor recebe o byte de versão e a carga útil em hexadecimal e escreve a cadeia Base58Check; o verificador lê uma de volta, separa os quatro bytes de soma de verificação, recalcula-os e indica tanto o que encontrou como o que esperava. Uma soma de verificação errada significa que a cadeia foi escrita mal ou alterada — nunca significa que a própria carga útil está errada, pois a carga útil nunca é interpretada.

• « O Base64 é encriptação. » Não. Não há chave nem segredo; qualquer pessoa consegue reverter o resultado. O Base32 e o Base58 estão exatamente na mesma posição, e passar um valor pelos três também não acrescenta proteção.
• « Uma cadeia Base58 é um endereço Bitcoin. » Só quando também passa a soma de verificação Base58Check e tem um byte de versão que o software recetor reconhece. Cadeias Base58 aparecem em muitos outros sítios, incluindo identificadores simples sem qualquer soma de verificação.
• « Os três alfabetos Base58 são intermutáveis. » Usam os mesmos cinquenta e oito caracteres em três ordens diferentes, por isso os mesmos bytes produzem três cadeias diferentes. É preciso dizer a uma ferramenta qual usar, e esta página indica sempre qual usou.
• « O preenchimento faz parte do valor. » Os caracteres = só marcam o último grupo. Duas cadeias Base32 que diferem apenas no preenchimento descrevem os mesmos bytes, por isso o descodificador aceita uma cadeia com o preenchimento cortado.
• « Qualquer carácter serve. » Cada alfabeto é um conjunto fixo. Um carácter que não pertence a ele não tem valor, por isso o descodificador para e indica o carácter e a posição, em vez de adivinhar.

Porque é que o Base32 usa 2-7 e não 0-9? Porque a RFC 4648 escolheu o alfabeto para que ficasse dentro dos caracteres que um nome de domínio pode conter, e para que seja fácil de ler em voz alta. O Base32 Hex usa 0-9 A-V quando a ordenação natural importa mais.

Porque é que uma cadeia Base58 começa tantas vezes por 1? Cada byte zero inicial da entrada torna-se um 1 inicial (o primeiro carácter dos alfabetos Bitcoin e Flickr). Um byte de versão 0x00 é um byte zero, por isso a maioria dos endereços Bitcoin da rede principal começa exatamente com um 1.

O que carrega o botão Exemplo? O exemplo que pertence ao esquema e à direção que estão atualmente no ecrã, nunca um texto fixo. Ao codificador é dado o texto do exemplo do próprio esquema — os vetores da secção 10 da RFC 4648 para Base32 e Base32 Hex, o 12345 de Crockford, as linhas z-base-32 impressas acima — e ao descodificador é dada a cadeia codificada para o alfabeto selecionado, o que torna o exemplo utilizável nos dois sentidos. As três linhas Base58 levam o mesmo texto de propósito, para que mudar o esquema e premir Exemplo outra vez mostre lado a lado as três ordens dos mesmos cinquenta e oito caracteres. Com o símbolo de verificação Crockford marcado, o descodificador recebe o valor com o símbolo no fim, que é a única forma de ver o verificador aceitar um.

Esta página envia os meus dados para algum lado? Não. Todas as conversões acontecem neste separador do navegador, e a página não tem chamadas de rede de nenhum tipo. É também por isso que funciona com o ficheiro aberto diretamente do disco.

Qual devo usar para um segredo? Os segredos dos autenticadores TOTP e HOTP costumam ser Base32 no alfabeto da RFC 4648, porque o segredo tem de ser escrito à mão. Use aquele que o seu software recetor pedir, e nunca conte com a própria codificação para ter confidencialidade.