Cracking SHA1(linkedin)
#11
Yes the odds of that happening are 1 in (2^(160-20 bits)) = 1/2^140 ~ 1 in 1.39e42

Yet it seems someone may have discovered such a collision:


source: https://www.win.tue.nl/~aeb/linux/john/john.html
"LinkedIn hashes:
After the release of 6.5 million LinkedIn hashes, a patch JtR-Jumbo-5-LinkedIn-SHA1.diff for john was published that handles the raw-sha1_li format of SHA1 with the first twenty bits zeroed. Be careful:

% echo -n sunshine09 | shasum
3b1787e7bd710592ee36264a72d6aa35c2d165f9 -
% grep `echo -n sunshine09 | shasum | cut -c6-40` combo_not.txt
a96807e7bd710592ee36264a72d6aa35c2d165f9
000007e7bd710592ee36264a72d6aa35c2d165f9

Here ‘sunshine09’ is a password that fits the second, but not the first hash. (If the first hash is an actual password hash, this is a very remarkable coincidence: a 140-bit SHA1 near-collision.) By mistake the formats raw-sha1 and raw-sha1_li are both labeled dynamic_26."
Reply
#12
Actually the situation is a bit worse. hashcat only checks the last 16 bytes of the sha1 hash

$ echo -n 'testing123' | sha1sum
4c0d2b951ffabd6f9a10489dc40fc356ec1d26d5 *-

$ hashcat -m 100 -a3 --outfile-autohex-disable --potfile-disable 000000001ffabd6f9a10489dc40fc356ec1d26d5 testing123
000000001ffabd6f9a10489dc40fc356ec1d26d5:testing123
Reply