Gerador de hash grátis

O que uma função hash criptográfica realmente é

Uma função hash criptográfica recebe uma entrada de qualquer tamanho e produz uma saída de tamanho fixo, chamada hash, digest ou impressão digital. A mesma entrada produz sempre o mesmo hash; uma mudança de um único bit na entrada produz um hash radicalmente diferente (o "efeito avalanche"); e a função é computacionalmente inviável de inverter, dado um hash, na prática você não consegue encontrar a entrada que o gerou. Três propriedades de resistência tornam uma função hash "criptográfica": resistência à preimagem (dado um hash h, inviável encontrar uma entrada m tal que hash(m) = h), resistência à segunda preimagem (dado m₁, inviável encontrar uma m₂ diferente com o mesmo hash), e resistência a colisões (inviável encontrar duas entradas distintas com o mesmo hash). Uma função que perde a resistência a colisões pode continuar segura para alguns usos (integridade de arquivo) mas insegura para outros (assinaturas digitais). MD5 e SHA-1 estão exatamente nesse balde: colisões quebradas, mas preimagem ainda resistente.

Uma breve história de MD5, SHA-1, SHA-2 e SHA-3

MD2 / MD4 / MD5 são obra de Ron Rivest no MIT e na RSA Data Security. MD2 foi publicado em 1989; MD4 em 1990; MD5 foi publicado em 1991 e padronizado como RFC 1321 em abril de 1992. MD5 foi o hash dominante por uma década, padrão para checksums de download, armazenamento de senhas, deduplicação de arquivos e sistemas endereçáveis por conteúdo. O primeiro alerta veio em 1995 quando Hans Dobbertin publicou um ataque de colisão de rodada completa sobre o MD4, antecessor do MD5; a primeira colisão prática de MD5 completo chegou em agosto de 2004 quando Wang e Yu anunciaram duas mensagens de 128 bytes em colisão; Vlastimil Klima acelerou a busca por colisões em MD5 de horas para segundos em hardware comum em 2006. Marc Stevens, trabalhando com pesquisadores da TU Eindhoven e da EPFL, demonstrou uma colisão MD5 por prefixo escolhido no 25C3 em dezembro de 2008, produzindo um certificado falsificado de RapidSSL CA assinado em MD5. Quando o malware Flame apareceu em 2012, usando uma colisão MD5 para falsificar certificados do Microsoft Update, MD5 estava completamente quebrado para qualquer uso sensível à segurança.

SHA ("Secure Hash Algorithm") é uma família da NSA estadunidense. SHA-0 foi publicado como FIPS 180 em maio de 1993 e retirado em menos de um ano por defeitos de design não especificados. SHA-1 seguiu como FIPS 180-1 em abril de 1995, com uma mudança de um bit no message schedule que a NSA nunca explicou publicamente. SHA-1 tornou-se o hash padrão do final dos anos 1990 e dos anos 2000, usado pelo Git para hashes de commit, pelos certificados SSL/TLS, por praticamente qualquer esquema de assinatura. O primeiro ataque teórico por colisão veio em 2005 (Wang, Yin, Yu); uma colisão freestart em 2015 (Stevens, Karpman, Peyrin); e a primeira colisão SHA-1 completa foi entregue em 23 de fevereiro de 2017 como "SHAttered" (Stevens, Bursztein, Karpman, Albertini, Markov), que produziu dois arquivos PDF distintos com o mesmo hash SHA-1. Em janeiro de 2020 o ataque de prefixo escolhido "SHA-1 is a Shambles" (Leurent e Peyrin, custo total de aproximadamente USD 45 000 em aluguel de GPU) tornou viável a falsificação em nível de certificado, acelerando a transição para SHA-256 que o projeto Git já havia começado a planejar em 2018. SHA-1 está agora formalmente depreciado pelo NIST para assinaturas digitais e certificados.

SHA-2 é a família que substituiu SHA-1: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 e SHA-512/256, publicada como FIPS 180-2 em agosto de 2002. SHA-2 foi um design defensivo, saídas maiores, mais rodadas, estado interno maior, e vinte e três anos depois continua sem ser quebrado. SHA-256 é o padrão moderno para assinaturas digitais, certificados, JWT, hashes de bloco do Bitcoin, armazenamento endereçável por conteúdo e a maior parte da verificação de integridade de arquivos. SHA-3 é um design fundamentalmente diferente, a construção esponja Keccak por Bertoni, Daemen, Peeters e Van Assche, selecionada em uma competição do NIST de cinco anos aberta em 2007 e vencida pelo Keccak em outubro de 2012; publicada como FIPS 202 em agosto de 2015. SHA-3 não é um substituto para SHA-2 (SHA-2 ainda é seguro); é uma alternativa defensiva com estrutura interna completamente diferente, de forma que uma quebra criptanalítica futura de SHA-2 não afetaria necessariamente SHA-3. Esta ferramenta produz SHA-1, SHA-256, SHA-384 e SHA-512 (o conjunto suportado pela Web Crypto API) mais MD5 (via uma implementação em JavaScript, já que a Web Crypto API omite MD5 deliberadamente).

