3 ms·

> Not encrypted, hashed. In modern systems, sure. SunOS shipped with crypt_unix as the only option for many many years, which used the lower bits of the first

by mike_d 5y ago

> Not encrypted, hashed. In modern systems, sure. SunOS shipped with crypt_unix as the only option for many many years, which used the lower bits of the first 8 characters of your password as a 56-bit key. This was then combined with one of 4096 possible salt values and used as a key to DES encrypt a fixed string. Solaris 9 (I think?) added the option to switch to sunmd5, so at the time OP was probably correct in it being encryption (abet one way) and not a hash function.

tialaramex 5y ago
There are now two replies in this vein, so I guess it's worth a moment to expand on how it's not encryption it's a hash even though (a variant of) DES is used and you think of DES as being for encryption. The whole point of encryption is that you can decrypt it, but that's not what's going on here. Instead the DES block cipher is being used as a poor man's compression function for the hash. A compression function in this context (distinct from "data compression" like Deflate) is a one way function that takes a bunch of bits and spits out fewer bits in a way that means the result isn't at all helpful for determining the inputs. It's completely normal to use a block cipher for a compression function. This is the essence of the Merkle–Damgård construction familiar from MD5 through to the SHA-2 family. If you were inventing a new high performance cryptographic hash in 2021 you wouldn't do it 'cos it's going to be slower than your competitors, but if you were trying to cobble together a working password hash for early Unix without a PhD in cryptography DES is all you need. You can do much stupider things with DES in this space. Microsoft owns at least three which I know of, some of them are even still in use in corporate environments. But DES is not encrypting anything in these scenarios, it's a compression function. The problem with all those Microsoft solutions I characterise as "much stupider" isn't DES, although obviously you should stop using DES because it's 2021, but lots of other dumb things they got wrong.
- 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 ago
    On 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.

by mike_d 5y ago

tialaramex 5y ago

There are now two replies in this vein, so I guess it's worth a moment to expand on how it's not encryption it's a hash even though (a variant of) DES is used and you think of DES as being for encryption. The whole point of encryption is that you can decrypt it, but that's not what's going on here. Instead the DES block cipher is being used as a poor man's compression function for the hash. A compression function in this context (distinct from "data compression" like Deflate) is a one way function that takes a bunch of bits and spits out fewer bits in a way that means the result isn't at all helpful for determining the inputs. It's completely normal to use a block cipher for a compression function. This is the essence of the Merkle–Damgård construction familiar from MD5 through to the SHA-2 family. If you were inventing a new high performance cryptographic hash in 2021 you wouldn't do it 'cos it's going to be slower than your competitors, but if you were trying to cobble together a working password hash for early Unix without a PhD in cryptography DES is all you need. You can do much stupider things with DES in this space. Microsoft owns at least three which I know of, some of them are even still in use in corporate environments. But DES is not encrypting anything in these scenarios, it's a compression function. The problem with all those Microsoft solutions I characterise as "much stupider" isn't DES, although obviously you should stop using DES because it's 2021, but lots of other dumb things they got wrong.

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 ago
  On 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.