0

While trying out the wordlist generator crunch in Kali Linux 2020.1 I came across the following behaviour:

root@kali:/home/kali# crunch 10 10 \
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890,.-:! -o chars.txt
Crunch will now generate the following amount of data: 1604471776359824323 bytes
1530143524513 MB
1494280785 GB
1459258 TB
1425 PB
Crunch will now generate the following number of lines: 1822837804551761449

root@kali:/home/kali# crunch 10 10 \
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890,.-: -o chars.txt
Crunch will now generate the following amount of data: 17251705690018753536 bytes
16452508630770 MB
16066902959 GB
15690334 TB
15322 PB
Crunch will now generate the following number of lines: 1568336880910795776

How come removing the exclamation mark blows up the calculated wordlist size to 15322PB in contrast to being 1425PB if it were to be included?

For me this very much looks like a bug in the code.

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
FloatingPointOperation
  • 1
  • 1

1 Answers1

1

Yes, this is a bug, but not a problematic one.

crunch counts the expected number of bytes as a 64-bit integer. When you look at the number of bytes of the bottom output, you can see that it is 17251705690018753536, which is a rather huge number.

In fact, if we take the log_2(17251705690018753536), we get 63.9..., which means that it's very close to the 64 bit overflow point, which is 18446744073709551615. By adding more characters to the wordlist, the number becomes too large for crunch to handle and it will roll over. Any subsequent output count will be useless and arbitrary.

But why is this not a problem? Simply put, because nobody makes wordlists this large. Could this be fixed? Yes, crunch could use 128-bit integers, but it would not really solve any real-world problem.

Community
  • 1