Comparação de algoritmos

Algoritmo	Saída	Segurança
MD5	128 bits (32 caracteres hex)	Quebrado · não use para segurança
SHA-1	160 bits (40 caracteres hex)	Fraco · obsoleto
SHA-256	256 bits (64 caracteres hex)	Forte · recomendado
SHA-384	384 bits (96 caracteres hex)	Forte
SHA-512	512 bits (128 caracteres hex)	Forte

Onde aparecem os hashes criptográficos

• Integridade de arquivo / checksums. Espelhos de distribuições Linux publicam hashes SHA-256 (e historicamente MD5/SHA-1) ao lado dos downloads de ISO; o usuário calcula o hash do arquivo baixado e compara com o valor publicado. Uma divergência significa que o download foi corrompido ou adulterado. shasum, sha256sum e md5sum são as ferramentas Unix padrão.
• Armazenamento de senhas, mas NUNCA como hash puro. Armazenar SHA-256(senha) diretamente é perigoso porque rainbow tables (mapas pré-calculados de (senha → hash)) tornam senhas com hash puro reversíveis em milissegundos. O padrão correto é uma função de hashing de senhas (KDF) com sal por usuário e fator de custo ajustável: Argon2id (RFC 9106, 2021, recomendação moderna), scrypt (RFC 7914, Percival 2009) ou bcrypt (Provos e Mazières, USENIX 1999). Os três combinam um sal (para que senhas idênticas produzam hashes armazenados distintos) com um cálculo deliberadamente caro (para que ataques de força bruta sejam freados pelo custo de hardware). Esta ferramenta calcula hashes brutos, útil para muitas coisas, mas inadequado para armazenamento de senhas sozinho.
• Assinaturas digitais. Assina-se o hash, não os dados, os dados são longos demais para assinar com eficiência. RSA, DSA, ECDSA e EdDSA todos assinam um hash da mensagem. A função hash usada precisa ser resistente a colisões (caso contrário um atacante pode substituir uma mensagem em colisão); é exatamente por isso que MD5 e SHA-1 estão depreciados para assinaturas.
• Armazenamento endereçável por conteúdo do Git. Cada objeto Git (blob, tree, commit, tag) é identificado pelo SHA-1 do seu conteúdo. A escolha de design de Linus Torvalds em 2005 está hoje em meio a uma transição plurianual para SHA-256, motivada pela quebra de colisões do SHA-1. Git for Windows e Git oficial entregam ambos suporte SHA-256; a migração em produção é gradual.
• Bitcoin e Ethereum. Bitcoin usa duplo-SHA-256 para hashes de bloco e IDs de transação (a função hash domina o custo da mineração de Bitcoin, ASICs existem unicamente para calcular SHA-256 rapidamente). Ethereum usa Keccak-256 (o Keccak original antes dos ajustes de padronização do NIST; às vezes chamado de "SHA-3 menos a mudança de padding").
• Verificação de assinatura JWT. JSON Web Tokens são tipicamente assinados com HMAC-SHA-256 (nome do algoritmo "HS256" na spec do JWT) ou com RSA/ECDSA sobre um hash SHA-256. A assinatura permite ao receptor verificar que o token veio do emissor e não foi adulterado.
• Subresource Integrity (SRI). O atributo integrity="sha256-..." nas tags <script> e <link> permite aos navegadores verificar que um script hospedado em CDN não foi modificado antes de executá-lo, defesa contra CDNs comprometidos.
• Assinatura de requisições de API. AWS Signature Version 4 usa HMAC-SHA-256 para assinar cada requisição de API com a chave secreta de acesso do usuário. Isso autentica a requisição sem mandar o segredo pela rede e impede ataques de replay via timestamp.

Quebra de colisões vs quebra de preimagem, por que MD5 ainda é usado

