Date: Tue, 6 Jul 1999 23:26:28 +0930 (CST) From: Kris Kennaway <kkennawa@physics.adelaide.edu.au> To: Peter Wemm <peter@netplex.com.au> Cc: security@freebsd.org Subject: Re: Improved libcrypt ready for testing Message-ID: <Pine.OSF.4.10.9907062308350.13993-100000@bragg> In-Reply-To: <19990706133410.58E2B78@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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:
$Blowfish$xy$<salt><password> following the OpenBSD format (xy = log2 rounds),
and
_<rounds><salt><password> for New-DES. (<rounds> encoded as a base-64 binary
value).
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 there
are cryptographic implications to doing that).
It would probably also be worthwhile redefining New-DES and our blowfish
format to fit this common form:
$DES$<rounds>$salt$hash
The question then becomes whether we make <rounds> implementation-defined or
always log base-2?
> 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.
> 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
static void
encode_salt(salt, csalt, clen, logr)
char *salt;
u_int8_t *csalt;
u_int16_t clen;
u_int8_t logr;
#endif
{
salt[0] = '$';
salt[1] = BCRYPT_VERSION;
salt[2] = 'a';
salt[3] = '$';
snprintf(salt + 4, 4, "%2.2u$", logr);
encode_base64((u_int8_t *) salt + 7, csalt, clen);
}
Having said that, the version doesn't actually seem to be used in their code
($2$ is equivalent to $2a$), but it's there presumably for forward
compatability.
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-security" 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.9907062308350.13993-100000>