From owner-freebsd-security Mon May 3 0: 8:36 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 3D8A614F41 for ; Mon, 3 May 1999 00:08:32 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id JAA27207; Mon, 3 May 1999 09:08:31 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id JAA37791; Mon, 3 May 1999 09:08:29 +0200 (MET DST) Date: Mon, 3 May 1999 09:08:29 +0200 From: Eivind Eklund To: Dug Song Cc: freebsd-security@FreeBSD.ORG Subject: Re: Blowfish/Twofish Message-ID: <19990503090829.N32819@bitbox.follo.net> References: <19990502122142.A289@samurai.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: ; from Dug Song on Sun, May 02, 1999 at 03:48:52PM -0400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, May 02, 1999 at 03:48:52PM -0400, Dug Song wrote: > On Sun, May 02, 1999 at 06:16:47PM +0200, Eivind Eklund wrote: > > > > The point of this exercise would (IMO, at least) only be OpenBSD > > compatibility, where OpenBSD for marketeering reasons has decided to > > use Blowfish as part of their hash algorithm. > > marketeering? read the paper being presented by Niels Provos and David > Mazieres at next month's USENIX (FREENIX track), and decide for yourself - > "A Future-Adaptable Password Scheme": Let me try to write the same as above in a slightly different way: I don't believe the use of Blowfish as a part of the hash algorithm is necessary to achieve the design goals, and I believe it was done in order to show off OpenBSD's ability to include crypto in the core distribution. I may be wrong; it is credible to have done so for convenience reasons, too, if the authors had already developed an extensible cipher based on Blowfish, and did not want to repeat their work or force cryptoanalysis of two systems instead of one. If FreeBSD should switch default password storage hash, my vote would be for something that allowed secure challenges against it - e.g. SRP (which is much more elegant than my own proposal to achieve the same goal, which was based on searching for RSA keys). Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message