Limitations of hashcat approach for certain targets

[john_alan]

This is more of a general question around hashcat/JTR style approaches to cracking.


I understand and it's clear how hashcat approaches brute force mask attacks for a multitude of hash types.

However, I understand, in all applied circumstances, one needs a target hash to work towards.
Whether that's from an encrypted word-doc or indeed a bitcoin wallet.dat.

I'm wondering about the limitations of this, is it always possible to obtain such a target hash?
For example I noticed a user trying to attack Scrypt, I can't see how all implementations of symmetric cryptography that use Scrypt for KDF would also "leak" a hash.


As an example, taking a small tool I wrote using libsodium that users ChaCha20-poly1305 to encrypt data with a symmetric key.
 
A user chosen password is passed through Argon2, thus a key is derived using the Argon2 KDF (a slow HBKDF like Scrypt).

After encryption is complete only the payload of the blob stored on disk looks like this:

[saltForArgon2+nonceAndEncryptedCipherText]

In an example like this, how would one begin to extract a target hash for hashcat? I don't see it as possible.

So, in the case of bitcoin and scrypt support, is the ability to get a target hash from the data implementation specific? or for these examples, does hashcat actually derive a key and try to decrypt AES and check for an output template or something?

Thanks

[Chick3nman]

You don't. You don't get a hash.

If your algorithm involves a KDF, we just do the KDF step the same way you would, then do the decryption step on the encrypted cipher text and check if what we got is what we wanted/expected.

[john_alan]

You don't. You don't get a hash.

If your algorithm involves a KDF, we just do the KDF step the same way you would, then do the decryption step on the encrypted cipher text and check if what we got is what we wanted/expected.

Makes sense thanks!