hashcat Forum

Full Version: TEA/XTEA imp
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Is there by some chance that you guys are planning of implemeting the TEA/XTEA algo?
No. TEA is a block cipher, and hashcat targets hash algorithms. See also https://hashcat.net/forum/thread-4874-po...l#pid27356
Indeed it is a block cipher, with 128bit key, which works on 64bit blocks.
Given one scenario where its not used for streams (memory, files), but only one block, to find the key then the difference between hash and crypto is not much.
Sure, provided there's a KDF involved. Is it?
In the system Im looking at, the assumption is that TEA is used as a KDF. We call it a pwdgen
pwd = tea(Secret key, unique bytes)

btw doesn't hashcat support DES and other cryptos?...
No, Hashcat doesn't support cracking DES encryption. But it does support some password hashing algorithms which incorporate DES (descrypt, LM hash, etc.) Hashcat does support some popular encrypted filetypes (Office, PDF, RAR, 7z, etc.) but these are algorithms which run the password through a KDF to derive an encryption key, and we attack the KDF, not the crypto algorithm.

Hashcat is open source now, so if this is important to you, you can add it yourself Wink
(12-05-2015, 07:06 PM)iceman Wrote: [ -> ]In the system Im looking at, the assumption is that TEA is used as a KDF.  We call it a pwdgen
pwd = tea(Secret key,  unique bytes)

And the "Secret key" is a password chosen by a human? If not, there's nothing to attack: You obviously can't brute-force a 128-bit key.
Yes, I did notice that Hashcat went open source.
But I'm curious, how does the KDF for descrypt look like? I mean algorithmwise.
DEScrypt's KDF is among the weakest out there: The password is truncated to eight characters, and all characters have their 8th bit stripped. That leaves us with a 56-bit DES key.