O que foi o ataque SHAttered de 2017 contra SHA-1?

Foi a primeira demonstração prática de colisão contra SHA-1, publicada por pesquisadores do Google e da CWI Amsterdam — dois arquivos PDF diferentes construídos deliberadamente para produzir exatamente o mesmo hash SHA-1, confirmando formalmente a vulnerabilidade que estudos teóricos já apontavam.

Por que o Git ainda usa SHA-1 se o algoritmo está tecnicamente quebrado?

Porque o ataque de colisão exige construir deliberadamente arquivos binários especialmente manipulados — um cenário muito diferente de adulterar silenciosamente um commit real num repositório existente, onde a estrutura do conteúdo torna esse ataque impraticável. O Git também vem migrando gradualmente para SHA-256 como opção, mas é um processo lento pela escala do ecossistema de ferramentas construído ao redor do formato atual.

SHA-1 é seguro para verificar a integridade de um certificado digital?

Não. Certificados digitais e assinaturas criptográficas são exatamente o tipo de cenário adversarial onde a vulnerabilidade de colisão do SHA-1 importa diretamente — navegadores modernos já rejeitam certificados assinados com SHA-1 por esse motivo. SHA-256 ou algoritmos mais recentes são a escolha correta nesse contexto.

Codificar SHA1

Gere o hash SHA-1 de um texto. Hash é uma via só — não existe "decodificar" um SHA1.

Texto de entrada

Hash calculado no servidor com a função nativa do PHP. SHA-1 é considerado fraco para uso criptográfico sensível — prefira SHA-256 ou superior para novas aplicações.

Documentação técnica

SHA-1: 160 bits, e por que o Git ainda usa um algoritmo tecnicamente quebrado

SHA-1 produz um hash de 160 bits (40 caracteres hexadecimais), maior que os 128 bits do MD5, mas seguindo a mesma trajetória histórica: considerado seguro por décadas, até que em 2017 pesquisadores do Google e da CWI Amsterdam publicaram o ataque SHAttered — a primeira colisão de SHA-1 demonstrada na prática, produzindo dois arquivos PDF diferentes com o mesmo hash SHA-1. Isso confirmou formalmente o que já era teoricamente esperado desde estudos criptográficos anteriores: SHA-1 não deve mais ser usado onde resistência a colisão é criticamente necessária — certificados digitais, assinaturas criptográficas, verificação de integridade contra adulteração deliberada.

O paradoxo do Git: onde SHA-1 ainda está em produção massiva

O Git usa SHA-1 para identificar cada commit, árvore de arquivos e blob de conteúdo desde sua criação em 2005 — e continua usando até hoje na maioria dos repositórios, incluindo praticamente todo código aberto hospedado no GitHub. Isso não é uma contradição ingênua: o ataque SHAttered exige construir deliberadamente dois arquivos binários especialmente manipulados para colidir — um cenário muito diferente de alguém adulterar silenciosamente um commit já existente num repositório real, onde o conteúdo tem estrutura e contexto que tornam esse tipo de ataque impraticável. O Git também vem migrando gradualmente para SHA-256 como opção, mas a migração de um ecossistema inteiro de ferramentas construídas ao redor de hashes de 40 caracteres é um processo lento e ainda em andamento.

A mesma ressalva do MD5, com um algoritmo mais forte

Como no MD5, a vulnerabilidade de colisão do SHA-1 só importa diretamente em cenários com adversário ativo. Para identificação de conteúdo sem ameaça de adulteração deliberada (o caso de uso do Git, ou de deduplicação de dados), SHA-1 continua funcionalmente adequado. Para qualquer necessidade de segurança criptográfica real — assinatura digital, certificado, verificação de integridade num contexto adversarial — a recomendação atual (NIST incluído) é migrar para SHA-256 ou algoritmos mais recentes da família SHA-3.