Practical documentation · Authorized use only

Crunch

Crunch generates character-combination wordlists. Its safe educational use is demonstrating combinatorial growth and generating tiny synthetic test data; do not create large password dictionaries or connect output to authentication-testing tools.

WordlistGeneratorCLIPasswords

Start safely and get useful results

Best for

• Password-policy education
• Small synthetic test-data generation

Not for

• Attack-ready wordlists
• Real credential guessing

Before you run anything

• Document the authorized target, time window, success criteria, data-handling rules, and a named stop contact before you begin.
• Confirm the installed version with the tool’s version or help command, then compare its documented behavior with the linked upstream project before relying on any option.

Practical workflows

Beginner

Inspect limits and syntax

Scenario: Plan a classroom demonstration of search-space growth.

crunch --help

Review command syntax and calculate expected output size before generating any data.

Expected use: The plan should use a very small alphabet and length range.

Intermediate

Create a tiny bounded demonstration file

Scenario: Show the difference between two-character combinations and strong passphrases.

crunch 2 2 ab -o /tmp/synthetic-demo.txt

Generate only four combinations from a two-character alphabet and remove the file after review.

Expected use: Use the file only to explain growth, storage cost, and why password length matters.

Interpret results like an analyst

• Output grows exponentially with length and alphabet size; estimate disk impact before running.
• Small educational examples should lead to stronger policy, not operational guess lists.

Common mistakes and operating tips

Avoid

• Generating enormous files without disk and retention controls.
• Treating test-data generation as acceptable for real password attacks.

Operational discipline

• Treat command output as evidence, not a conclusion: retain the command, version, scope, timestamp, and a redacted result in the engagement record.
• Start with the smallest safe scope, validate expected behavior in a lab or pilot, then expand only when the authorization and monitoring plan support it.

Verify against the current upstream

Tool behavior and release syntax can change. Treat this guide as practical operating context, then verify version-specific details against the upstream project before an assessment.

Open authoritative upstream documentation