Example hash 14000 not returning correct password
#1
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
Reply
#2
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.
Reply
#3
(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
Reply
#4
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
Reply
#5
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.
Reply
#6
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 CTTongueT 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.
Reply
#7
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
Reply