lixos e lembretes

diff cuidando.org.br.txt  /tmp/whois/cuidando.org.br.txt | wc -l
46
diff ok.org.br.txt  /tmp/whois/ok.org.br.txt | wc -l
33
diff okfn.org.br.txt  /tmp/whois/okfn.org.br.txt | wc -l
30
diff governoaberto.org.br.txt  /tmp/whois/governoaberto.org.br.txt | wc -l
30
diff mira.org.br.txt  /tmp/whois/mira.org.br.txt | wc -l
30



diff votolegal.org.br.txt  /tmp/whois/votolegal.org.br.txt | wc -l
24
diff escolaDeDados.org.txt  /tmp/whois/escolaDeDados.org.txt | wc -l
23
diff queremossaber.org.br.txt  /tmp/whois/queremossaber.org.br.txt| wc -l
22


## Periferias do checksum

...     rhash --output=keccak256sum.txt --sha3-256 *

 *SHA-3 FIPS 202 standard*  ... `keccak256sum`? 

...Como o próprio [Linus já explicou](https://plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL), o git não corre risco algum de integridade com SHA1 (alias [este experimento](http://stackoverflow.com/a/34599081/287948) comprovou) e, como foi [explicado aqui](https://crypto.stackexchange.com/q/44277/42893), diferentes checksums se reforçam a garantia de autenticidade. 

Método das duas hashes:

1. Integridade SHA1 (futuro SHA256) no `git fsck` (comando que confirma os hashes do próprio git), com garantia parcial de autenticidade.
2. Integridade adicional e autenticidade mais robusta, SHA3-256 de cada arquivo.