Passwords with a length greater than 28 for 7z, and 23 for 7z-opencl, don't work.

[IamC8]

I wrote a small bash script to show the problems.

#!/bin/bash


#--format=7z-opencl --device=2 (Max Length is 23)
#--format=7z (Max Length is 28)
# Anything greater than 28 for 7z, and 23 for 7z-opencl, doesnt work?
pwd=$(tr -dc A-Za-z0-9 </dev/urandom | head -c 23)

# Create random file name
file_name=$(tr -dc A-Za-z0-9 </dev/urandom | head -c 5)

# Name files to use
file_7z="./"$file_name".7z"
raw_file="upload_test.txt"
hashes="./7z_hashes.txt"
passwords="./wordlist.txt"

# Create random file to 7z and encrypt
dd if=/dev/zero of=$raw_file bs=1M count=10

# Create random passwords in wordlist.txt
for ((i = 0 ; i < 10 ; i++)); do
	str_len=$(var=100 && shuf -i 1-${var} -n 1)
	str=$(tr -dc A-Za-z0-9 </dev/urandom | head -c $str_len)
	echo $str >> $passwords
done

# Add created pwd to wordlist.txt
echo $pwd >> $passwords

# Make 7z encrypted file
7z a $file_7z -p$pwd $raw_file

# John magic
~/src/john/run/7z2john.pl $file_7z > $hashes
~/src/john/run/john --wordlist=$passwords $hashes --format=7z-opencl --device=2
~/src/john/run/john --wordlist=$passwords $hashes --format=7z
~/src/john/run/john --show -format=7z-opencl $hashes

# Print usefull info
echo "Password is: "$pwd 
echo "7z encrypted file is: "$file_7z
echo "Pwd length is: ${#pwd}"


# Remove created files
rm $file_7z # REM this line to decrypt file manually to test?
rm $raw_file
rm $hashes
rm $passwords

NOTES

As stated, any password with a length greater than 28 for 7z, and 23 for 7z-opencl, doesn't decrypt 7z files.
I believe this is a bug.

System

• Ubuntu 20.04
• Linux ssd250 5.15.0-91-generic 101~20.04.1-Ubuntu SMP Thu Nov 16 14:22:28 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

John
Version: 1.9.0-jumbo-1+bleeding-047dc0775c 2023-12-14 16:58:50 -0300
Build: linux-gnu 64-bit x86_64 AVX2 AC OMP OPENCL
SIMD: AVX2, interleaving: MD4:3 MD5:3 SHA1:1 SHA256:1 SHA512:1
CPU tests: AVX2
$JOHN is ./
Format interface version: 14
Max. number of reported tunable costs: 4
Rec file version: REC4
Charset file version: CHR3
CHARSET_MIN: 1 (0x01)
CHARSET_MAX: 255 (0xff)
CHARSET_LENGTH: 24
SALT_HASH_SIZE: 1048576
SINGLE_IDX_MAX: 2147483648
SINGLE_BUF_MAX: 4294967295
Effective limit: Number of salts vs. SingleMaxBufferSize
Max. Markov mode level: 400
Max. Markov mode password length: 30
gcc version: 9.4.0
GNU libc version: 2.31 (loaded: 2.31)
OpenCL headers version: 1.2
Crypto library: OpenSSL
OpenSSL library version: 01010106f
OpenSSL 1.1.1f 31 Mar 2020
GMP library version: 6.2.0
File locking: fcntl()
fseek(): fseek
ftell(): ftell
fopen(): fopen
memmem(): System's
times(2) sysconf(_SC_CLK_TCK) is 100
Using times(2) for timers, resolution 10 ms
HR timer: clock_gettime(), latency 65 ns
Total physical host memory: 15864 MiB
Available physical host memory: 10630 MiB
Terminal locale string: en_ZA.UTF-8
Parsed terminal locale: UTF-8

[claudioandre-br]

any password with a length greater than 28 for 7z, and 23 for 7z-opencl, doesn't decrypt 7z files.

The maximum password length supported by the CPU format is 28 (23 for OpenCL).

$ john --list=format-all-details --format=7z
Format label                         7z
 Disabled in configuration file      no
Min. password length                 0
Max. password length                 28

So, it is by design. Looking at the source code, it looks like you can remove this limitation on CPU format if you disable SIMD.

Anyway, do you think there is anything we can improve?

[solardiz]

it looks like you can remove this limitation on CPU format if you disable SIMD.

Specifically, this is done by the --disable-simd option to configure, e.g. make distclean && ./configure --disable-simd && make -sj4. Of course, performance is expected to be worse.

do you think there is anything we can improve?

For some cracking modes/options, we print warnings or refuse to work when the requested candidate password lengths exceed the format's maximum. However, for wordlist mode without a min/max length requested, this is tricky since the candidates' length range will depend on what's in the wordlist and isn't known when cracking just starts. We could maybe be checking and print warnings the first time a candidate password exceeds the format's maximum, but it'd have performance impact on fast hashes.

We could alternatively be printing the format's maximum on each run just in case the user would find it unexpected. Not as a warning, but as an informational message. We could then disable that with a slight reduction of verbosity level (on the command-line or in john.conf). We're already printing a few other informational messages that could fall under the same category, and be controlled together.