@CATuGHTI
There are multiple important small changes to the scrypt-based kernel code for instance these:
- https://github.com/hashcat/hashcat/commi...5f851e9f25
- https://github.com/hashcat/hashcat/commi...5667a3ca11
- https://github.com/hashcat/hashcat/commi...4313ade8c1
etc
In theory they should make scrypt perform (much) better, especially on modern hardware etc. These are of course implementation-specific changes that are only of interst to devs and of course users that use/crack scrypt a lot, the user doesn't really need to care too much about these changes except that they should notice a speed improvement in the beta and upcoming release versions (but this of course also depends a lot on the scrypt parameters N, r, p etc and on the users hardware... for very heavy scrypt settings of course the speed improvement can't be noticed that much, because Nrp will make them kind of negligible). The improvement is still huge in general and very important.
@while1
no, you need the opposite, instead of scaling down, you need to scale up (or even better: first think A LOT about the feasibility and keyspace, number of password candidates, patterns etc etc etc). Instead of trying to use a Raspberry PI, that has (compared to a modern CPU or GPU rig, but we already stated here that for scrypt a CPU-rig might be better) almost no computing power, you need to scale up and use modern performant hardware that has a lot of computing power. hashcat doesn't support Raspberry PI for several obvious reasons (almost no computing power, no fan/cooling, not suitable for most of the advanced hard cracking jobs etc). In case of a scrypt-based algorithm you are better of with some modern Intel i9 processors or modern high-performant Intel Xeon processors (or similar). Good luck cracking.
There are multiple important small changes to the scrypt-based kernel code for instance these:
- https://github.com/hashcat/hashcat/commi...5f851e9f25
- https://github.com/hashcat/hashcat/commi...5667a3ca11
- https://github.com/hashcat/hashcat/commi...4313ade8c1
etc
In theory they should make scrypt perform (much) better, especially on modern hardware etc. These are of course implementation-specific changes that are only of interst to devs and of course users that use/crack scrypt a lot, the user doesn't really need to care too much about these changes except that they should notice a speed improvement in the beta and upcoming release versions (but this of course also depends a lot on the scrypt parameters N, r, p etc and on the users hardware... for very heavy scrypt settings of course the speed improvement can't be noticed that much, because Nrp will make them kind of negligible). The improvement is still huge in general and very important.
@while1
no, you need the opposite, instead of scaling down, you need to scale up (or even better: first think A LOT about the feasibility and keyspace, number of password candidates, patterns etc etc etc). Instead of trying to use a Raspberry PI, that has (compared to a modern CPU or GPU rig, but we already stated here that for scrypt a CPU-rig might be better) almost no computing power, you need to scale up and use modern performant hardware that has a lot of computing power. hashcat doesn't support Raspberry PI for several obvious reasons (almost no computing power, no fan/cooling, not suitable for most of the advanced hard cracking jobs etc). In case of a scrypt-based algorithm you are better of with some modern Intel i9 processors or modern high-performant Intel Xeon processors (or similar). Good luck cracking.