Gerador de Hash

O que uma função de hash de fato faz

Um hash criptográfico recebe uma entrada de tamanho arbitrário e devolve um digest de tamanho fixo — 128, 160, 256, 384 ou 512 bits, conforme o algoritmo. O mapeamento é determinístico (a mesma entrada sempre produz a mesma saída), unidirecional (não dá pra rodar ao contrário) e resistente a colisão (é computacionalmente inviável encontrar duas entradas com o mesmo digest — ao menos para os algoritmos modernos). Esse primitivo sustenta o content addressing do Git, a verificação de integridade em gerenciadores de pacote, deduplicação em object storage e tokens de rate-limit em APIs.

Três propriedades importam na escolha: resistência a colisão (quão difícil é forjar uma segunda entrada?), tamanho do digest (mais longo é melhor para identificadores únicos em escala) e velocidade (cada byte hasheado é CPU que você não vai gastar em outra coisa).

Cinco algoritmos, três eras

O MD5 (Rivest, RFC 1321, abril de 1992) é o mais antigo dos cinco. Produz um digest de 128 bits em cerca de 6 ciclos por byte em CPUs modernas — segue sendo a opção mais rápida para checksums sem requisito de segurança. Não use onde resistência a colisão importa — explico na próxima seção.

O SHA-1 (NIST, 1995) entrega um digest de 160 bits. Por muito tempo foi o padrão para assinaturas digitais e a chave de content addressing do Git. Hoje está obsoleto para uso de segurança; o próprio Git já está migrando para SHA-256.

A família SHA-2 — SHA-256, SHA-384 e SHA-512 — foi especificada pelo NIST na FIPS 180-4 e representa a linha de base moderna. SHA-256 é o que TLS, Bitcoin, Git novo e praticamente qualquer sistema novo escolhe por padrão. SHA-384 aparece nos cipher suites do TLS 1.3. SHA-512 é mais rápido que SHA-256 em CPUs 64-bit (opera em palavras de 64 bits nativamente), mas devolve um digest mais longo — útil quando você quer uma margem de colisão folgada ou está derivando várias sub-chaves de um único hash.

Por que MD5 e SHA-1 não devem assinar nada

Em agosto de 2004, Xiaoyun Wang e seu grupo na Universidade de Shandong anunciaram colisões práticas em MD5 na rump session do CRYPTO 2004; o ataque completo saiu no ano seguinte em Advances in Cryptology — EUROCRYPT 2005 (LNCS 3494, pp. 19–35). Em meses, pesquisadores geravam pares de arquivos PostScript e PDF com o mesmo hash. Em 2008, um ataque de prefixo escolhido permitiu forjar uma Autoridade Certificadora rogue. MD5 saiu de cena para assinaturas digitais e certificados desde então.

O SHA-1 teve queda mais lenta. Ataques teóricos começaram em 2005. Em 23 de fevereiro de 2017, o CWI Amsterdam e o Google anunciaram em conjunto o SHAttered — a primeira colisão prática de SHA-1, materializada em dois PDFs com o mesmo digest. O ataque custou cerca de US$ 110.000 de computação na AWS. Navegadores e ACs depreciaram certificados SHA-1 ao longo do ano seguinte; Microsoft e Mozilla cortaram suporte a novos certificados SHA-1 por completo.

O que uma colisão habilita na prática? Falsificação de assinatura: se você assina hash(X) e um atacante encontra Y com hash(Y) = hash(X), sua assinatura passa a cobrir Y retroativamente. Por isso algoritmos depreciados são perigosos para assinaturas digitais, certificados TLS, tokens de redefinição de senha, assinatura de código — qualquer cenário onde o hash compromete você com um payload que não viu byte a byte.

Quando MD5 e SHA-1 ainda servem

O que quebra é a resistência a colisão. As outras propriedades — determinismo, unidirecionalidade para entradas desconhecidas, distribuição uniforme da saída — continuam valendo. Por isso MD5 e SHA-1 seguem perfeitamente úteis em usos não-adversariais: checksum de arquivo contra corrupção acidental, chave de dedup em cache content-addressed, invalidação de cache estilo ETag, particionamento de entradas em shards. A regra simples é se um atacante que controla a entrada não ganha nada colidindo, pode usar o hash barato. Se algo na sua modelagem de ameaça depende de "duas entradas distintas não podem produzir o mesmo digest", troque para SHA-256.

