Date: Wed, 7 Jul 1999 09:20:39 +0930 (CST) From: Kris Kennaway <kkennawa@physics.adelaide.edu.au> To: Peter Wemm <peter@netplex.com.au> Cc: hackers@freebsd.org Subject: Re: Improved libcrypt ready for testing Message-ID: <Pine.OSF.4.10.9907070909080.30995-100000@bragg> In-Reply-To: <19990706160524.DD35C78@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
[I've redirected this to -hackers where I probably should have sent it
initially.]
On Wed, 7 Jul 1999, Peter Wemm wrote:
> > It would probably also be worthwhile redefining New-DES and our blowfish
> > format to fit this common form:
> >
> > $DES$<rounds>$salt$hash
>
> IMHO, don't change the existing new-des stuff since it's partially understood
> in a number of places already.
Okay.
> > The question then becomes whether we make <rounds> implementation-defined or
> > always log base-2?
>
> I'd suggest leave it implementation defined since there's no telling how
> fast or slow a given algorithm may be. IMHO, do it either log2 or log10 or
> do some sort of power encoding, ie literally store 2 and 12 for 2^12 or 10
> and 6 for 10^6 rounds.
Hmm. I don't know that using variable bases buys much; you can always
approximate to the nearest power-of-2 and not pay much. I think leaving it
implementation-defined is best.
There's a danger of over-engineering this, but I was also considering the
merits of a 'version number' like OpenBSD's "algorithm 2, version a" for
blowfish. That allows for algorithm changes without requiring a new name
token, and /possibly/ reduces the impact of other vendors choosing
incompatible algorithms with the same name (although only statistically).
So the generic format would be $token$version$rounds$salt$hash
e.g. $MD5$1$$salt$hash (the rounds being null because the algorithm doesn't
support variable-round encryption).
The extra size of password entries doesn't seem to be a big deal to me..
> The risk is that there has to be a reasonable minimum, otherwise an evil
> hacker (TM) might run some cpu burners to slow down the timing to get a
> weaker number of rounds.
You could run the timer so it counts the CPU time of the passwd program
itself, not the wall time. e.g. run it for some period of time, find it did
1000 basic operations per CPU-second, and calculate that 10000 rounds are
needed for passwords that crypt() in 10 seconds.
> There's also the risk that your K7-1000 encodes
> and exports a password to a 386SX-25. :-)
There is that, but it's mroe of an administrative problem. You can already
screw yourself that way by specifying 2^16-round blowfish passwords :-)
Kris
-----
"Never criticize anybody until you have walked a mile in their shoes,
because by that time you will be a mile away and have their shoes."
-- Unknown
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.OSF.4.10.9907070909080.30995-100000>