From owner-freebsd-security Mon Jul 29 12:01:53 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA16078 for security-outgoing; Mon, 29 Jul 1996 12:01:53 -0700 (PDT) Received: from kdat.calpoly.edu (kdat.csc.calpoly.edu [129.65.54.101]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA16073 for ; Mon, 29 Jul 1996 12:01:51 -0700 (PDT) Received: (from nlawson@localhost) by kdat.calpoly.edu (8.6.12/N8) id MAA00753; Mon, 29 Jul 1996 12:01:38 -0700 From: Nathan Lawson Message-Id: <199607291901.MAA00753@kdat.calpoly.edu> Subject: Re: Crack 4.1 patches for FBSD To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Mon, 29 Jul 1996 12:01:38 -0700 (PDT) Cc: freebsd-security@freebsd.org In-Reply-To: <2867.838405954@critter.tfs.com> from "Poul-Henning Kamp" at Jul 26, 96 08:32:34 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> Any news on any attacks on our MD5 based passwords ? > > >>The only problem I see with them is that MD5 is so darn quick, your number >>of crypts goes way up even with the present number of iterations. The DES >>hash used in most Unicen was desigend to be slow (originally taking 1 second >>per crypt on a VAX 11/780), but that fell prey to optimization and exponential >>CPU speed increases. >> >>Perhaps some intermediate permutations between hashes might be appropriate, >>but I'd consider the algorithm very carefully as it is very easy to end up >>with something that is no slower than the original and significantly less >>secure. > > Have you actually timed them ? Have you actually looked at the code that > generates the MD5 passwords in FreeBSD ? It sounds to me like you havn't... Yes, I actually have looked at it and timed them. I do not have any numbers with me any more, but I'd definitely like to see some. To expand further on what I meant, there's a comment in the code which says that the hash loop takes 34 ms to execute on a Pentium 60. In my opinion, this is on the rather quick side still, hence my comment that perhaps some more permutation could be useful. I was hoping to provoke some kind of discussion as to the cryptographic correctness of the MD5 crypt substitute. Also, the choices for the center of the loop (& 1, % 7, etc) seem rather arbitrary, so it might be possible that these cases do not help much in certain instances. For instance, since it's known that you go from one to a thousand in the loop, the exact same sequence of MD5Updates are executed, no matter what the user uses as a password. This makes it a good candidate for unrolling the loop and possibly combining various phases of the Updates into one step. I'm curious as to whether FreeBSD's crypt has come under any scrutiny from the crypto community, and would perhaps like some justification for the choices in the hashing loop. It's very difficult when arbitrary choices are made in crypto to determine their validity or possible problems. -- Nate Lawson "There are a thousand hacking at the branches of CPE Senior evil to one who is striking at the root." CSL Admin -- Henry David Thoreau, 'Walden', 1854