Hex, Base64, Base64URL — três vistas dos mesmos bytes

O digest é uma sequência de bytes. Como você os exibe é outra história. O Hex é a representação universal: cada byte vira exatamente dois caracteres de [0-9a-f], então o comprimento é previsível e a renderização é locale-safe. A saída fica cerca de duas vezes mais longa que os bytes; para SHA-256, são 64 caracteres.

O Base64 empacota três bytes em quatro caracteres imprimíveis, deixando a string final ~33% maior que o cru (em vez de 100% como no hex). É a representação padrão em HTTP basic auth, S/MIME e várias APIs de storage. Usa + e / no alfabeto e = como padding, o que torna inseguro jogar direto em URL.

O Base64URL (RFC 4648 §5) resolve isso: troca + por - e / por _, e tipicamente remove o padding. O resultado é URL-safe e filename-safe. JSON Web Tokens, OAuth 2.0 PKCE e a plataforma web moderna falam Base64URL nativamente. Se você está integrando algo do ecossistema JWT ou OAuth, é esse o formato.

Modo Verificar: quando o hash já existe

A aba Verificar recebe uma entrada e um digest esperado e diz se batem. Três fluxos do mundo real se apoiam nisso:

• Integridade de download. Um fornecedor publica um SHA-256 ao lado de um instalador ou imagem de container. Você cola os dois no modo Verificar e confirma que os bytes que tem em mãos são os que o fornecedor pretendia entregar.
• Content addressing. Git e IPFS identificam objetos pelo hash. O modo Verificar permite confirmar que um payload ainda corresponde a um identificador conhecido sem precisar escrever um script.
• Comparação de token. Um link de redefinição traz token_hash=... e seu backend guarda o mesmo valor. Você cola os dois e confirma o round-trip sem rodar nada do lado servidor.

A comparação é tolerante: hex casa independente do caixa, Base64 com padding casa com Base64URL sem padding quando os bytes subjacentes são iguais e espaço em branco no final é ignorado. Internamente comparamos os bytes decodificados em tempo constante — para um hash digitado pelo usuário não muda nada, mas é o hábito correto para quando o mesmo primitivo for reutilizado em verificação de HMAC.

Privacidade: nada sai do seu navegador

Geradores de hash server-side vazam a entrada digitada via logs de load balancer, intermediários de proxy, logs de aplicação e qualquer middleware de analytics que capture corpos de POST. Isso pesa quando a entrada é uma senha, uma seed de carteira, um identificador pessoal ou um documento em rascunho. Esta ferramenta hasheia localmente — o SubtleCrypto.digest() da Web Cryptography API (W3C Recommendation desde janeiro de 2017) está em todo navegador evergreen. A implementação do MD5 é JavaScript puro (o Web Crypto exclui MD5 de propósito) e vem junto com a página. Zero requisição de rede.

A barra de "Entradas recentes" é um atalho que preserva privacidade: ela lembra a sua entrada recente e qual algoritmo você escolheu, para você iterar no mesmo payload sem recolar. Ela deliberadamente não guarda o hash resultante — quando você clica numa entrada antiga, o hash é recalculado em milissegundos. Uma inspeção regulatória do payload armazenado (ou simplesmente localStorage.getItem('recent-inputs:hash-generator:v1') no devtools) vai mostrar apenas a entrada, o rótulo do algoritmo e o timestamp. Isso conversa diretamente com o tratamento que a LGPD dá à pseudonimização: o artigo 12 considera dado anonimizado só quando o processo é irreversível pelos meios do próprio controlador, e o guia de anonimização que a ANPD colocou em consulta pública em 2024 recomenda explicitamente desenhos onde a saída sensível nunca toca o disco. Para a comunidade dev BR — que frequentemente brinca com "hash de CPF" em ambientes de teste —, manter o digest fora do localStorage é um filtro útil contra logs que vazariam o link entre identificador real e token.