Base64 não é criptografia — e aumenta o arquivo em 33%

O “33%” é o limite, não a regra

Base64 empacota 3 bytes de entrada em 4 caracteres de saída — 24 bits viram quatro grupos de 6 bits, cada um endereçando um dos 65 caracteres da Tabela 1 do RFC 4648 (64 letras/números/símbolos mais o = de preenchimento). Quando o texto é um múltiplo exato de 3 bytes, a conta fecha redonda: 33,33% a mais, sempre — nas linhas de 3, 6, 9 e 12 bytes da tabela acima, sem exceção.

O problema é que a maioria dos textos NÃO é múltiplo de 3, e o RFC já previa os outros dois casos, na Seção 4: sobrando 1 byte no final (8 bits), a saída leva DOIS caracteres de preenchimento; sobrando 2 bytes (16 bits), leva UM. Cada = sobra é espaço puro — não carrega informação nenhuma, só completa o grupo de 4. E é exatamente aí que o overhead dispara: um único byte — uma letra, um dígito — vira 4 caracteres, 300% a mais. Duas letras viram os mesmos 4 caracteres, 100% a mais.

A tabela mostra os dois piores casos decaindo a cada ciclo de 3 bytes — resto 1 vai de 300% em 1 byte para 100% em 4, 71,43% em 7 e 60% em 10 — mas nunca some: para saber se um texto QUALQUER vai custar perto de 33% ou perto de 300%, é preciso saber o tamanho dele em bytes, não só “é grande ou pequeno”.

Mesmo o pior caso converge — só devagar

Todas as cinco linhas acima são, de propósito, o caso mais caro (1 byte sobrando no final) — e mesmo ele desce de 41,94% em 31 bytes para 33,33% em 300.001, cada vez mais perto dos 33,33% — o limite que a fração 4/3 menos 1 já cravava antes de qualquer tabela, porque todo múltiplo de 3 bytes bate nele exatamente. O “33%” que todo artigo cita é esse limite: verdadeiro para praticamente qualquer arquivo grande, e enganoso para o PIN, o token ou a senha de poucos bytes que alguém cola aqui pra “disfarçar”.

Por que o formato existe: transporte, nunca sigilo

O RFC 4648 é claro sobre o motivo de existir, logo na Introdução: “Base encoding of data is used in many situations to store or transfer data in environments that, perhaps for legacy reasons, are restricted to US-ASCII data” — codificar dado binário para caber num canal que só aceita texto puro. A razão histórica está no RFC 2045, o MIME: o SMTP definido pelo RFC 821 “restricts mail messages to 7bit US-ASCII data”, então um anexo binário — uma imagem, um PDF — precisava virar texto de 7 bits antes de viajar por e-mail. Isso é transporte, não segredo — o mesmo RFC 2045 fala em “encoding such data into a 7bit short line format”, nunca em escondê-lo de quem lê.

A Seção 12 nega o mito com todas as letras

A Seção 12 do RFC 4648, “Security Considerations”, diz o seguinte sobre Base64 e os irmãos dele (Base32, Base16):

“Base encoding visually hides otherwise easily recognized information, such as passwords, but does not provide any computational confidentiality. […] Base encoding adds no entropy to the plaintext, but it does increase the amount of plaintext available.”

Em português: Base64 esconde uma senha DOS OLHOS — ninguém lê “P@ssw0rd” olhando pra UEBzc3cwcmQ= — mas não esconde nada da CONTA. O mesmo parágrafo do RFC ainda cita um incidente real de segurança causado exatamente por essa confusão: alguém publicando um trecho de protocolo de rede para ilustrar outro problema, sem perceber que a senha ali dentro estava só “disfarçada”, não protegida.

E dá pra confirmar isso lendo a assinatura de verdade da função que decodifica, em base64.ts: processar recebe texto e direcao — só isso. Não existe um terceiro parâmetro de senha, chave ou segredo, porque o alfabeto Base64 é público desde 2006 (a Tabela 1 do RFC, as mesmas 65 posições para qualquer implementação do planeta). Rodamos a bateria inteira da tabela acima nos dois sentidos — codificar e depois decodificar, sem passar nada além do texto e da direção — e as 12 linhas recuperaram o original. Não é falta de sorte: é o que o RFC descreve como “does not provide any computational confidentiality” — quem sabe o alfabeto (todo mundo) decodifica de primeira, sempre.

A senha padrão daqui, em Base64

A senha padrão que o gerador deste site sorteia — 16 caracteres, os quatro grupos ligados — vira Base64 50% maior, pela mesma conta acima. E a força dela, pela conta que o próprio gerador publica (bitsDeEntropia, importada aqui de verdade, não recalculada), é de 99,1 bits de entropia — o tamanho do espaço de busca de quem tenta adivinhar a senha sem conhecer o sorteio.

Codificar essa senha em Base64 não muda o segundo número em NADA: 0 bits. A força inteira dela vem do sorteio de crypto.getRandomValues que o gerador descreve; o Base64 por cima só paga 50% a mais de espaço para transportar os mesmos bytes, sem acrescentar nem tirar um bit de dificuldade de quem tenta quebrá-la. Guardar uma senha em Base64 “para não deixar em texto puro” é gastar espaço sem comprar segurança nenhuma — o alfabeto que decodifica de volta é o mesmo RFC público há vinte anos.