Scrypt Example Hash Composition

[norfSprite]

I do not understand the example SCRYPT Hash composition. I am trying to recreate the example hash to understand, from what I can infer the hash appears to be composed as follows..

   SCRYPT:N:r:p:b64encoded(salt):b64(hash)

I think my confusion is caused by the last two segments in which a hash of length 64 appears to be separated into a segment of length 20 and a segment of length 44 with each being base64 encoded.

I am generating my own hashes like this..
   Python SCRYPT Library -- https://pypi.python.org/pypi/scrypt/
   scrypt.hash(password.encode('utf-8'), str(salt), N=1024, r=1, p=1, buflen=64).encode('hex')
 
   Is the process to create the hash generate 32 bit hash from salt concatenated with password. then base64 encoded and append the salt, and resulting hash as the last two segments?


I cracked the example hash and spit it out in the form..

   hash:[salt:]:plain:hex_plain

it is still unclear to me how the last two segments of the example hash are generated and what their semantic meaning is.

If there is documentation about how the example hash is created I would be happy to look that over, my search_fu was not able to find anything. I am looking at https://tools.ietf.org/html/draft-josefs...ypt-kdf-05 but have not found the answers yet.

cheers.

[norfSprite]

So I think I demonstrate my understanding of the composition of the last two segments below, but I am still stuck attempting to recreate the example hash.

Salt length (20 bytes, b64encoded format) --> ((20 / 4) * 3) - 2 = 13 byte long salt in binary format.
(-2 for the padding bytes '=')
Key length (44 bytes, b64 encoded format) --> ((44/4) * 3) - 1 = 32 byte long key in binary format.
(again -1 for the padding byte '=')

After cracking it in various formats I haven't been able to deduce what the salt is... is it possible that the salt was generated from /dev/urandom and lucky enough to get all non-printable ASCII chars?

I have tried various Outfile formats:
?Is it acceptable to display the results of example Hashes?
   1 = hash[:salt]

   3 = hash[:salt]:plain

   6 = plain:hex_plain

   9 = hash[:salt]:crackpos

Reference Resources:
https://blogs.oracle.com/rammenon/entry/..._explained
http://stackoverflow.com/questions/13378...alculation

[atom]

I don't understand anything from this. I think you need to entirely rephrase.

[norfSprite]

I don't understand anything from this. I think you need to entirely rephrase.

Goal: Be able to recreate the example SCRYPT hash.

I will list the steps/knowledge I assume are needed to be able to recreate the example SCRYPT hash. After which I will go on to explain my current mindset/approach in hope that it will help users be able to see what I am doing wrong/ or what I am missing. After these two sections I will go on to ask questions which I hope can be answered.

1.
     -To recreate the example SCRYPT hash I need to know the password and salt that are used.
     -I also need to know the work parameters that were used during generation.
  
2.
     -The work parameters are stored in the hash, they are (N=1024, p=1, r=1)
     -Cracking the hash spits out the password.
     -Cracking the hash with --outfile-format=i for i in (1,3,6,9) does not display the salt.

3.
     -The example hash uses a salt correct?
     -Why can't/don't I see the salt in any of the various outfile-formats used?
     -What programming language and library was used to generate the example SCRYPT hash?

[philsmd]

The hash type -m 8900 = scrypt uses a so-called embedded salt (this is at least hashcat's terminology). It means that the salt is part of the string you give hashcat to crack (the "hash") and there are many more hash types that use similar strings.
What this means is, that the salt in most cases can't be separated from the hash, this is especially the case if an algorithm produces some output that "embeds" the (mostly random) bytes to other parameters and the final digest/hash itself. Since it makes no sense to split such string into hash : salt, because often it can't even be done easily (think about something like base64 ($salt.$digest) where you can't just split the salt and digest without base64 decoding the whole line first).

Whenever hashcat deals with embedded salts, it won't use something like hash : salt and therefore the --outfile-formats which normally can e.g. skip/omit the salt won't do anything (applying these outfile formats to hashes with embedded salt output the whole "hash" with the embedded salt included).

Yes, the scrypt format uses a similar concept, the format incorporates the salt already, along with the Nrp parameters. the format is SCRYPT:N:r:p:base64(salt):base64(digest) . Well, this format is no invention by hashcat devs but this is kind of a defacto-standard to output scrypt hashes used in PHP, perl etc... furthermore also other crackers use this format.

most example hashes are generated by test.pl (see https://github.com/hashcat/hashcat/blob/...5491-L5505 for scrypt)

btw: the salt for the example hash is 0203305404425 and MDIwMzMwNTQwNDQyNQ== base64-encoded, all passwords for the example hashes are "hashcat" (except otherwise noted)

[kiara]

The hash type -m 8900 = scrypt uses a so-called embedded salt (this is at least hashcat's terminology). It means that the salt is part of the string you give hashcat to crack (the "hash") and there are many more hash types that use similar strings.
What this means is, that the salt in most cases can't be separated from the hash, this is especially the case if an algorithm produces some output that "embeds" the (mostly random) bytes to other parameters and the final digest/hash itself. Since it makes no sense to split such string into hash : salt, because often it can't even be done easily (think about something like base64 ($salt.$digest) where you can't just split the salt and digest without base64 decoding the whole line first).

Whenever hashcat deals with embedded salts, it won't use something like hash : salt and therefore the --outfile-formats which normally can e.g. skip/omit the salt won't do anything (applying these outfile formats to hashes with embedded salt output the whole "hash" with the embedded salt included).

Yes, the scrypt format uses a similar concept, the format incorporates the salt already, along with the Nrp parameters. the format is SCRYPT:N:r:p:base64(salt):base64(digest) . Well, this format is no invention by hashcat devs but this is kind of a defacto-standard to output scrypt hashes used in PHP, perl etc... furthermore also other crackers use this format.

most example hashes are generated by test.pl (see https://github.com/hashcat/hashcat/blob/...5491-L5505 for scrypt)

btw: the salt for the example hash is 0203305404425 and MDIwMzMwNTQwNDQyNQ== base64-encoded, all passwords for the example hashes are "hashcat" (except otherwise noted)

i have seen u took the Scrypt example  which MDIwMzMwNTQwNDQyNQ== is equal to 0203305404425 in base64 but when decoding the "hash"/"digest" with base64 the result is way different.

how can we encode the second part of the "hash" like the example?
thanks




UPDATE:

answer was given in private , so here it is

the second part of the has was encode with "echo HASH... xxd -p -r | base64"