SHA-1 vs SHA-256 vs SHA-512: Escolhendo o Algoritmo de Hash Certo em 2026

Abra um certificado TLS, um banco de dados de objetos do Git, um cabeçalho de bloco do Bitcoin, um gerenciador de pacotes Linux e um manifesto de imagem Docker — você vai encontrar um hash SHA em cada um deles. Mas não o mesmo SHA. SHA-1, SHA-256, SHA-384, SHA-512, SHA-3: a família abrange três décadas, duas linhagens de design e um ataque de colisão decisivo que quebrou o membro mais antigo em produção.

Este guia mapeia toda a família para que você possa escolher o algoritmo certo para o seu caso de uso sem ficar em dúvida.

Árvore de Decisão Rápida

Antes de mergulhar nos detalhes, aqui está o resumo em uma tabela que a maioria dos desenvolvedores realmente precisa:

Sua Situação	Melhor Escolha	Motivo
Certificado TLS/HTTPS	SHA-256 (mínimo), SHA-384 para alta segurança	Exigido pelos Requisitos de Base do CA/Browser Forum
Assinatura JWT (HMAC ou RSA)	SHA-256 (HS256/RS256)	Suporte universal; SHA-384/512 para regimes de conformidade
Checksum de integridade de software	SHA-256	Padrão da indústria; amplamente compreendido
Integridade arquivística ou de longo prazo	SHA-512	Saída maior, margem segura para as próximas décadas
Endereçamento de conteúdo (IPFS, OCI)	SHA-256	Padrão de fato para armazenamento endereçado por conteúdo
Git (lendo/gravando repositórios existentes)	SHA-1 para existentes; SHA-256 para novos via `--object-format=sha256`	Git está em migração; SHA-1 ainda domina
Interoperação com Ethereum	Keccak-256 (não o NIST SHA-3)	Ethereum usa a variante Keccak anterior à padronização
Sistemas classificados ou defesa em profundidade	SHA-384 ou SHA-512	NSA Suite B; combina com AES-256-GCM
Código novo, sem restrições de legado	SHA-3 (SHA3-256)	Linhagem de design diferente; sem vulnerabilidade de extensão de comprimento
Armazenamento de senhas	Nenhum dos acima	Use bcrypt, Argon2id ou scrypt — SHA é rápido demais

A Família SHA em Resumo

Algoritmo	Padrão	Bits de Saída	Chars Hex	Ano	Status NIST	Uso Principal Hoje
SHA-1	FIPS 180-4	160	40	1995	Descontinuado (2011), retirado para assinaturas digitais	Legado do Git, impressões digitais
SHA-256	FIPS 180-4	256	64	2001	Atual	TLS, JWT, Bitcoin, checksums
SHA-384	FIPS 180-4	384	96	2001	Atual	Suite B, TLS de alta segurança
SHA-512	FIPS 180-4	512	128	2001	Atual	Arquivamento, LUKS, HMAC-SHA-512
SHA-3 (qualquer variante)	FIPS 202	224/256/384/512	varia	2015	Atual	Linhagem alternativa, aceleração por hardware

SHA-1 e SHA-2 (o grupo 256/384/512) compartilham uma construção de Merkle-Damgard. SHA-3 usa uma construção de esponja — uma distinção que importa mais do que pode parecer à primeira vista, abordada abaixo.

SHA-1: Quebrado, Mas Não Morto

SHA-1 foi o cavalo de batalha dos anos 2000. Certificados SSL, e-mail S/MIME, impressões digitais PGP e Git convergiram para ele. Então, em fevereiro de 2017, o Google e o CWI Amsterdam publicaram o SHAttered: um ataque de colisão de prefixo escolhido que produziu dois arquivos PDF distintos com hashes SHA-1 idênticos. O ataque exigiu aproximadamente 6,5 × 10^19 avaliações de SHA-1 — custoso em 2017, mas viável hoje com computação em nuvem.

O NIST já havia descontinuado o SHA-1 para assinaturas digitais em 2011 (Publicação Especial NIST 800-131A). A demonstração do SHAttered acelerou a limpeza: os navegadores pararam de confiar em certificados TLS com SHA-1 em 2017, e o CA/Browser Forum tornou o SHA-256 obrigatório para novas emissões.

Para que o SHA-1 ainda é utilizado:

