Support recovery of passwords of length 16 and above

[arex1337]

As I understand this Wiki section, oclHashcat is, by design, unable to recover passwords of length 16 and above.

I assume this allows for some optimizations in the hashing algorithms, which obviously is good, but ideally it would be a switch or option of some sort.

[Hash-IT]

This is mentioned occasionally and it is an old request of mine. I perhaps should add this to the wiki request page as "Pending" and await atoms reply.

However I don't think atom is keen to implement it as it will involve a lot of work, re-writing etc.

[Kgx Pnqvhm]

The way I request that is where dictionaries are supported, longer passwords should be, too.
Brute forcing beyond 15 characters isn't so productive, but working with dictionaries is.
It may be more feasible to add multiple dictionaries with per-dictionary rules to CPU hashcat, than to increase the limits of a GPU hashcat.

[arex1337]

Good points. Looking forward to hear from atom

[atom]

this have been discussed very often. i can not increase the support easily. its to much code change. well, maybe for brute-force, but on there its useless.

[forumhero]

does cpu hashcat support more than 15 char?

[atom]

yes

[Kgx Pnqvhm]

Maybe add a note in the wiki about the other hashcats that 'lite can do longer than 15 characters, though brute force only.

[thorsheim]

For most purposes, I don't see the need for expanding length support beyond 15. Especially when we have it in -lite.

If it is a major code change and/or a major hit to performance I'd rather see distributed computing and/or increment bruteforce to plus (and lite?).

[atom]

I did some tests. For example, due to its caching architecture, if we want to support 64 char passwords with oclHashcat-plus it will require 16gb host memory. Otherwise it wont start. The speed dropped from ~ 3000Mhash/s to ~ 1800Mhash/s. If we choose to support 32 char only its 8gb host memory and ~2400Mhash/s.