Confusão comum: se MD5 está "quebrado", por que md5sum ainda vem em toda distribuição Linux? A resposta é a distinção entre resistência a colisões (quebrada no MD5) e resistência à preimagem (ainda intacta no MD5). Um ataque por colisão permite a um atacante construir duas entradas diferentes com o mesmo hash; isso importa para assinaturas digitais (em que um atacante pode forjar um par em colisão, fazer assinar um e substituir o outro) e para qualquer aplicação em que a função hash supostamente amarra uma entrada específica. Um ataque por preimagem, em contraste, permitiria a um atacante recuperar a entrada original a partir de um hash, é isso que de fato quebraria um checksum de download, um hash de senha ou um identificador endereçável por conteúdo. A resistência à preimagem do MD5 não foi quebrada; os melhores ataques de preimagem publicados continuam próximos do limite teórico de 2¹²⁸, computacionalmente inviáveis em qualquer hardware existente ou previsto. Então MD5 (e SHA-1) continuam legítimos para: verificação de integridade de arquivo quando você confia na fonte do hash publicado (um atacante que pode substituir o arquivo presumivelmente também pode substituir o hash, então o modelo de ameaça é "corrupção acidental", não "adulteração deliberada"); chaves de cache e deduplicação em que você controla as duas pontas; construções HMAC (HMAC-MD5 continua seguro porque a estrutura do HMAC é robusta diante da fraqueza de colisão do MD5, embora HMAC-SHA-256 seja preferido para código novo). Onde MD5 deve ser substituído: assinaturas digitais, hashes de certificado, em qualquer lugar onde um atacante possa forjar a entrada.

A Web Crypto API e a omissão deliberada do MD5

Os navegadores modernos expõem o hashing através de crypto.subtle.digest(algorithm, data), uma função assíncrona que devolve o hash como ArrayBuffer. Algoritmos suportados: SHA-1, SHA-256, SHA-384, SHA-512. Repare no que não está nessa lista: MD5 está deliberadamente omitido. O W3C Web Crypto Working Group tomou a decisão explícita de deixar MD5 de fora, raciocinando que qualquer uso de MD5 em um navegador era ou legacy (melhor tratado com um polyfill) ou errado (e não deveria ser facilitado). O suporte de MD5 desta ferramenta vem de uma pequena implementação em JavaScript (~10 KB) embutida na página; todo o resto (SHA-1, SHA-256, SHA-384, SHA-512, mais todas as variantes HMAC) passa pela Web Crypto para processamento em velocidade nativa. A Web Crypto API só está disponível em contextos seguros (HTTPS ou localhost), abrir esta ferramenta sobre HTTP simples desativaria silenciosamente o hashing SHA.

Formatos de saída: Hex, Base64, Base32

Hashes são binários por natureza, um hash de 256 bits são 32 bytes de dados opacos. Para exibi-los ou transportá-los, codificam-se como texto. Hex (Base16) é a codificação mais comum: cada byte vira dois caracteres hex, então a saída SHA-256 são 64 caracteres hex. Universal, legível, dobra o tamanho. Base64 compacta bytes mais densamente (3 bytes → 4 caracteres); SHA-256 em Base64 são 44 caracteres (com padding) ou 43 (sem). Usado em JWT (a assinatura é codificada em Base64URL), em atributos integrity SRI, e onde compactação importa. Base32 (RFC 4648) usa 32 caracteres que excluem os visualmente ambíguos (sem distinção 0/O, 1/I/L); usado em chaves secretas TOTP, ULIDs e endereços onion. Esta ferramenta produz hex por padrão, o formato universal que toda outra ferramenta entende.

HMAC, hashing com chave para autenticação

HMAC (Hash-based Message Authentication Code) é uma construção definida em RFC 2104 (Krawczyk, Bellare, Canetti, fevereiro de 1997) que transforma qualquer função hash criptográfica em um código de autenticação com chave. A construção é HMAC(K, m) = H((K' XOR opad) || H((K' XOR ipad) || m)), onde K' é uma chave derivada do segredo K, e opad/ipad são pads XOR fixos. A estrutura é provavelmente segura enquanto o hash subjacente o for, e notavelmente continua segura mesmo quando o hash subjacente tem resistência a colisões fraca (por isso HMAC-MD5 ainda é considerado seguro, e por isso HMAC-SHA1 está OK em TLS mesmo após a quebra de colisões do SHA-1). HMAC tem três usos principais: assinatura de requisições de API (AWS Signature v4, webhooks do GitHub, webhooks do Stripe), em que o receptor verifica que a requisição veio do detentor do segredo; integridade de JWT (HS256 = HMAC-SHA-256); e derivação de chave baseada em senha (PBKDF2 usa HMAC internamente). O modo HMAC desta ferramenta recebe uma chave secreta e produz o HMAC da entrada sob essa chave.

Escopo honesto: para que esta ferramenta serve e não serve

