In message <[EMAIL PROTECTED]>, Spike Gronim writes:
> I understand the literal meaning of /usr/src/lib/libcrypt/crypt-md5.c,
>and the algorithm it uses to create it's output. However, I do not understand
>the design criteria or functional purpose of several elements of the process.
At the time the MD5 hash was written we could not use anything DES based
due to ITAR.
The design criteria was to get a strong, preferably stronger than DES,
password encryption, which would make brute force attacks very much
harder.
At the time I had seen a demonstration of a bruteforce attack on a
plain DES scrambled hardware which took less time than a good
dinner to complete.
The longer salt was to twart prebuilt dictionary attacks. With the
12 bit salt, an ExaByte tape could contain a *very* large precomputed
dictionary, by increasing the salt-space several orders of magnitude
this method was twarted.
The overall MD5 chewing code were done to try to make the algorithm
unsuitable for hardware implementation (MD5 is already pretty bad
for that) the various unlinear steps would make it practically
impossible to do a hardware implementation of anything but the basic
MD5: you would still need to iterate through it.
I don't know enough about cryptographic math to argue that this
algorithm is perfect or even "good". I know it to be better than
the DES things, and infinitely better than the scrambler we had
to fill the hole for DES at the time.
In light of this theoretical backing, I introduced the $1$ marker,
which allows the algorithm to be replaced in a backwards compatible
way (as already done by OpenBSD).
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
