Which Feature / Algo to add next to oclHashcat?
| Poll: Which Feature / Algo to add next to oclHashcat? You do not have permission to vote in this poll. |
|||
| Feature: password length range support | 6 | 16.22% | |
| Feature: delete a hash from the hashlist once it is cracked | 9 | 24.32% | |
| Feature: make -l more precise | 1 | 2.70% | |
| Feature: define a fixed salt length | 2 | 5.41% | |
| Feature: increase password length limitation | 1 | 2.70% | |
| Algo: DES | 6 | 16.22% | |
| Algo: MD5(Wordpress) / MD5(phpBB3) | 4 | 10.81% | |
| Algo: SHA-256 | 5 | 13.51% | |
| Algo: md5(md5($salt).md5($pass)) | 2 | 5.41% | |
| Algo: Whirlpool | 1 | 2.70% | |
| Total | 37 vote(s) | 100% | |
| * You voted for this item. | [Show Results] |
|
Which Feature / Algo to add next to oclHashcat?
|
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
06-18-2010, 11:50 AM
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
06-23-2010, 10:09 AM
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).
06-24-2010, 12:09 PM
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.
06-25-2010, 04:35 AM
will there be any chance of a single wordlist use + rules on the single word list?
or is this already implemented?
07-03-2010, 06:50 PM
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  -- atom
07-07-2010, 03:37 PM
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. |
|
« Next Oldest | Next Newest »
|