Esta ferramenta calcula hashes criptográficos brutos de um texto ou arquivo de entrada. Útil para: verificar downloads de arquivo contra checksums publicados, gerar identificadores endereçáveis por conteúdo, calcular valores HMAC para depurar APIs, comparar a integridade de duas cópias de um arquivo e aprender para que entradas específicas dão. Não útil para: armazenamento de senhas (use uma função real de hashing de senhas como Argon2id, scrypt ou bcrypt com sal e fator de custo apropriados); reverter hashes (que é a razão de existir das funções hash e não é possível por design); ou gerar hashes SHA-3 / Keccak (esta ferramenta hoje emite SHA-1, SHA-256, SHA-384 e SHA-512 da família SHA-2, mais MD5, SHA-3 está na lista de funcionalidades futuras); gerar hashes BLAKE2 ou BLAKE3. Para BLAKE3 (o hash moderno de alta vazão para armazenamento endereçável por conteúdo), use a CLI dedicada; para armazenamento de senhas, use a biblioteca bcrypt/scrypt/Argon2id da sua aplicação diretamente.

Privacidade: por que apenas no navegador importa aqui

Hashear um arquivo num servidor exige enviá-lo. Para verificação de download comum isso é indiferente, você já confia na fonte. Para hashear documentos internos, identidades digitalizadas, capturas de UIs em desenvolvimento ou qualquer arquivo que você não queira ver copiado no disco rígido de um estranho, o hashing do lado servidor é um vazamento. Esta ferramenta lê o arquivo diretamente no seu navegador usando a File API e o hashea localmente, nada sai do seu dispositivo. Verifique abrindo a aba Network das DevTools enquanto clica em Hashear, ou coloque a página off-line (modo avião) depois de carregar e confirme que a ferramenta segue funcionando. A Web Crypto API exige HTTPS, mas não exige acesso de rede em tempo de execução.

Perguntas frequentes

Para que serve o MD5 se ele está quebrado?

O MD5 ainda é amplamente utilizado para fins não relacionados à segurança: verificações de integridade de arquivos (verificação de downloads), deduplicação, chaves de cache e somas de verificação. Nunca deve ser usado para hashing de senhas ou assinaturas digitais.

Posso reverter um hash para obter o texto original?

Não. Funções de hash são projetadas para serem unidirecionais. No entanto, atacantes usam tabelas pré-calculadas (tabelas arco-íris) para procurar hashes comuns. É por isso que senhas devem ser hasheadas com funções de hash lentas e com sal, como bcrypt, não com SHA-256 puro.

Meu arquivo é enviado quando o faço hash?

Não. O arquivo é lido diretamente no seu navegador usando a File API e hasheado localmente usando a Web Crypto API (para SHA) ou uma implementação em JavaScript puro (para MD5). Nada é enviado a nenhum servidor.

Qual a diferença entre SHA-256 e SHA-3?

SHA-256 faz parte da família SHA-2 (FIPS 180-2, agosto de 2002), construção Merkle-Damgård, projetada pela NSA. SHA-3 (FIPS 202, agosto de 2015) é a família Keccak, construção esponja, projetada por Bertoni, Daemen, Peeters e Van Assche, selecionada em uma competição pública do NIST. SHA-3 não é um substituto para SHA-2 (SHA-2 ainda é seguro); é uma alternativa defensiva com estrutura interna fundamentalmente diferente, de forma que uma quebra hipotética futura de SHA-2 não afetaria necessariamente SHA-3. Para novas aplicações em 2026, SHA-256 ainda é o padrão correto; SHA-3 vem sendo cada vez mais usado em Ethereum e esquemas pós-quânticos. Esta ferramenta hoje suporta SHA-2 (SHA-1 / 256 / 384 / 512); SHA-3 está na lista de funcionalidades futuras.

O que é HMAC e quando preciso dele?

HMAC (Hash-based Message Authentication Code, RFC 2104, 1997) é uma construção de hash com chave que prova que uma mensagem foi criada por alguém que conhece um segredo compartilhado. Você precisa dele sempre que estiver verificando que uma requisição veio da parte certa, verificação de assinaturas de webhooks do GitHub (o segredo é a chave de assinatura do webhook), assinaturas de webhooks do Stripe, assinaturas de requisições de API da AWS (Signature v4 é HMAC-SHA-256) ou assinaturas JWT (HS256 = HMAC-SHA-256). HMAC continua seguro mesmo quando o hash subjacente tem resistência a colisões fraca, por isso HMAC-MD5 ainda é considerado seguro, embora HMAC-SHA-256 seja o padrão moderno para código novo.

Meu arquivo é enviado quando eu o hasheio?

Não. O arquivo é lido diretamente no seu navegador usando a File API e hasheado localmente, via Web Crypto API para algoritmos da família SHA, via uma pequena implementação em JavaScript para MD5. Nada cruza a rede, verifique na aba Network das DevTools enquanto computa, ou coloque a página off-line após carregar. Seguro para hashear documentos internos, identidades digitalizadas, capturas de UIs em desenvolvimento ou qualquer arquivo que você não queira ver copiado no disco rígido de um estranho.

Ferramentas relacionadas