3 ms·
It takes 56 bits in and spits 64 bits out, and is not lossy. You can decrypt it. It doesn't even hit the Wikipedia definition of a hash function by being able t
by mike_d 5y ago
It takes 56 bits in and spits 64 bits out, and is not lossy. You can decrypt it. It doesn't even hit the Wikipedia definition of a hash function by being able to accept a variable length input (I don't think truncating input really fits the spirit).
You are clearly extremely knowledgeable in this field. But I think you are trying to retroactively apply everything we have learned about how to do it correctly to code that was written 30 years ago. :)
- tialaramex 5y agoOn the contrary, it takes a 56-bit key and a 64-bit block and it spits out a 64-bit block, that's your compression function. 120 bits narrowed to 64. crypt(3) does that 25 times, the key is your password, the initial 64-bit block is all zeroes - the resulting 64-bit block after the 25 iterations is the hash stored in /etc/passwd It's just a hash. The hash is too small by modern standards, and so you shouldn't use it. But it's still a hash. You cannot in fact decrypt it, which is why L0phtcrack, still, today, doesn't decrypt it. I mean, sure, if you knew the password and salt (to make the right modified DES, that's what the salt does in crypt(3)), you could therefore generate the key, and decrypt the hash block 25 times in a row to get back all zeroes. But discovering it's always all zeroes isn't the goal here, you can't break into a Unix system by knowing that the initialisation state of the password hash is all zeroes. The goal of something like L0phtcrack is to discover the secret password and the password isn't encrypted, it's hashed.