SHA-1 vs SHA-256: SHA-1 está morto, mas o Git ainda o usa

Resumo. SHA-1 está criptograficamente quebrado — uma colisão prática foi demonstrada pelo Google em 2017 e ataques de prefixo escolhido tornaram-se acessíveis em 2020 — portanto, use SHA-256 para toda nova aplicação de segurança. O Git ainda usa SHA-1 para hashes de objetos, mas está migrando; impressões digitais sem segurança (caches, deduplicação) não são afetadas.

SHA-1 (saída de 160 bits, 1995) e a família SHA-2 (saídas de 256/384/512 bits, 2001) são ambas funções de hash criptográfico publicadas pelo NIST. SHA-1 foi o hash de integridade dominante na década de 2000. Está agora descontinuado em todos os lugares onde a segurança importa — mas ainda não em todos os lugares.

O resumo

Como o SHA-1 foi quebrado

Uma função de hash criptográfico deve tornar computacionalmente inviável encontrar duas entradas que produzem o mesmo hash. A saída de 160 bits do SHA-1 dava resistência à colisão de 2⁸⁰ no papel — muito além dos orçamentos de força bruta no momento do design em 1995.

Três marcos corroeram isso:

1. 2005: Wang, Yin e Yu publicaram um ataque teórico reduzindo a busca de colisão para ~2⁶⁹ operações — ainda inviável na época, mas um claro sinal de alerta.
2. 2017: O projeto SHAttered do Google demonstrou a primeira colisão prática de SHA-1: dois PDFs com o mesmo hash SHA-1. Custo: ~US$110 mil em computação GPU e 9 quintilhões de avaliações SHA-1.
3. 2020: Leurent e Peyrin publicaram um ataque de colisão de prefixo escolhido — dados dois cabeçalhos de arquivo arbitrários, anexe bytes cuidadosamente elaborados e produza arquivos colidentes. Custo: ~US$45 mil em computação cloud. Este é o tipo de ataque que permite certificados forjados e assinaturas falsificadas.

Após 2020, SHA-1 é inadequado para qualquer finalidade de segurança onde a falsificação importa.

Onde SHA-1 ainda é aceitável

Impressões digitais não adversariais — onde não há incentivo de atacante para forjar colisões — ainda estão bem com SHA-1:

• Hashes de objetos commit e tree do Git. Um atacante que forja uma colisão precisaria injetar commits elaborados e tê-los aceitos em mirrors mainstream. O Git também executa detecção SHA-1 de padrões de ataque conhecidos (a detecção SHAttered) em cada operação, tornando a injeção de ataques visível.
• Armazenamento endereçável por conteúdo onde você controla todas as entradas (caches de build, deduplicação de CDN).

Mesmo nesses casos, SHA-256 é o padrão correto para novos sistemas. A diferença de desempenho (SHA-256 é ~40% mais lento que SHA-1 na maioria das CPUs modernas) é irrelevante para quase toda carga de trabalho.

Onde SHA-256 é obrigatório

• Assinaturas de certificados TLS. Navegadores pararam de aceitar SHA-1 em 2017.
• Assinaturas JWT (HS256, RS256, ES256). O 256 é SHA-256.
• Assinatura de código. Microsoft e Apple pararam de aceitar assinaturas SHA-1 por volta de 2016-2017.
• Qualquer lugar onde ataques de colisão permitiriam falsificação. Assinaturas de documentos, criptomoedas, provas de identidade.

A migração do Git

O Git tem migrado para SHA-256 desde 2018. A migração é tecnicamente direta, mas leva tempo porque cada servidor Git, cada sistema CI/CD, cada gerenciador de dependências precisa suportar ambos. Status em 2026:

• Repositórios SHA-256 funcionam de ponta a ponta no Git moderno.
• O GitHub suporta repos SHA-256, mas usa SHA-1 como padrão para novos repos.
• GitLab e Bitbucket: suporte parcial, varia por versão.
• A maioria das integrações CI funciona com ambos.

O comportamento padrão do CLI do Git ainda é SHA-1. Para criar um repositório SHA-256: git init --object-format=sha256. Quando a migração for concluída — provavelmente no período 2027-2028 — o padrão mudará.

A regra pragmática

• Para novos sistemas: SHA-256. Sempre. A diferença de desempenho não importa.
• Para sistemas SHA-1 legados: migre quando viável, mas não entre em pânico — a ameaça é real, mas específica.
• Para Git especificamente: SHA-1 está bem por agora. Fique atento ao SHA-256 se tornar o padrão.
• Para TLS, assinatura de código, JWT, cripto: SHA-256 já era a única escolha aceitável.

Calcule ambos os hashes via nosso gerador de hash.

Dados numéricos

• Comprimento hex: SHA-1 = 40 chars (160 bits); SHA-256 = 64 chars (256 bits); base64url = 27 chars vs 43 chars sem padding.
• Resistência à colisão pelo aniversário: SHA-1 ~2⁸⁰ genérico, caiu para ~2⁶¹ após o ataque SHAttered de 2017; SHA-256 permanece ~2¹²⁸.
• Custo do SHAttered (2017): 9.223.372.036.854.775.808 avaliações SHA-1, ~US$110.000 em tempo de GPU cloud, equivalente a 6.500 anos de CPU.
• Ataque de prefixo escolhido (Leurent & Peyrin, 2020): ~US$45.000 na AWS — acessível para operações criminosas de médio porte.
• Throughput no Intel SHA-NI (Ice Lake / Zen 3+): SHA-1 ~2,1 GB/s/core; SHA-256 ~1,9 GB/s/core — a aceleração por hardware reduz a diferença para ~10%, não 40%.
• Sem aceleração por hardware: SHA-1 ~700 MB/s vs SHA-256 ~400 MB/s — a diferença legada de ~40% que as pessoas citam.
• Tamanho do bloco: ambos usam blocos de 512 bits; SHA-1 produz um estado de 160 bits, SHA-256 um estado de 256 bits.
• Navegadores em 2017: Chrome 56, Firefox 51, Edge — todos pararam de aceitar certificados TLS SHA-1 em 24 de janeiro de 2017.

Matriz de decisão

Fontes

• NIST FIPS 180-4 — Secure Hash Standard — csrc.nist.gov/pubs/fips/180-4.
• Stevens, M. et al. — The first collision for full SHA-1, CRYPTO 2017 (SHAttered) — shattered.io.
• Leurent, G. & Peyrin, T. — SHA-1 is a Shambles, USENIX Security 2020 — sha-mbles.github.io.