Garantia git com checksums

Estratégia para a garantia de autenticidade através do git e de checksums dos bitcoins, para uma perspectiva de 20 anos.

A seguir as explicações e justificativas para o algoritmo sha3-base58.pl na complementação do SHA1 encadeado do git.

---

Todo repositório git padrão já vem munido de checksum SHA1, o que garante a integridade física dos arquivos durante as operações cotidianas e, em parte, a sua autenticidade com relação à fonte original.
PS: importante lembrar que está previsto, para um futuro não muito distante, a atualização do git substituindo SHA1 por outra hash.

Essa mesma garantia pode ser ampliada se acrescentamos mais uma hash. Alguns protocolos concatenam duas hashes outros registram elas em separado. O importante é que a teoria diz que os fatores de proteção das duas hashes serão multiplicados, resultando em um fator muito maior do que qualquer das hashes sozinha.
E é importante que o fator seja grande, o suficiente para assegurar por no mínimo uma década a autenticidade do que foi "assinado" pelas hashes — como ao longo dos anos o poder computacional e o conhecimento dos hackers aumenta, o risco de se quebrar a criptografia de uma hash vai aumentando, e o fator de segurança da hash decrescendo.

---

Quanto a uma garantia maior na autenticidade e algum reforço na preservação de longo prazo, conforme crypto.stackexchange/44277 o ideal é utilizar uma segunda hash baseada em algoritmo diferente, assegurando as duas coisas:

• Somado ao SHA1, garante vida longa ao checksum, pois o ataque precisa satisfazer simultaneamente a dois hashes;
• Ser um algoritmo atualmente (2017) imune a ataques (ex. SHA2 ou SHA3);
• Ser um hash baseado em algortimo bem diferente (ex. SHA3).

O algoritmo SHA3 pode ser testado com a string vazia e outros testes simples para garantir que não haja confusão com o algoritmo Keccak-256: o UBUNTU sha3sum é de fato o SHA3 do padrão FIPS 202 de 2015, ver teste online. Pode-se usar os dois:

• RHash v1.3.3: rhash --output=sha3-256sum.txt --sha3-256 *.mkv
• Digest::SHA3 v0.24: sha3sum -a 256 *.mkv > sha3-256sum.txt

Exemplo completo: sha3sum -a 256 * | grep -v sha3-256sum.txt > sha3-256sum.txt. Para simplificar o comando e evitar que repita o cálculo sobre os arquivos já registrados foi implementado um script Perl. Aproveitou-se o mesmo script para compactar a string usando uma representação de base superior a 16. Optou-se por base-58 ao invés da base-64. Ver justificativa de uso da base58-alfabeto-bitcoin.

Ver implementação e usar executável de sha3-base58.pl.

Notas e referências

• A certificação SHA1 dos arquivos git não é exatamente a mesma que a oferecida pelo comando sha1sum, mas pode ser obtida uma certificação de igual valor com git hash-object $file ou git ls-files -s *.
  Essa diferença se deve ao fato de o sistema git usar o SHA1 do conteúdo do arquivo concatenado ao seu tamanho.[ref]

• Existem fortes justificativas para o uso do SHA3 neste contexto de complementariedade, tanto ao SHA1 como ao SHA2:

One of the reasons why SHA-3 was chosen to be what it was is that it uses rather different techniques (a sponge construction, whereas MD5, SHA-1 and SHA-2 all used a Merkle-Damgård construction), so it's very unlikely that both will be broken at the same time
Gilles (2017)

Keccak uses the sponge function for creating the cryptographic hash, which truly sets it apart from SHA1 and SHA2. This means any successful attack against SHA1 or SHA2 will likely be ineffective on SHA3.
Aaron (2014)

---

Quanto à reprodutibilidade do SHA1 apresentado pelo git, temos a equivalência
  echo -e 'blob 16\0Hello, \r\nWorld!' | shasum
  == echo -e 'Hello, \r\nWorld!' | git hash-object --stdin --no-filters
e será ainda equivalente com \n e 15.

PS: ver também comentários finais de Linus.

---

Quanto à escolha "SHA2 ou SHA3", além do fato de que SHA3 é um complementar de SHA1 (enquanto SHA2 é um similar), a equipe do Keccak lembra do argumento de que todo o processo de construção e validação do SHA3 foi e continua sendo aberto, https://keccak.team/2017/open_source_crypto.html