Date: Mon, 03 May 1999 09:45:10 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Peter Jeremy <peter.jeremy@auss2.alcatel.com.au> Cc: provos@openbsd.org, dm@openbsd.org Subject: Re: Blowfish/Twofish Message-ID: <6765.925717510@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 03 May 1999 12:02:44 %2B1000." <99May3.114810est.40331@border.alcanet.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <99May3.114810est.40331@border.alcanet.com.au>, Peter Jeremy writes: >Adam Shostack <adam@homeport.org> wrote: >>The reason to not use it for passwords is that the function you want >>(if you're going to not change the model), is a hash function, not a >>block cipher. > >You'd better let Bob Morris know this :-). > >Why can't a block cipher (like, say DES) be used for a password >hashing function? (It can, but we can't export it from the US.) My final comments on this thread will be this: I think you are all overlooking the important bit of the password field as stored in /etc/master.passwd: the "$1$" which starts the field. This is the part that allows us to change the algorithm at any time where we feel the need. I just scanned the http://www.citi.umich.edu/u/provos/papers/bcrypt.ps.gz paper, and they too seem to overlook that the important thing is not to be able to design an algorithm which will last for a thousand years, but the ability to use a new one when we need to. That is not to say that the stuff they've come up with isn't better than what we have, it certainly look a lot more robust. It lacks the stamp of approval for export from the US which MD5 has, but that could probably be arranged too. In difference from virtually all other cryptographic uses, we don't care much about our data (plaintext passwords), we can replace them cheaply and easily, we just don't want anybody (ourselves included) to be able to read them. This is what gives rise to what I call the "Kleenex-method", if our algorithm gets compromised, or even just a credible threat of a weakness, we'll just replace our algorithm *AND OUR DATA* with whatever we feel the best candidate at the time. The worried looks which the paper gives the MD5 acrobatics I wrote are probably fair and just. It has to be remembered that I were not trying to beat the DES based code, but rather the lousy XOR based hash we used for export at the time. I think that I suceeded in beating the DES based code by a huge margin also, and I think that has protected a lot of FreeBSD based systems in the last 5 years from brute-force or dictionary attacks, and I would personally think that the MD5 code can safely last another 3 years. We have the mechanisms inplace for running multiple algorithms already, so I don't see any particular reason to have wild arguments about which one we should use: take your own pick. In the FreeBSD project we have some concerns to address about exportability, but otherwise there are no restrictions. I don't know if we should setup a "registry" for the identifying magic strings ($1$, $2$, $2a$ and so on) to avoid clashes, maybe we could get the IANA to do it for us if we managed to squeze a RFC through the editors. [provos, dm: should we attempt this ?] -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6765.925717510>