Symmetric ciphers as hash functions
Steven M. Bellovin
smb at cs.columbia.edu
Tue Nov 1 11:36:38 EST 2005
In message <d4f1333a0510312333k44e882e7l75adbff3a12b02c3 at mail.gmail.com>, "Trav
is H." writes:
>> How does one properly use a symmetric cipher as a cryptographic hash
>> function? I seem to be going around in circles.
>
>Isn't this is like asking a mechanic how to use a screwdriver as a hammer?
Given that we seem to know much more about block cipher design than
hash function design, finding a hash function that is provably as
strong as a block cipher is a great idea.
>
>> Reversing the situation (using the data as the key and a known plain-
>> text) makes a plaintext attack seem like a joy etc..
>
>This is exactly how traditional Unix crypt(3) implementations used
>DES, although they used a null string as the input and added some salt
>to prevent dictionary attacks. What exactly do you mean by "plaintext
>attack"? If we choose the plaintext, then we can compute the hash...
>what's the problem? All hashes I can think of work this way.
>
>Incidentally, does anyone know how crypt(3) used salt, and why it used
>so little instead of using a 64-bit IV in some mode with feedback?
>
Have you read the Morris and Thompson paper? If not, see
http://citeseer.ist.psu.edu/morris79password.html
Briefly, though, the 12 bits of salt were used to permute the E-box in
DES. They limited the salt to 12 bits because there was little need for
any more. The salt served three purposes: discouraging hardware attacks
based on off-the-shelf DES chips; rendering precomputed dictionaries
prohibitively expensive; and forcing an attacker to attack individually each
password in a file. If you have 500 passwords -- a lot for 1978 -- and
4K choices, the odds are high that you won't get much overlap in salt
space. Even with 15K entries, a high figure even today, you're not going
to increase the attacker's work factor by more than a few bits. As for
the dictionary size -- they felt (probably correctly) that the size
expansion was already large enough that that wasn't a feasible path for
the attacker.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
More information about the cryptography
mailing list