SHA1 broken by US Government
...but not in the way you might expect. One of us noisers (Gerry Leach) tried to use the Argonne National Laboratory's implementation of SHA1 to double-check his own computations. What he found was a bit of a surprise, to say the least...
Given the input string 1316798755 the above site returns DA39A3EE5E6B4BD3255BFEF95601890AFD879. One wouldn't normally question this result, coming from a national laboratory, except that it didn't match Gerry's local tests, nor does it match mine:
$ echo -n 1316798755 | sha1sum | tr '[:lower:]' '[:upper:]' A897C3B9E5A64D609A1D7DB3D1D7F4C03C3F00A1 -
Bob Bell quickly pointed out the similarity of the site's computation to the SHA1 of the empty string:
$ sha1sum </dev/null | tr '[:lower:]' '[:upper:]' DA39A3EE5E6B4B0D3255BFEF95601890AFD80709 - DA39A3EE5E6B4BD3255BFEF95601890AFD879 (output from ANL)
After a few more tests, Bob enumerated the issues with the site's computation:
- First, it strips any non-alpha characters from the input, including digits and whitespace.
- Then it converts lowercase input to uppercase, so the result for "foobar" is the same as the result for "FOOBAR", but even so the final answer is wrong because...
- It prints the result as a string of bytes using %X instead of %02X, so the output drops leading zeroes in the hex representation of each byte.
I wonder what Argonne is doing with this particular calculator... Dare we hope for... nothing?