01-31-2021, 01:43 AM
The reason that specific test is failing is because the portions of the hash and salt that hashcat uses to compare are exactly the same in those hashes so they are thrown away. Changing only the last bits of the enc/mac like that wont actually change how hashcat does its calculations, so in theory all those hashes are considered the same until the last two steps where the enc is decrypted and the MAC is checked on the decrypted data. When the MAC fails on the decrypted data or the decryption fails the candidate is thrown away. This is not a bug exactly, i believe it's related to an optimization applied to almost all of our kernels/algorithms. In the case of this kernel specifically, and how incredibly slow it is already, we could possibly store/check the entire string and not lose speed but that may take a bit to do.
Further, corrupting your own hashes like that seems really odd to do on purpose. It doesn't offer you any extra security as the hash format is NOT to be used as a format for backups/security regardless. In some wallets/modes for ethereum it doesn't even store enough information to use the wallet again afterwards, it only stores enough information to find the password. You can't use the information in the hash format to rebuild the wallet fully. This is not true for presale wallets, but the other variants it can be.
Further, corrupting your own hashes like that seems really odd to do on purpose. It doesn't offer you any extra security as the hash format is NOT to be used as a format for backups/security regardless. In some wallets/modes for ethereum it doesn't even store enough information to use the wallet again afterwards, it only stores enough information to find the password. You can't use the information in the hash format to rebuild the wallet fully. This is not true for presale wallets, but the other variants it can be.