Banco de dados de objetos do Git: O Git foi projetado com SHA-1 como um hash de conteúdo rápido, não como uma primitiva de segurança. O formato do repositório codifica IDs de objeto de 40 caracteres hexadecimais. Um caminho de migração para SHA-256 (git init --object-format=sha256) existe, mas a adoção é lenta porque toda plataforma de hospedagem, toda ferramenta de CI e todo clone existente precisariam migrar em sincronia.
Impressões digitais de sistemas legados: Impressões digitais de chaves de host SSH antigas, impressões digitais de chaves PGP e esquemas de número de série de certificados ainda expõem valores SHA-1. Esses são informativos e, na maioria dos contextos, não são críticos para a segurança.

O que fazer: Não use SHA-1 para nada novo. Para o Git, o risco de colisão é baixo para fluxos de trabalho típicos de desenvolvimento de software (um atacante precisaria controlar ambos os arquivos na colisão), mas novos projetos usando --object-format=sha256 são a direção correta a longo prazo.

Gere um hash SHA-1 no seu navegador: Gerador de SHA-1.

SHA-256: O Cavalo de Batalha

SHA-256 é o algoritmo que mantém a internet funcionando em 2026. Todo certificado TLS emitido por uma CA pública usa SHA-256 para seu hash de assinatura. Todo JWT assinado com HS256, RS256 ou ES256 usa SHA-256 internamente. A prova de trabalho do Bitcoin é SHA-256 duplo. O hash de conteúdo do Docker é SHA-256. A integridade de pacotes do npm usa SHA-256.

Os motivos são práticos:

Margem de segurança: 256 bits de saída significa 2^128 operações para um ataque de pré-imagem por força bruta — além de qualquer hardware concebível no futuro previsível. O nível de segurança real é ligeiramente inferior devido a ataques de colisão por aniversário (2^128 operações), mas ainda inexpugnável.
Aceleração por hardware: SHA-256 está implementado em silício em todo CPU Intel Goldmont+ (extensão SHA-NI), em todo chip Apple Silicon, em todo processador ARMv8 e em ASICs dedicados em appliances de rede e controladores de armazenamento. Quando o caminho de hardware é utilizado, o throughput do SHA-256 supera o de muitas alternativas de software aparentemente mais rápidas.
Suporte universal em bibliotecas: Toda biblioteca TLS, toda biblioteca JWT e toda biblioteca padrão de linguagem implementa SHA-256. Você não vai encontrar uma parede de incompatibilidade.

Para endereçamento de conteúdo, verificação de integridade e a maioria dos fluxos de trabalho de assinatura, SHA-256 é o padrão correto a menos que um padrão específico exija outra coisa.

Gere um hash SHA-256 no seu navegador: Gerador de SHA-256.

SHA-384: A Especialidade TLS

SHA-384 é o SHA-512 truncado para 384 bits. Foi criado para fornecer um nível de segurança de 192 bits (metade do tamanho da saída é o piso de resistência a colisões) e incluído na criptografia NSA Suite B ao lado de AES-256-GCM e chaves de curva elíptica P-384.

Duas propriedades tornam o SHA-384 especificamente atraente para TLS:

Imunidade a extensão de comprimento neste tamanho de saída: SHA-256 e SHA-512 são vulneráveis a ataques de extensão de comprimento — um atacante que conhece H(segredo || mensagem) pode calcular H(segredo || mensagem || extensão) sem conhecer o segredo. SHA-384 e SHA-512/256 são truncados a partir do estado interno completo, portanto a extensão de comprimento não se aplica. Se você estiver usando hashes SHA brutos como MACs (em vez de HMAC), SHA-384 é mais seguro.
Conformidade com Suite B: Organizações obrigadas a atender aos requisitos do suite NSA/CNSA (Commercial National Security Algorithm) devem usar SHA-384 ou SHA-512 junto com RSA-3072+, ECDH P-384 e AES-256. Se seu cliente é uma agência federal dos EUA ou um contratante operando sob os requisitos FIPS 140-3, SHA-384 pode ser obrigatório.

SHA-384 não é significativamente mais seguro que SHA-256 para a maioria dos casos de uso — a diferença prática entre resistência a colisões de 128 bits e 192 bits é teórica nos níveis de computação atuais. Escolha-o quando a conformidade ou o pareamento com Suite B o exigir, não para uso genérico.

