02-14-2021, 01:06 AM
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."
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."