|
Message-ID: <20220205210338.GA25516@openwall.com> Date: Sat, 5 Feb 2022 22:03:38 +0100 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: Bitcoin hash difference Hi Tony, On Fri, Feb 04, 2022 at 02:45:41AM +0000, hamano_clevage@...ail.me wrote: > When I run the bitcoin2john.py script I have stored from 2019 it > generates me an hash ending differently than when I run it using the > current version. > > 2019 bitcoin2john.py version hash: > $bitcoin$64$<_the_identical_part_>$1318$96$55b605d8050d8dc073eef17df20ef760dbe6885217e9$130$04e93d2592735ec271e0c65e0925854a710e2c648aff1d79a22fe93 > > current bitcoin2john.py version hash: > $bitcoin$64$<_the_identical_part_>$16$adfbb9cfa83e9cf6$135318$2$00$2$00 > > I would expect them to be the same. The first part is the same but after > the 4th dollar sign the outcome is very different. > > Should it be the same with the old and the new version? No, that difference is as intended in order to make these "hashes" less revealing - the latest kind of them is what we believe the minimum needed for password cracking. In fact, there was a third kind, prior to 2019, that was even more revealing than the 2019 kind. > Does this influence the result when using it in Hashcat or John the Ripper? No, they're all compatible. As you can see, the latest kind has four dummy fields in the end - those are for backwards compatibility. Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.