Salts in Bitcoin wallet.dat hashes

[MA40]

Hello.

In my hashes file, I have several of the type Bitcoin “wallet.dat”.

HashCat says that some hashes have salts and some do not.

Do Bitcoin “wallet.dat” password hashes really have salts?

A greeting.

[MA40]

Nobody can help me?

A greeting.

[Mem5]

Post your output, don't forget to blur hashes.

[MA40]

Thanks.

[undeath]

Please don't post screenshots of text. Just copy the text.

On those screenshots I can not see any hashcat output complaining about not having salts.

[MA40]

Sorry.

$ ./restore.sh
hashcat (v6.1.1) starting in restore mode...

Kernel /opt/HashCat/OpenCL/m11300-optimized.cl:
Optimized kernel requested but not needed - falling back to pure kernel

OpenCL API (OpenCL 2.1 LINUX) - Platform #1 [Intel(R) Corporation]
==================================================================
* Device #1: Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz, 60228/60292 MB (15073 MB allocatable), 10MCU

Kernel /opt/HashCat/OpenCL/m11300-optimized.cl:
Optimized kernel requested but not needed - falling back to pure kernel

Minimum password length supported by kernel: 0
Maximum password length supported by kernel: 256

Hashes: 52 digests; 50 unique digests, 49 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Rules: 1

Applicable optimizers applied:
* Zero-Byte
* Slow-Hash-SIMD-LOOP
* Uses-64-Bit

Watchdog: Hardware monitoring interface not found on your system.
Watchdog: Temperature abort trigger disabled.

Host memory required for this attack: 66 MB

Dictionary cache hit:
* Filename..: *******************
* Passwords.: 1973218843
* Bytes.....: 21744529702
* Keyspace..: 1973218843

[s]tatus [p]ause [b]ypass [c]heckpoint [q]uit => s

Session..........: hashcat
Status...........: Running
Hash.Name........: Bitcoin/Litecoin wallet.dat
Hash.Target......: bitcoin.hashes
Time.Started.....: Fri Nov 20 20:46:52 2020 (11 secs)
Time.Estimated...: Fri Nov 22 21:51:57 2030 (10 years, 2 days)
Guess.Base.......: File (*******************)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:      306 H/s (237.69ms) @ Accel:1024 Loops:256 Thr:1 Vec:4
Recovered........: 0/50 (0.00%) Digests, 0/49 (0.00%) Salts
Progress.........: 52057600/96687723307 (0.05%)
Rejected.........: 0/52057600 (0.00%)
Restore.Point....: 1062400/1973218843 (0.05%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:10752-11008
Candidates.#1....: unarchiving -> sighandler

[s]tatus [p]ause [b]ypass [c]heckpoint [q]uit =>

NOTE: Observe "50 unique digests, 49 unique salts". I mean, one hash doesn't have salt, right?
 
A greeting.

[undeath]

It could also be that one hash is included twice, hence a duplicate salt. Or, less likely, two hashes are different but have a common salt.

[MA40]

Hi.

There is something that escapes me.

If by salt we understand what is described in https://en.m.wikipedia.org/wiki/Salt_(cryptography) , I do not understand the following:

An encrypted "wallet.dat" file has the password hash and if it has salt, then the hash is the password + the salt.

But a "wallet.dat" file is a separate and transportable file. I mean that if I have Bitcoin Core installed on one computer with its “wallet.dat”, and now I copy the “wallet.dat” on another computer with Bitcoin Core, the “wallet.dat” also works on this second computer. I mean, I can transfer bitcoins only with the password. How does this second computer know which salt to add to the password to decrypt the private keys?

According to the Wikipedia article, salts are kept separate from hashes to be effective.

I explain, right?

A greeting.

[Mem5]

sort -u bitcoin.hashes | wc -l
(count how many unique hashes you have in bitcoin.hashes)

[MA40]

$ sort -u bitcoin.hashes | wc -l
50
$

Hello.
 
I also don't understand how HashCat can tell if a hash has salt or not.
 
Let's take the example of the password "ABCDE12345".
 
This string of characters will produce a hash X.
 
Just by the hash it is possible to know if the password is "ABCDE" and the salt "12345" or if "ABCDE12345" is really the whole password?
 
A greeting.