Support recovery of passwords of length 16 and above

[Incisive]

Thank you for looking into this, Atom. The speed drop is pretty significant, but the larger host memory requirement is just a budget issue for those that need to do that level of auditing.

Would it be reasonable to keep the current 16 character maximum, low memory, high speed implementation, and then add support for either one or both of the other two options with a new series of hash types, so that the user can run at the highest speed/lowest memory requirements they need for the length set they're working on at the time?

[atom]

In theory yes, but then we would require special Kernels for each Hash-lenght (in steps of 4). If you take a look at the kernels directory, it would cause the program to explode. I'm afraid we have to find a different solution.

[Hash-IT]

Oh dear,

Reading this thread has me worried. The password length increase feature has been something I have been looking forward to for quite some time. The results of the recent polls gave me some hope as it seemed a very popular idea.

However, after reading the technical difficulties atom mentioned I wonder if it is simply impossible to achieve ?

..... really quite depressed at the moment ....

[atom]

Only for rule-based attacks. However, would it make sens for BF? no. For Permutation? No. For Combinator and Hybrid? Maybe.

[Hash-IT]

I am really pleased you are thinking about it atom, adding a few numbers using the suffix rule to longer passwords in my list would really make a difference for me when tackling WPA.

I saw this and instantly thought "hashcat cautiously approaching the >16 character problem" !!

[Incisive]

In theory yes, but then we would require special Kernels for each Hash-lenght (in steps of 4). If you take a look at the kernels directory, it would cause the program to explode. I'm afraid we have to find a different solution.

As far as causing the program to explode, are you worried about more programming time? I don't have a good way around that, other than automated build scripts to help with the automatable part.

If you're worried about size and download bandwidth (also very reasonable), then perhaps have more than one download: Normal (<16), and Large Password. Perhaps split at least the large into ATI, NVIDIA, and both? Alternately, would it be reasonable to have "Normal", and then have add-on packages that can simply be unzipped from the base directory, to add the kernels required for that user?

I do realize it'll be a fair bit of work to set up, but if it can be automated and you go to excess, that might lead to me downloading only, say, the ATI Caicos <=32 character kernel sets. Nothing bigger, and only a limited set of kernels - no newer or older ATI kernels, no NVIDIA kernels at all.

[Hash-IT]

If you're worried about size and download bandwidth (also very reasonable), then perhaps have more than one download: Normal (<16), and Large Password. Perhaps split at least the large into ATI, NVIDIA, and both? Alternately, would it be reasonable to have "Normal", and then have add-on packages that can simply be unzipped from the base directory, to add the kernels required for that user?

I do realize it'll be a fair bit of work to set up, but if it can be automated and you go to excess, that might lead to me downloading only, say, the ATI Caicos <=32 character kernel sets. Nothing bigger, and only a limited set of kernels - no newer or older ATI kernels, no NVIDIA kernels at all.

Your ideas about reducing download size are good, but it would mean atom having to make many builds.

I suggest torrents as I am sure many hashcat users would be willing to help out with bandwidth (torrents are not illegal by the way, only copyright ones are). However I believe this would be against the hashcat license rules, which seems a shame.

All atom would have to do is PGP sign the torrent files and users would know they have the genuine article.

Another point atom once made against torrents is that he would like to know how many people are downloading his software. I wonder if this could be worked out from how many people download the torrent file from the website instead ?

I am looking forward to longer password lengths more than anyone as I mainly test WPA, but I understand there are many problems which are simply beyond my technical knowledge.

If you are desperate for a solution right now there is a commercial software that handles the full 63 character range but it is expensive and slow.

It would also feel like you were cheating on ocl-hashcat-plus !!! .. and thats what prevents me from using it ! Ha ha !! After a while you get quite attached to ocl-hashcat-plus as you watch it grow and develop. Being part of it by making feature requests, writing wiki pages and being able to talk to the creator I have got quite attached to it !

[Incisive]

Your ideas about reducing download size are good, but it would mean atom having to make many builds.

Agreed; that's why I suggested automated build scripts. Those, admittedly, take effort and work to set up, maintain, and test, but they do make the various builds much easier to create each time.

Regrettably, adding things means adding things!

[atom]

However I believe this would be against the hashcat license rules, which seems a shame.

Another point atom once made against torrents is that he would like to know how many people are downloading his software. I wonder if this could be worked out from how many people download the torrent file from the website instead ?

This restriction has been removed with the latest EULA updates. You are free to mirror the binaries.

[atom]

Agreed; that's why I suggested automated build scripts. Those, admittedly, take effort and work to set up, maintain, and test, but they do make the various builds much easier to create each time.

Regrettably, adding things means adding things!

I would prefer a different solution, sorry.