02-14-2017, 09:57 AM
(This post was last modified: 02-14-2017, 10:06 AM by maykelbembibre.)
(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.