Is the prefix of the Yescrypt message digest expected to be identified and correctly so?

[Ricky-Tigg]

Name-That-Hash v. 1.11.0

Hello. As I understand it, some types of hash formats are known by default because their prefixes are standardised identifiers–as specified by the Modular Crypt Format I believe–, such as "y" which identifies Yescrypt. Illustration in Linux in /etc/shadow as the result of 'sudo getent shadow $USER'.

Generating a message digest

While /etc/login.defs is with default settings,

$ echo | mkpasswd -s -m yescrypt
$y$j9T$emLpuMtd8hDttnxP6ZqUX/$vKEEhML1GIoFOrSGQPI7cF/Zso3U1cs1H/ITHD2tUt.

• resulting from the hashing function Yescrypt
• implicit random salt; designed to vary up to 512 bits
• empty password

Analyse on the nth.skerritt.blog site

There passing into the dedicated field the

• full string, results in the algorithm identifier not being detected, neither by John the Ripper (JtR) nor HashCat (HC); no suggestion of algorithms printed.

Is it expected "Yescrypt" not to be as part of the suggested possible candidate algorithms, itself as a result of an expected non detection of the identifier?

• string "emLpuMtd8hDttnxP6ZqUX/vKEEhML1GIoFOrSGQPI7cF/Zso3U1cs1H/ITHD2tUt." triggers an algorithm suggestion, solely BigCrypt, as identified by JtR, therefore erroneously so.

Is it expected Yescrypt not only not to be suggested by HC but also its prefix to be erroneously decoded by JtR?

Could the faulty analyse be related to the following considerations?

In the following sites and in regard to the cracking operation targeting Yescrypt

• HC shows no mention of it as part of natively supported algorithms.
• JtR, as I interpret it, is supported though not natively.