Date: Wed, 07 Jul 1999 00:05:24 +0800 From: Peter Wemm <peter@netplex.com.au> To: Kris Kennaway <kkennawa@physics.adelaide.edu.au> Cc: security@freebsd.org Subject: Re: Improved libcrypt ready for testing Message-ID: <19990706160524.DD35C78@overcee.netplex.com.au> In-Reply-To: Your message of "Tue, 06 Jul 1999 23:26:28 %2B0930." <Pine.OSF.4.10.9907062308350.13993-100000@bragg>
next in thread | previous in thread | raw e-mail | index | archive | help
Kris Kennaway wrote:
> On Tue, 6 Jul 1999, Peter Wemm wrote:
>
> > I'd strongly suggest encoding the number of rounds as well, ie:
> > $token$salt$rounds$password
>
> For the two algorithms which currently support variable rounds, it's
> already encoded into the password:
OK.
> I was thinking about defining the general format as you suggest, and leaving
> the "rounds" null (or zero) for things like MD5/SHA-1 which have a static
> count (or maybe allowing variable rounds there, although I don't know if ther
e
> are cryptographic implications to doing that).
I guess the main thing is to not define any new methods without the rounds
in there somehow.
> 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.
> 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.
> > That way plain old crypt(3) can work without needing to dive off to
> > /etc/login.conf.db. When passwd(1) generates the string it can set the
> > number of rounds either from the count in login.conf, or perhaps some sort
> > of time count. For example, suppose you specify that the root login is
> > to have a minimum number of X rounds, and the has has to run for at least
> > N seconds on this system. So, it could scale according to cpu speed.
>
> That's an interesting idea. I'll have to think about that.
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. There's also the risk that your K7-1000 encodes
and exports a password to a 386SX-25. :-)
> > Also, I don't think using $2a$ for openbsd blowfish is a good idea - use
> > $2$ directly since it's what they use. Ther is no need to be different for
> > the sake of it.
>
> Are you sure? from lib/libc/crypt/bcrypt.c
No, sorry. :-)
Cheers,
-Peter
--
Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
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?19990706160524.DD35C78>