[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.