Gere um hash SHA-384 no seu navegador: Gerador de SHA-384.

SHA-512: Quando Você Precisa de Mais Bits

SHA-512 produz um digest de 512 bits (128 caracteres hexadecimais). Em hardware de 64 bits, ele muitas vezes é mais rápido que SHA-256 porque o algoritmo opera em palavras de 64 bits em vez de palavras de 32 bits — o escalonamento interno do SHA-256 usa aritmética de 32 bits, enquanto o SHA-512 usa aritmética de 64 bits que se mapeia de forma mais eficiente nos CPUs modernos.

Benchmarks em hardware de 64 bits (indicativo; Web Crypto API do navegador):

Algoritmo	Throughput Aproximado
SHA-1	~600 MB/s
SHA-256	~500 MB/s
SHA-384	~700 MB/s
SHA-512	~700 MB/s
SHA-3-256	~300 MB/s

Nota: SHA-384 e SHA-512 compartilham a mesma função de compressão interna, portanto rodam na mesma velocidade. SHA-256 é mais lento em sistemas de 64 bits porque seu tamanho de palavra de 32 bits significa mais iterações para processar cada bloco de mensagem de 512 bits. Em hardware de 32 bits ou em hardware com restrições de recursos, SHA-256 é mais rápido.

SHA-512 é bem adequado para:

Integridade arquivística: Checksums destinados a durar décadas se beneficiam da maior margem de saída.
Criptografia de disco completo: O Linux LUKS usa SHA-512 como o hash PBKDF de derivação de chave padrão (como componente do PBKDF2, não como hash standalone).
HMAC-SHA-512: Usado em alguns esquemas de assinatura JWT (HS512) e autenticação de API onde MACs maiores são preferidos.
Geração de grandes quantidades de dados pseudoaleatórios: Aplicações que fazem hash de uma semente e precisam de muitos bits de saída podem usar SHA-512 para reduzir o número de chamadas de hash.

Gere um hash SHA-512 no seu navegador: Gerador de SHA-512.

SHA-3: Uma Filosofia de Design Diferente

SHA-3 não é SHA-2 com uma saída maior. É um algoritmo fundamentalmente diferente baseado em uma construção de esponja chamada Keccak, projetado por Guido Bertoni, Joan Daemen, Michaël Peeters e Gilles Van Assche. O NIST o selecionou como vencedor de uma competição pública de sete anos (2007–2012) destinada a produzir uma família de hash que pudesse servir de backup caso fraquezas fossem encontradas na construção de Merkle-Damgard do SHA-2.

A construção de esponja funciona de forma diferente do Merkle-Damgard:

A entrada é preenchida (padded) e dividida em blocos.
Cada bloco é XOReado na primeira parte de um grande estado interno (a “taxa”), e depois o estado inteiro é permutado com a permutação Keccak-f.
Após absorver toda a entrada, a saída é “espremida” da porção de taxa do estado.

Como a saída é extraída de apenas uma parte do estado e a porção de capacidade nunca é exposta diretamente, as construções de esponja são inerentemente imunes a ataques de extensão de comprimento sem necessidade de truncamento.

Variantes padrão do SHA-3 (FIPS 202):

Variante	Bits de Saída	Nível de Segurança
SHA3-224	224	112 bits
SHA3-256	256	128 bits
SHA3-384	384	192 bits
SHA3-512	512	256 bits
SHAKE128	variável	128 bits
SHAKE256	variável	256 bits

SHA-3 vs SHA-2 na prática:

SHA-3 ainda não está amplamente implantado em protocolos projetados antes de 2015 — TLS, JWT e a maior parte da infraestrutura da internet ainda usam SHA-2. SHA-3 está aparecendo em esquemas de assinatura pós-quânticos (CRYSTALS-Dilithium, SPHINCS+ usam SHA-3 internamente), novos designs de protocolo que querem um backup de linhagem diferente, e hardware onde a permutação Keccak acelera bem. Em software puro, SHA-3 é cerca de 40% mais lento que SHA-256 em x86.

Gere um hash SHA-3 no seu navegador: Gerador de SHA-3.

A Distinção do Keccak-256 no Ethereum

