Posts: 11
Threads: 7
Joined: Jul 2017
Hi
When I run the example hash from the examples page for hash 14000 the expected password is 'hashcat1' however I'm getting different and incorrect results depending on which piece of hardware I am running it on. Any ideas why?
When I run:
hashcat64.exe -m 14000 a28bc61d44bb815c:1172075784504605 -a 3 ?l?l?l?l?l?l?l1 --potfile-disable -D2
The output password is
a28bc61d44bb815c:1172075784504605:haribat1
When I run:
hashcat64.exe -m 14000 a28bc61d44bb815c:1172075784504605 -a 3 ?l?l?l?l?l?l?l1 --potfile-disable -D1
a28bc61d44bb815c:1172075784504605:haricat1
If I slow hashcat down using this command the same result happens:
hashcat64.exe -m 14000 a28bc61d44bb815c:1172075784504605 -a 3 ?l?l?l?l?l?l?l1 --potfile-disable -D2 -n 1 -u 1 -T 1 --force
a28bc61d44bb815c:1172075784504605:harhbat1
Code:
OpenCL Info:
Platform ID #1
Vendor : NVIDIA Corporation
Name : NVIDIA CUDA
Version : OpenCL 1.2 CUDA 11.2.162
Device ID #1
Type : GPU
Vendor ID : 32
Vendor : NVIDIA Corporation
Name : GeForce GTX 1080
Version : OpenCL 1.2 CUDA
Processor(s) : 20
Clock : 1835
Memory : 2048/8192 MB allocatable
OpenCL Version : OpenCL C 1.2
Driver Version : 461.92
Platform ID #2
Vendor : Intel(R) Corporation
Name : Intel(R) OpenCL
Version : OpenCL 2.1 WINDOWS
Device ID #2
Type : CPU
Vendor ID : 8
Vendor : Intel(R) Corporation
Name : Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz
Version : OpenCL 2.1 (Build 0)
Processor(s) : 12
Clock : 3300
Memory : 16362/65448 MB allocatable
OpenCL Version : OpenCL C 2.0
Driver Version : 2020.11.11.0.13_160000
Posts: 442
Threads: 2
Joined: Dec 2015
Firstly, please update Hashcat to at least 6.1.1 Release and retest if your behavior is not expected.
Second, DES KPA is one of many modes that i believe can have collisions. Many keys may produce the plaintext provided, and as such these results may not be unexpected. Retest with --keep-guessing to get more keys and see if the expected key is among them.
Posts: 11
Threads: 7
Joined: Jul 2017
(04-05-2021, 04:48 AM)Chick3nman Wrote: Firstly, please update Hashcat to at least 6.1.1 Release and retest if your behavior is not expected.
Second, DES KPA is one of many modes that i believe can have collisions. Many keys may produce the plaintext provided, and as such these results may not be unexpected. Retest with --keep-guessing to get more keys and see if the expected key is among them.
Hi Chick3nman
I upgraded as suggested and ran the --keep-guessing options. The results are below, none of which are the password. Are you able to test and do you get the expected result? Maybe it's just my install that's doing something funny.
a28bc61d44bb815c:1172075784504605:harhbat1
a28bc61d44bb815c:1172075784504605:hashbat1
a28bc61d44bb815c:1172075784504605:harhbau1
a28bc61d44bb815c:1172075784504605:hasicau1
Posts: 218
Threads: 0
Joined: Nov 2017
Weird I get more results when using latest hashcat but no hashcat1:
a28bc61d44bb815c:1172075784504605:harhcat1
a28bc61d44bb815c:1172075784504605:hashbat1
a28bc61d44bb815c:1172075784504605:harhbau1
a28bc61d44bb815c:1172075784504605:hashbau1
a28bc61d44bb815c:1172075784504605:harhcau1
a28bc61d44bb815c:1172075784504605:hashcau1
yet when specifying a smaller charset it returns
hashcat -1 hasct -m 14000 a28bc61d44bb815c:1172075784504605 -a 3 "?1?1?1?1?1?1?11" --potfile-disable
a28bc61d44bb815c:1172075784504605:hashcat1
Posts: 442
Threads: 2
Joined: Dec 2015
I will take a look at this and see if there is an issue with this kernel. It's possible its either a driver/runtime bug or something on our end.
Posts: 5,227
Threads: 233
Joined: Apr 2010
It's all working perfect!
DES KPA mode expects a key, not a password. The DES key is based on 7 bit per bytes, not 8. So it's just us who are interpreting the results incorrectly. All of the passwords hashcat outputs are valid DES keys for this particular example CT
T pair. They can be used in your cryptographic problem the same way as the original key.
The real problem which is caused by this is that the hashcat user is wasting time because hashcat checks multiple times the same key (without knowing). To get rid of this effect, use -1 charsets/DES_full.hcchr --hex-charset. This makes your brute force attack much more efficient.
About the different results -D1 and -D2: That's becuase the worksizes have influence on the mask order. You need to combine it with the about the keep-guessing: See docs/limits.txt section about keep-guessing. If you now connect both situations together you understand that there's no problem.
Posts: 5,227
Threads: 233
Joined: Apr 2010
Some visualization:
$ echo a28bc61d44bb815c | xxd -r -p | openssl enc -d -des-ecb -nopad -K $(echo -n hashcat1 | xxd -p) | xxd -p
1172075784504605
$ echo a28bc61d44bb815c | xxd -r -p | openssl enc -d -des-ecb -nopad -K $(echo -n harhcat1 | xxd -p) | xxd -p
1172075784504605
$ echo a28bc61d44bb815c | xxd -r -p | openssl enc -d -des-ecb -nopad -K $(echo -n hashbat1 | xxd -p) | xxd -p
1172075784504605
$ echo a28bc61d44bb815c | xxd -r -p | openssl enc -d -des-ecb -nopad -K $(echo -n harhbau1 | xxd -p) | xxd -p
1172075784504605
$ echo a28bc61d44bb815c | xxd -r -p | openssl enc -d -des-ecb -nopad -K $(echo -n harhcau1 | xxd -p) | xxd -p
1172075784504605
$ echo a28bc61d44bb815c | xxd -r -p | openssl enc -d -des-ecb -nopad -K $(echo -n hashcau1 | xxd -p) | xxd -p
1172075784504605
$ echo a28bc61d44bb815c | xxd -r -p | openssl enc -d -des-ecb -nopad -K $(echo -n invalid1 | xxd -p) | xxd -p
7b0fbe243c08147c
