Some algorithms have ambiguous hashes (e.g. case-insensetive usernames
in Net-NTLMv2 hashes). This optional function allows test modules to
unify the hashlist before the verification process starts.
Also update readme and minor code formatting.
Contains a kernel for the ODF 1.1 encryption implemented in OpenOffice.
The algorithm uses a SHA-1 checksum, a PBKDF2-HMAC-SHA1 key derivation
with 1024 iterations and Blowfish-CFB encryption.
Valid hashes can be extracted with the libreoffice2john.py script,
available from the John the Ripper Jumbo repository at
https://github.com/magnumripper/JohnTheRipper/blob/bleeding-jumbo/run/libreoffice2john.py
You have to remove the filename suffix at the end of the hash before
passing it to hashcat. Also see 'hashcat -m18600 --example-hashes'.
You can leave the filename prefix if you use the --username option to
process those hashes.
- Add hash-mode 18600 (Open Document Format (ODF) 1.1 (SHA-1, Blowfish))
- Tests: add hash-mode 18600 (Open Document Format (ODF) 1.1 (SHA-1, Blowfish))
Contains a kernel for the latest ODF 1.2 encryption implemented in
LibreOffice. The algorithm uses a SHA-256 checksum, a PBKDF2-HMAC-SHA1
key derivation with 100000 iterations and key stretching and AES-CBC
encryption.
Valid hashes can be extracted with the libreoffice2john.py script,
available from the John the Ripper Jumbo repository at
https://github.com/magnumripper/JohnTheRipper/blob/bleeding-jumbo/run/libreoffice2john.py
You have to remove the filename suffix at the end of the hash before
passing it to hashcat. Also see 'hashcat -m18400 --example-hashes'.
You can leave the filename prefix if you use the --username option to
process those hashes.
- Add hash-mode 18400 (Open Document Format (ODF) 1.2 (SHA-256, AES))
- Tests: add hash-mode 18400 (Open Document Format (ODF) 1.2 (SHA-256, AES))
Adds suport for the Japanese cipher Camellia with 256-bit keys as used
by VeraCrypt.
- Add Camellia header decryption checks to all VeraCrypt kernels
- Add test containers for remaining cipher combinations
Adds support for the Russian cipher specified in GOST R 34.12-2015, also
known as Kuznyechik (Grasshopper).
- Add Kuznyechik header decryption checks to all VeraCrypt kernels
- Add test containers for available Kuznyechik cipher combinations
The test scripts have grown to be quite big (over 15000 lines) and
are hard to navigate. There are multiple if branches with over
40 conditional checks chained together. This commit solves some of
those issues.
- Unite big repetetive if conditions into clean array lookups
- Move 'install help' commands to a separate shell script
- Adjust array lookup in test.sh to behave more intuitive
- Add comments at key points to simplify navigation
- Code formatting
Hardware Monitor: Renamed --gpu-temp-disable to --hwmon-disable
Fixed invalid warnings about throttling in case --hwmon-disable was used
Fixes https://github.com/hashcat/hashcat/issues/1757
Implement HMAC based on GOST 34.11-2012 Streebog-512 as well as a test
case for it. Both the PyGOST + hmac python module and the VeraCrypt HMAC
for Streebog-512 were used as references. The kernels expect the digests
to be in big-endian order according to the RFC examples for Streebog.
Fix two bugs from commit 224315dd62.
- Add hash-mode 11850: HMAC-Streebog-512 (key = $pass), big-endian
- Add test case for hash-mode 11850
- Bugfix for a3-pure Streebog kernels (modes 11700 and 11800)
- Rename a few Streebog constants in interface.h
Complete Streebog support with pure kernels that allow for passwords
longer than 64 characters. Provide generic inc_hash_streebog files
for future Streebog-based hash modes (HMAC, PBKDF2, VeraCrypt).
Include streebog support in the test suite. For this, python module
PyGOST is needed. Also add clarification to hash mode description
stating that Streebog hashes are expected in big-endian byte order.
There are several implementations, including PyGOST, which default
to little-endian byte order, while the RFC examples are big-endian.
- Add pure kernels for hash-mode 11700 (Streebog-256)
- Add pure kernels for hash-mode 11800 (Streebog-512)
- Tests: Add hash-modes 11700 (Streebog-256) and 11800 (Streebog-512)
Added hash-mode 16801 = WPA-PMKID-PMK
Renamed lot's of existing WPA related variables to WPA-EAPOL in order to distinguish them with WPA-PMKID variables
Renamed WPA/WPA2 to WPA-EAPOL-PBKDF2
Renamed WPA/WPA2 PMK to WPA-EAPOL-PMK
Renamed pure kernels to default kernels
Replaced long option --length-limit-disable with --optimized-kernel-enable
Replaced short option -L with -O
Set --optimized-kernel-enable to unset by default
Something weird happend here, read on!
I've expected some performance drop because this algorithm is using the password data itself inside the iteration loop.
That is different to PBKDF2, which I've converted in mode 2100 before and which did not show any performance as expected.
So after I've finished converting this kernel and testing everything works using the unit test, I did some benchmarks to see how much the
performance drop is.
On my 750ti, the speed dropped (minimal) from 981kH/s -> 948kH/s, that's mostly because of the SIMD support i had to drop.
If I'd turn off the SIMD support in the original, the drop would be even less, that us 967kH/s -> 948kH/s which is a bit of a more reasable
comparison in case we just want to rate the drop that is actually caused by the code change itself.
The drop was acceptable for me, so I've decided to check on my GTX1080.Now the weird thing: The performance increased from 6619kH/s to
7134kH/s!!
When I gave it a second thought, it turned out that:
1. The GTX1080 is a scalar GPU so it wont suffer from the drop of the SIMD code as the 750ti did
2. There's a change in how the global data (password) is read into the registers, it reads only that amount of data it actually needs by using
the pw_len information
3. I've added a barrier for CLK_GLOBAL_MEM_FENCE as it turned out to increase the performance in the 750ti
Note that this kernel is now branched into password length < 40 and larger.
There's a large drop on performance where SIMD is really important, for example CPU.
We could workaround this issue by sticking to SIMD inside the length < 40 branch, but I don't know yet how this can be done efficiently.
