fingerprint Verificador de Checksum de Arquivo star

Por Que os Desenvolvedores de Software Publicam Checksums

Quando você baixa uma ISO do Linux, um binário de código aberto ou um instalador assinado, a página de download geralmente lista um checksum ao lado do arquivo — uma string curta como a94a8fe5ccb19ba61c4c0873d391e987982fbbd. Essa string é o resultado de uma função hash criptográfica executada sobre cada byte do arquivo. Mude até um único bit em qualquer parte do arquivo e o hash sai completamente diferente. Os desenvolvedores publicam esse valor para que, depois de baixar o arquivo, você possa rodar a mesma função hash e comparar o seu resultado com o que foi publicado. Se as duas strings coincidirem exatamente, você pode ter confiança de que a cópia no seu disco contém precisamente os mesmos bytes que o desenvolvedor compilou e enviou — nada adicionado, nada faltando, nada alterado.

Um checksum detecta dois tipos de problema bem diferentes. O primeiro é corriqueiro: conexões de rede caem no meio da transferência, proxies truncam arquivos grandes, e discos ocasionalmente gravam setores defeituosos — qualquer um desses pode deixar você com um arquivo que parece completo (tamanho certo, abre sem erro óbvio) mas difere do original em alguns bytes corrompidos, o que muitas vezes já é suficiente para travar um instalador ou corromper dados silenciosamente depois. O segundo é adversarial: se um invasor compromete um servidor espelho (mirror) ou intercepta um download em trânsito e o substitui por um binário modificado com malware embutido, comparar o checksum com o valor publicado na página oficial e confiável é uma das poucas verificações capazes de pegar isso — um nome e um tamanho de arquivo são triviais de falsificar, mas reproduzir um hash exato exige possuir exatamente os bytes originais.

Checksums Não São Criptografia

Vale a pena ser preciso sobre o que um checksum verifica, porque a terminologia costuma gerar confusão. Hashing é uma operação de mão única, irreversível: o SHA-256 transforma um arquivo em uma string hexadecimal fixa de 64 caracteres, mas não existe operação que transforme essa string de volta no arquivo. Só isso já mostra que não é criptografia — a criptografia é projetada para ser reversível com a chave certa; o hashing é projetado para nunca ser reversível. Um checksum verifica integridade, não confidencialidade: confirma que os bytes que você tem são os bytes que foram hasheados. Qualquer pessoa com acesso ao arquivo ainda pode ler cada byte dele às claras; o hashing não faz nada para esconder o conteúdo. O que ele garante é que, se um único byte fosse alterado — de propósito ou por acidente —, o hash que você calcula deixaria de coincidir com o publicado, e você saberia imediatamente que algo é diferente.

Essa distinção também importa para a escolha do algoritmo. O SHA-1 foi formalmente quebrado para fins de segurança criptográfica em 2017, quando pesquisadores do Google e do CWI Amsterdam publicaram o ataque "SHAttered": dois arquivos PDF diferentes projetados para produzir o mesmo hash SHA-1, provando que um invasor suficientemente motivado poderia construir um arquivo malicioso com o mesmo checksum de um arquivo legítimo. Esse resultado aposentou o SHA-1 para qualquer coisa crítica para a segurança — certificados TLS, assinaturas digitais, defesa contra um agente hostil construindo deliberadamente uma colisão. Mas para o caso muito mais comum que esta ferramenta resolve — confirmar que um download não foi corrompido por uma conexão instável — o SHA-1 ainda funciona bem na prática, porque ninguém está projetando o seu download corrompido específico para coincidir com um hash-alvo; a corrupção acidental é a alteração aleatória de bits, não a construção intencional de uma colisão. Dito isso, quando um desenvolvedor oferece a opção, o SHA-256 não custa nada a mais para calcular e fecha essa brecha por completo, o que o torna a escolha padrão mais segura.