openwall / openwall/john

Simplify/speedup "--show" and "--make-charset"

Open
#4,430 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

maintenance/cleanup RFC / discussion
Dominant language
C
Stars
13.6k
Forks
2.6k
PR merge metrics
No merged PRs in 30d

Description

As I pointed out in https://github.com/openwall/john/issues/4388#issuecomment-719723533, jumbo's usage of split() on --show is much heavier than core's, which is both good (allowing for #4428) and bad (slow). #4429 is a start at optimizing it, however we can do more.

Perhaps most importantly, we can optimize the scanning of the formats list in ldr_show_pot_line() to cache and probe the previous line's format's valid() first.

Also, I think right after merging #4429 (or adding to it) we can also make ldr_cracked_hash() case-sensitive.

Further, why do we(?) even bother to build the db->cracked_hash table when invoked with --make-charset? We should probably skip that.

Finally, given that #4429 obsoletes FMT_SPLIT_UNIFIES_CASE, should we drop that flag from everywhere, keep it around in case we need it again later, or rename/repurpose it (e.g., to just FMT_SPLIT_UNIFIES, so that we'd set it in more formats yet be able to skip split() in ldr_show_pot_line() for most formats)?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading ldr_show_pot_line(), ldr_cracked_hash(), the --make-charset path, and uses of FMT_SPLIT_UNIFIES_CASE. Compare the behavior and cost of --show and --make-charset before deciding which optimizations and flag changes are still appropriate; done means the selected changes preserve existing behavior while reducing unnecessary work.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
cli, performance
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.