Frank Dittrich

Alternatively, you could implement counting from the end if the number is negative, e.g., `%-1?d` meaning the last digit. But this might be overkill, because nobody is ever going to...

I think not even truecrypt can distinguish those. It just tries the passphrase with all supported algorithms, until it finds the one that works.

Only slightly OT: Wouldn't it make sense to add a VeraCrypt format? https://www.veracrypt.fr/en/Home.html Hashcat sems to support VeraCrypt.

One way would be to have different format names which all consider the same hash as valid. Then, picking an algorithm (even cascaded) would be done by the --format switch....

The hash string doesn't have information about the encryption algorithm. Truecrypt tries each implemented algorithm (and the cascades versions) in a sequence until it finds a match.

Which systems accept arbitrary hex values as passwords, so that a password cannot be cracked without supporting `$HEX[...]`? I wouldn't want that additional complexity just to be able to "crack"...

Given that some formats "hexify" their salts when they contain certain problematic characters, this can get messy. Also, I'd like the pot file to contain the real passwords, i.e. `johnripper`,...

descrypt and dummy would also be a good choice: Both are core formats, stable, well tested. One of them is salted, the other isn't.

A seed that can be specified is needed to reliably reproduce a problem that only occurs under certain conditions. So, we need something similar to jtrts.pl's already existing `-random -seed...

In addition to the fuzzer, could we add at least one hard coded --dynamic=... test to the default test suite run?