Date: Mon, 03 May 1999 18:18:01 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: David Mazieres <dm@reeducation-labor.lcs.mit.edu> Cc: peter.jeremy@auss2.alcatel.com.au, adam@homeport.org, freebsd-security@FreeBSD.ORG, provos@openbsd.org Subject: Re: Blowfish/Twofish Message-ID: <8574.925748281@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 03 May 1999 11:54:48 EDT." <199905031554.LAA09846@reeducation-labor.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199905031554.LAA09846@reeducation-labor.lcs.mit.edu>, David Mazieres writes: >Well, I missed the beginning of the thread, but just got CCed on this, >so I will respond. > >First of all, the "$1$" clearly is important, because evan >variable-cost hashes could potentially fail. We mention this briefly >in our implementation section. I now regret that we did not credit >FreeBSD for this more explicitly. We weren't really trying to claim >this as a contribution; we just wanted to make the point that it's >easy to have multiple hash functions in one password file. Ahh, don't worry about that, we have the stuff in the CVS trees if we ever get to disagree about where it came from :-) >> 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. > >You could easily create an implementation of bcrypt that could not be >used as a block cipher. What exactly is magically blessed about MD5? It's been blessed for export by the US gov in any form. >> 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. > >Of course you can do that. You are effectively using the shared >library version number on libc or libcrypt to determine the cost of >hashing passwords. It's a lot nicer to have the two decoupled. You lost me there... All I meant was that passwords should be changed every so often anyway, so changing algorithm doesn't have the tremendous scope it would have if you had a 5 year archive of correspondence encrypted (retrieve, decrypt, encrypt, store, delete+whipe old versions from media/destroy old media). >If you are uncomfortable incorporating bcrypt for export-control >reasons, I would still encourage you to allow variable cost in >whatever you design next to replace MD5crypt (i.e. $3$). I think at >this point peole can probably tolerate an algorithm about 10 times >slower than MD5crypt. It should probably require between 1/10th of a >second and one second to check a password, depending on the speed of >the hardware. I have no plans on creating a $3$ in the forseeable future, if at all: We'll probably just adopt something from OpenBSD :-) Until we have some kind of assurance that $2a$ can be exported we will have to go through all the mess with the .za repository and all that to use it. Poul-Henning -- 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?8574.925748281>