Is this a bug?

[Rannek]

So i started algo veracrypt SHA 512 and 256 on two different cloud servers. XTS 1536

I had a list of passwords, some of which exceeded the maximum password length of 128 characters. I assumed Hashcat would handle these longer passwords correctly.

However, I noticed that even with the same password list, it seemed to be incorrectly processing the longer passwords. Additionally, despite having the same hash rate, one process writes 6 minutes while the other writes 21 minutes. Both processes were running on RTX 4090 graphics cards and had identical settings.

Can anyone help me understand why these issues are occurring?

In addition, I noticed that even though both encryption algorithms have the same maximum password length of 128 characters, the processes didn't start at the same completion percentage.






  01.png (Size: 45.63 KB / Downloads: 68)
  02.png (Size: 50.09 KB / Downloads: 66)

[Rannek]

Now both Streebog and Whirlpool starts from 16.91% which is weird. I also made a line counter, so all four algo should start at 78.47%

[Snoopy]

well im not quite sure about this, but do you strip the line-endings before getting the lenght of your lines?

regarding your 2 screeenshots from above (first 2 screens), hashcat rejects both times 311.088 from your passlist, which is quite "near" your count of 317.904, the mismatch of ~6.900 could just be the number of passes which are in fact 128 chars long but you count them as >128 because of the line ending which counts

hashcat uses bulks the feed gpu, first bulk was completly rejected, just wait und you should see, that this will rise to the 311.088 from above

regarding string lenght see this (line ending counts ^^)

[Rannek]

well im not quite sure about this, but do you strip the line-endings before getting the lenght of your lines?

regarding your 2 screeenshots from above (first 2 screens), hashcat rejects both times 311.088 from your passlist, which is quite "near" your count of 317.904, the mismatch of ~6.900 could just be the number of passes which are in fact 128 chars long but you count them as >128 because of the line ending which counts

hashcat uses bulks the feed gpu, first bulk was completly rejected, just wait und you should see, that this will rise to the 311.088 from above

regarding string lenght see this (line ending counts ^^)

OMG you are so right. I am so stupid. You are correct, the newline characters \n
at the end of each line were being counted, which could potentially distort the length of the line. Now these are the results.
Thanks for the comment so hashcat is working fine. I just don't really understood how it works



  newline.png (Size: 19.84 KB / Downloads: 28)

[Snoopy]

you are welcome

there are many more tripwires, like UTF-8 <->ISO-8859-15 misconversion and so on

jfyi: another common mistake for bruteforce and masks with non asciii chars

when trying to crack non ascii chars like german umlauts äöü e.g. ö is HEX C3 B4, as hashcat works on bytesyized objects, to crack this "single" char, the mask for bruteforce has to be of length 2.

so for cracking "öl" the mask has to be of lenght 3. 2 for ö and 1 for standard ascii l which is one byte in size

[Rannek]

you are welcome

there are many more tripwires, like UTF-8 <->ISO-8859-15 misconversion and so on

jfyi: another common mistake for bruteforce and masks with non asciii chars

when trying to crack non ascii chars like german umlauts äöü e.g. ö is HEX C3 B4, as hashcat works on bytesyized objects, to crack this "single" char, the mask for bruteforce has to be of length 2.

so for cracking "öl" the mask has to be of lenght 3. 2 for ö and 1 for standard ascii l which is one byte in size

Thanks for those awesome tips! I didn't know those facts before.