Why doesn't the restore point update with BCrypt hashes?
#5
(02-13-2017, 11:53 PM)atom Wrote: That's because you did check only 348 words yet (28780880 / 82563). You threads alone do 256, not even counted the shader or the -n multiplicator. For sure you didn't reach a checkpoint for restore. Problem is not hashcat here, problem is cracking 82563 at once is braindead

Thank you, I have noticed that only when current candidates change in the Hashcat output, a restore point is created. The problem with me was that the algorithm was so slow that I had never watched the candidates change even waiting for four days.

Even with only one Bcrypt hash I checked that Hashcat takes too much time to create the first restore point. The reason for that is that the algorithm is too slow. Instead of that I would suggest that Hashcat created restore points more frequently when the algorithm is slower, so that we could stop a task without losing all the done work. With MD5 for example Hashcat creates too many restore points in my computer, almost every second I could say. But with BCrypt it takes four hours to create the first restore point. I think that those times should be more homogeneus bearing in mind the algorithm speed.


Messages In This Thread
RE: Why doesn't the restore point update with BCrypt hashes? - by maykelbembibre - 02-14-2017, 09:57 AM