hashcat Forum

Full Version: Which Feature / Algo to add next to oclHashcat?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Hey oclHashcat-Users,

i fixed all known Bugs and implemented all points from docs/todo.txt in v0.20.

Please vote for the next Feature or Algo that should be added to oclHashcat.

--
atom
my plan is to add all features (if it is possible). the poll is used to build a priority list. i will start implementing the most voted feature and when it is finished i will directly release new version. depending on the feature this can go very quick or not. after that i will start new poll with all the leftovers (and new requests) ... loop
another info: this poll will timeout on 07-02-2010 (server time). i will then start implementing most voted feature and start a new poll excluding most voted feature (see description above).
All algos that are designed to deliberately waste CPU cycles in order to mitigate the possibility of a potential attack (such as PHPbb3@ over 8000 rounds), should be added first.
Algo: Whirlpool - very nice! I shall wait
will there be any chance of a single wordlist use + rules on the single word list?
or is this already implemented?
no, use hashcat for single wordlists + rules
poll should end tomorrow
all right we have a winner. i will add the feature "delete a hash from the hashlist once it is cracked". if i have some time left maybe "password length range support" as well. otherwise it will show up again in the next poll.

i recognized the votes on DES. anyway, i will remove DES(Unix) from the next oclHashcat poll. but i will add it to hashcat cpu. reason for that is my tests with bitsliced DES was nearly equal in speed on GPU and on CPU (i did not spend much time on optimizing). even it is still a common used hash in htaccess i think its popularity will drop in the future. it is already replaced in most linux distributions by md5(unix) or sha512. i think its better to spend time into these newer and stronger hashes. however, oclHashcat features have priority over this.

thanks for voting on the poll. it clearly shows a direction. dont forget to vote on next poll, too Smile

--
atom
I would propose the implementation of the UX DES and LMNT as a end solution for these algorithms. UX DES is normally limited to a length of 8 characters LMNT turn seven characters (You can then delete the few giga rainbow tables for lm-charset cp437-FRT-850).

As for me personally for a maximum password recovery realized UX MD5, BF UX and standard ZIP (not AES). Anything would be happy with that.
Pages: 1 2