Um ponto crítico a observar: o Ethereum não usa o NIST SHA-3. O Ethereum foi projetado enquanto a competição Keccak ainda estava em andamento e antes do NIST finalizar o FIPS 202. A Máquina Virtual Ethereum usa a submissão original Keccak-256, que usa preenchimento diferente do padrão NIST SHA-3 finalizado.

Especificamente:

NIST SHA3-256 acrescenta preenchimento 0x06 antes do bloco final.
Keccak-256 original (como usado pelo Ethereum) acrescenta preenchimento 0x01.

A mesma entrada produz hashes diferentes. Chamar NIST SHA3-256 e chamar keccak256 do Ethereum não são intercambiáveis. A maioria das linguagens tem ambos: em Python, hashlib.sha3_256() é NIST SHA-3; para Keccak-256 como o Ethereum usa, você precisa de uma biblioteca como pysha3 (que implementa keccak_256). Em JavaScript, a biblioteca js-sha3 expõe ambos. O Gerador de SHA-3 implementa NIST SHA3-256 — se você precisar de hashes Keccak-256 do Ethereum, use uma ferramenta específica para Ethereum.

Benchmarks de Desempenho

Os números abaixo são indicativos para a Web Crypto API do navegador em um laptop x86-64 moderno. O throughput real varia com o hardware, o tamanho da mensagem e se a plataforma usa um caminho de aceleração por hardware.

Algoritmo	Throughput em streaming (64 bits)
SHA-1	~600 MB/s
SHA-256	~500 MB/s
SHA-384	~700 MB/s
SHA-512	~700 MB/s
SHA-3-256	~300 MB/s

Para mensagens pequenas (tokens de API, checksums de poucos KB), todos os algoritmos completam em menos de 2 µs — a diferença é imperceptível. Para dados grandes (tarballs, imagens de disco), SHA-384/512 superam SHA-256 em sistemas de 64 bits porque operam em palavras de 64 bits. SHA-3 é mais lento em software puro; prefira SHA-2 em código crítico de throughput a menos que a aceleração por hardware de Keccak esteja disponível. O throughput do SHA-1 nunca é motivo para usá-lo.

Armadilhas Comuns

Incompatibilidades de codificação

SHA opera sobre bytes. Se você fizer o hash da string "hello" em um navegador onde o JavaScript a codifica como UTF-16 em vez de UTF-8, você obterá um digest diferente do de um script Python que usa str.encode("utf-8"). Sempre normalize para UTF-8 antes de fazer hash de texto.

Um padrão consistente:

const encoder = new TextEncoder(); // UTF-8
const data = encoder.encode(inputString);
const hashBuffer = await crypto.subtle.digest("SHA-256", data);

Falta de salting para MACs

Usar um hash SHA bruto como código de autenticação de mensagem (H(segredo || mensagem)) é vulnerável a ataques de extensão de comprimento em SHA-256 e SHA-512. Use HMAC (RFC 2104): HMAC-SHA256(chave, mensagem). O HMAC envolve o hash com um pad interno e externo com chave que impede ataques de extensão.

Extensão de comprimento no SHA-256

Se você estiver construindo uma assinatura de API como SHA256(segredo + payload), um atacante que conhece o hash resultante pode calcular SHA256(segredo + payload + extensão_do_atacante) sem conhecer o segredo. Solução: use HMAC, ou use SHA-3 (imune por construção), ou use SHA-384/SHA-512/256 (imune devido ao truncamento).

Confundir Keccak-256 com NIST SHA-3

Como descrito acima: o Ethereum usa Keccak-256 com preenchimento 0x01; o NIST SHA3-256 usa preenchimento 0x06. Eles produzem saídas diferentes da mesma entrada. Verifique qual variante sua biblioteca implementa antes de integrar com contratos Ethereum ou codificação Solidity ABI.

Usando SHA para senhas

Os algoritmos SHA foram projetados para ser rápidos. Essa é exatamente a propriedade errada para armazenamento de senhas: um cluster de GPU pode calcular bilhões de hashes SHA-256 por segundo, tornando um ataque de dicionário contra um banco de dados de senhas com hash SHA algo viável na prática. Para senhas, use uma função de derivação de chave com uso intensivo de memória: Argon2id (recomendado), bcrypt ou scrypt. Nunca armazene senhas como hashes SHA brutos, mesmo com salting.

