Date: Mon, 3 May 1999 11:54:48 -0400 (EDT) From: David Mazieres <dm@reeducation-labor.lcs.mit.edu> To: phk@critter.freebsd.dk Cc: peter.jeremy@auss2.alcatel.com.au, adam@homeport.org, freebsd-security@FreeBSD.ORG, provos@openbsd.org Subject: Re: Blowfish/Twofish Message-ID: <199905031554.LAA09846@reeducation-labor.lcs.mit.edu> In-Reply-To: <6765.925717510@critter.freebsd.dk> (message from Poul-Henning Kamp on Mon, 03 May 1999 09:45:10 %2B0200) References: <6765.925717510@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
> cc: adam@homeport.org, freebsd-security@FreeBSD.ORG > cc: provos@openbsd.org, dm@openbsd.org > Date: Mon, 03 May 1999 09:45:10 +0200 > From: Poul-Henning Kamp <phk@critter.freebsd.dk> > > 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. 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. > 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? MD5's compression function (or MD5 itself) functions perfectly well as a block cipher in OFB or CFB modes. Is there some directive from the US government allowing the export of MD5 in source form? Bcrypt could easily be manipulated to achieve the same status as, say, arc4random--based on ARC4, but the implementation is hard to use for encryption. > 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. 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. David 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?199905031554.LAA09846>