# **Distributed Keyspace Attacks**
_Coordinating parallel cracking across multiple nodes_
Distributed attacks are not a separate attack _type_, they are a **scaling technique**.
The underlying attack logic (mask, rules, dictionary, hybrid) remains unchanged; what changes is **how the keyspace is divided and consumed**.
This section documents **manual and semi-automatic methods** for splitting work across multiple systems in controlled research environments.
---
## **Why Distribute?**
Password search spaces grow exponentially. Even modest masks can exceed what a single system can reasonably process.
Distribution allows you to:
- Reduce total wall-clock time
- Use heterogeneous hardware efficiently
- Avoid duplicate work
- Scale research without altering attack logic
Key principle:
> **Each node must operate on a mutually exclusive slice of the same keyspace.**
---
## **Hashcat: Manual Keyspace Distribution**
Hashcat exposes explicit **keyspace calculation**, **offset**, and **limit** controls, making it well-suited for deterministic distribution.
### **Step 1: Calculate Total Keyspace**
Before distributing work, determine the full size of the search space.
```
hashcat -a 3 -m 0 ?a?a?a?a?a?a --keyspace
```
**Output**
```
81450625
```
This represents the _total number of candidates_ generated by the mask.
---
### **Step 2: Divide the Keyspace**
For **3 nodes**:
```
81450625 ÷ 3 ≈ 27,150,208
```
Each node receives a contiguous block.
---
### **Step 3: Assign Skip and Limit Per Node**
Hashcat uses:
- -s → starting offset (skip)
- -l → number of candidates to process (limit)
#### **Node 1**
```
hashcat -a 3 -m 0 hash.txt ?a?a?a?a?a?a -s 0 -l 27150208
```
#### **Node 2**
```
hashcat -a 3 -m 0 hash.txt ?a?a?a?a?a?a -s 27150208 -l 27150208
```
#### **Node 3**
```
hashcat -a 3 -m 0 hash.txt ?a?a?a?a?a?a -s 54300416 -l 27150209
```
> The final node absorbs any remainder to ensure full coverage.
---
### **Key Properties of Hashcat Distribution**
- Deterministic
- No coordination required after launch
- Works for:
- Mask attacks
- Hybrid attacks
- Rule-based attacks
- Ideal for:
- Air-gapped clusters
- Stateless compute nodes
- Batch research experiments
---
## **John the Ripper: Manual Node Assignment**
John takes a different approach. Rather than explicit keyspace slicing, it uses **node indexing**.
This model is better suited to:
- CPU-heavy workloads
- Wordlist + rule attacks
- Incremental modes
---
### Manual Node Distribution
with --node and --fork
Example: **3 systems**, each with **8 CPU cores**
#### **Node 1**
```
john --format=<type> hash.txt --wordlist=dict.txt --rules=All --fork=8
node=1-8/24
```
#### **Node 2**
```
john --format=<type> hash.txt --wordlist=dict.txt --rules=All --fork=8
node=9-16/24
```
#### **Node 3**
```
john --format=<type> hash.txt --wordlist=dict.txt --rules=All --fork=8
node=17-24/24
```
Interpretation:
- 24 = total logical execution slots
- Each node claims a distinct slice
- No overlap occurs if ranges are assigned correctly
---
## **Additional John Parallelization Techniques**
John supports multiple scaling strategies beyond manual node slicing:
### **Option 1: OpenMP**
Enable shared-memory parallelism by enabling OpenMP during build.
All of this requires [GCC 4.2 or newer](https://openwall.info/wiki/internal/gcc-local-build "internal:gcc-local-build"), or another OpenMP-capable C compiler (also tested with Sun Studio 12). To enable the OpenMP parallelization, the proper `OMPFLAGS` line in the `Makefile` needs to be uncommented.
Best for:
- Single multi-core systems
- Uniform workloads
---
### **Option 2: Custom Incremental Modes**
Define additional incremental charsets and modes in john.conf.
One approach to splitting the keyspace by password length would be to create additional `incremental` modes in `john.conf`. This approach is limited to the maximum password length set at compile time, but is not difficult to set up or run. The following is an example based on `Incremental:All`:
```john.conf
[Incremental:All5]
File = $JOHN/all.chr
MinLen = 0
MaxLen = 5
CharCount = 95
[Incremental:All6]
File = $JOHN/all.chr
MinLen = 6
MaxLen = 6
CharCount = 95
[Incremental:All7]
File = $JOHN/all.chr
MinLen = 7
MaxLen = 7
CharCount = 95
[Incremental:All8]
File = $JOHN/all.chr
MinLen = 8
MaxLen = 8
CharCount = 95
```
To use, one would launch four separate instances of JtR, each with its own `–incremental=AllN` argument (replacing N with the maximum length). Although those instances with larger keyspaces will, in theory, take longer to complete, all of the instances will be accelerated due to not having to search other lengths. In practice, with _slow enough_ hashes and a large enough number of different salts, none of the instances or only those for very short lengths will terminate in a reasonable amount of time, so this approach achieves a reasonable split of the workload.
It is advisable to split the lengths range _by complexity_ to the extent possible (like it is done in the example above) rather than _numerically_ (e.g., 0-2, 3-4, 5-6, 7-8 would be very inefficient).
Best for:
- Research into structure-specific brute force
- Controlled exploration of subspaces
---
### **Option 3: Built-in MPI (MPI-style) Support**
John includes internal multiprocessing logic that can coordinate across cores and processes.
No additional patch is required, just uncomment the last two lines in the MPI section in Makefile so it looks like this:
```
## Uncomment the TWO lines below for MPI (can be used together with OMP as well)
## If you experience problems with MPI_Barrier, remove -DJOHN_MPI_BARRIER
## If you experience problems with MPI_Abort, remove -DJOHN_MPI_ABORT
CC = mpicc -DHAVE_MPI -DJOHN_MPI_BARRIER -DJOHN_MPI_ABORT
MPIOBJ = john-mpi.o
```
More information about MPI is in doc/README.mpi.
Best for:
- CPU clusters
- Long-running incremental jobs
PLEASE NOTE: MPI is a full parallelization suite; as such it has extensive configuration options and daemons to run before using. If using one of the MPI-based works, please familiarize yourself with the MPI version you install - seldom can one simply install them and immediately begin using 'mpirun'.
---
## **Comparative Summary**
|**Aspect**|**Hashcat**|**John the Ripper**|
|---|---|---|
|Distribution Model|Explicit keyspace slicing|Node indexing|
|Best For|Mask & hybrid attacks|Rules & incremental|
|GPU Friendly|Yes|Limited|
|Stateless Nodes|Excellent|Moderate|
|Deterministic Coverage|Yes|Yes (if configured correctly)|
---
## **Takeaways**
- Distributed cracking is about **coordination**, not speed alone
- Hashcat excels at **mathematically precise distribution**
- John excels at **rule-driven and CPU-centric workloads**
- Misconfigured ranges cause:
- Overlap
- Missed keyspace
- Invalid research conclusions
> Always calculate first. Always document ranges. Always assume human error.
---
[[Advanced Compositional Attacks]]
[[Home]]
#advanced #sudad