Perguntas Frequentes

Qual é a diferença entre SHA-1 e SHA-256?

SHA-1 e SHA-256 são ambas funções de hash de Merkle-Damgard padronizadas no FIPS 180-4, mas SHA-256 produz um digest de 256 bits versus os 160 bits do SHA-1. Mais importante ainda, SHA-1 foi quebrado: um ataque de colisão no mundo real (SHAttered, 2017) demonstrou dois arquivos PDF distintos com o mesmo hash SHA-1. SHA-256 não tem ataques de colisão conhecidos e fornece um nível de resistência a colisões de 128 bits. Use SHA-256 para qualquer coisa que exija garantias de integridade; não use SHA-1 para trabalho novo.

SHA-512 é mais rápido que SHA-256?

Em hardware de 64 bits, sim, frequentemente em 30–40% para entradas grandes. SHA-512 usa aritmética de palavras de 64 bits, que os CPUs modernos processam nativamente. SHA-256 usa aritmética de palavras de 32 bits, exigindo o dobro de operações por bloco de mensagem no mesmo hardware. Em plataformas de 32 bits ou microcontroladores com restrições de recursos, SHA-256 é mais rápido. Para mensagens curtas (abaixo de alguns KB), a diferença é imperceptível.

Devo migrar de SHA-1 para SHA-256?

Para assinaturas digitais, certificados TLS e assinatura de código: sim, absolutamente — SHA-1 está descontinuado e ativamente quebrado. Para repositórios Git: o caminho de migração existe (git init --object-format=sha256), mas a adoção é lenta devido aos requisitos de coordenação do ecossistema; o risco de colisão para uso típico de repositório é baixo. Para impressões digitais informativas (exibição de chave de host SSH): a exposição de segurança é mínima, mas migrar para SHA-256 é uma boa prática de higiene.

SHA-256 pode ser revertido?

Não. SHA-256 é uma função unidirecional por design. Dado um hash, você não pode recuperar matematicamente a entrada original. O que os atacantes podem fazer é executar um ataque de dicionário ou força bruta: fazer hash de milhões de entradas candidatas e comparar. Para entradas de baixa entropia (strings curtas, senhas comuns, números sequenciais), tabelas rainbow pré-computadas tornam isso viável. Para entradas de alta entropia (UUIDs aleatórios, arquivos grandes), a reversão não é computacionalmente viável. É por isso que SHA sozinho é inadequado para senhas — você precisa de uma KDF lenta e com salting.

Quando devo usar SHA-3 em vez de SHA-2?

SHA-3 é apropriado quando: (a) você quer um hash de uma linhagem de design diferente como seguro contra futuras fraquezas do SHA-2; (b) seu protocolo requer imunidade a extensão de comprimento sem usar HMAC; (c) você está implementando esquemas de assinatura pós-quânticos que especificam SHA-3 internamente; ou (d) você tem aceleração por hardware para Keccak e precisa de throughput. Para a maioria dos casos de uso cotidianos (TLS, JWT, checksums), SHA-256 tem suporte de ecossistema mais amplo e é o padrão pragmático. SHA-3 não é mais seguro que SHA-2 em tamanhos de saída equivalentes — é uma aposta diferente na segurança a longo prazo.

Por que o Ethereum usa Keccak-256 em vez de NIST SHA-3?

O Ethereum foi projetado em 2013–2014, antes do NIST publicar o FIPS 202 (agosto de 2015) finalizando o padrão SHA-3. Na época, a submissão Keccak era considerada a provável vencedora, e os autores do Ethereum a usaram diretamente. Quando o NIST finalizou o padrão, eles mudaram o preenchimento de separação de domínio de 0x01 (Keccak original) para 0x06, produzindo saída diferente da mesma entrada. O Ethereum já estava implantado com o preenchimento Keccak original e não podia mudar isso. Portanto, “Ethereum keccak256” e “NIST SHA3-256” são algoritmos diferentes, apesar de compartilharem a mesma permutação Keccak-f subjacente.

Experimente as ferramentas: SHA-1 · SHA-256 · SHA-384 · SHA-512 · SHA-3 — todas rodam no seu navegador, nenhum dado sai da sua máquina.

SHA-1 vs SHA-256 vs SHA-512: guia de hash 2026