Date: Sun, 26 Jan 2014 23:32:16 +0100 From: Frank Dittrich <frank_dittrich@...mail.com> To: john-dev@...ts.openwall.com Subject: Handling of hashes with different iteration counts While some hash formats have a fix iteration count, others allow the iteration count to be configured by sysadmins. If an input file contains several hashes of the same hash algorithm, but with different iteration counts, it would be good if john would report this and allow an easy to select hashes which require CPU time to be attacked separately. For some hash algorithms, the iteration count is encoded into the hash in a human readable way (iteration count/rounds as a decimal number or as powers of 2), for other hash algorithms, this is less obvious. To improve the current situation, I think the format interface needs to be extended. Each format should define a new function: unsigned int iteration_count(char * ciphertext) (I am not sure if some formats need an additional struct fmt_main *self parameter. I am also not sure if all formats consider a variable iteration count to be part of the salt, so that we could pass the salt instead of ciphertext.) The default function fmt_default_iteration_count should always return 1 and can be used by all functions without a variable iteration count. (If some algorithms do indeed have multiple iteration counts, e.g., X iterations of md5, Y iterations of sha1, we could either extend the format interface by an array of iteration_count functions, or require the iteration count function to return an array of integers, reporting the most significant iteration count first, and the least significant iteration count last. (May be if we make the additional function(s) optional, and assume NULL otherwise, we wouldn't even need to adjust each format. Formats without a variable iteration count just use NULL as the first iteration count function, functions with 2 independent iteration counts provide 2 different functions, etc. In case we allow NULL, john should handle this as if the fmt_default_iteration_count function had been used. fmt_default_iteration_count should probably not be called for --test. In a cracking session, it should be called for all valid hashes which remain uncracked (after checking the pot file). If there is a different iteration count, john should print a warning to stderr and/or the log file, mentioning the lowest and the highest iteration count. In verbose mode, john could even list the distribution of hashes across different iteration counts. To filter hashes below or above a certain iteration count, a new command line option is requires. I wouldn't call that new option --iteration-count, because currently --incremental is the only option starting with letter i, and because --rounds is shorter (and, so far, there is no other option starting with "--ro"). --rounds should be used for --show and --show=LEFT as well. Similar to --salts, --rounds=16 should include all hashes with iteration counts >= 16, while --rounds=-16 would include iteration counts from 1 to 15. A list of iteration counts would also be allowed: --rounds=10,12,15. May be in this case we should allow --rounds=19000-20000 (just be sure to document whether or not the boundaries are included). If we decide to support multiple iteration counts, I would suggest using --rounds= for the most significant iteration count, and --rounds2= for the second most significant iteration count. (Formats which have just one iteration count, but a computation time that also depends on salt size, could then decide to misuse the second iteration_count function to calculate some pseudo iteration count based on salt length.) What do you think? Too much effort for a limited use? Should I have started discussing that topic on john-users? (I can either re-post this on john-users, or post a version which skips some of the possible implementation details and focuses on user interface enhancements.) Frank
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.