From root@turing.morons.org  Sat Jun  8 12:24:20 2002
Return-Path: <root@turing.morons.org>
Received: from turing.morons.org (cpe-66-1-148-96.ca.sprintbbd.net [66.1.148.96])
	by hub.freebsd.org (Postfix) with ESMTP id 7075237B405
	for <FreeBSD-gnats-submit@freebsd.org>; Sat,  8 Jun 2002 12:24:19 -0700 (PDT)
Received: by turing.morons.org (Postfix, from userid 0)
	id BD119A94B; Sat,  8 Jun 2002 12:32:08 -0700 (PDT)
Message-Id: <20020608193208.BD119A94B@turing.morons.org>
Date: Sat,  8 Jun 2002 12:32:08 -0700 (PDT)
From: Nick Johnson <freebsd@spatula.net>
Reply-To: Nick Johnson <freebsd@spatula.net>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: crypt-md5 may prematurely drop a source of entropy
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         39037
>Category:       bin
>Synopsis:       crypt-md5 may prematurely drop a source of entropy
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Jun 08 12:30:01 PDT 2002
>Closed-Date:    Sun Jun 09 03:07:01 PDT 2002
>Last-Modified:  Sun Jun 09 03:07:01 PDT 2002
>Originator:     Nick Johnson
>Release:        FreeBSD 4.5-RELEASE-p2 i386
>Organization:
Morons.org
>Environment:
System: FreeBSD turing.morons.org 4.5-RELEASE-p2 FreeBSD 4.5-RELEASE-p2 #4: Wed Apr 10 10:27:18 PDT 2002 root@turing.morons.org:/usr/src/sys/compile/TURING i386


	
>Description:
In crypt-md5.c, there is the following bit of code:

        /* Don't leave anything around in vm they could use. */
        memset(final,0,sizeof final);

        /* Then something really weird... */
        for (i = strlen(pw); i ; i >>= 1)
                if(i&1)
                    MD5Update(&ctx, final, 1);
                else
                    MD5Update(&ctx, pw, 1);

Note that "final" is referenced after it has been memset to all 0's.
The result is that rather than getting more noise from the md5 data
from previous steps, the same number (0) is always applied.  If this
is intentional, please disregard this PR :)

	
>How-To-Repeat:
Watch "final" with any of a variety of inputs; observe that it's always 0.
	
>Fix:

This PR is informational only, and shouldn't be taken to mean that this 
should be fixed in the current implementation.  Indeed, if it WERE 
changed, it would completely break any existing password files, as the
outcome of the function will definitely change.

Also note that this isn't terribly likely to reduce the security of the
algorithm, since MD5 is pretty irreversible to begin with.

I note this not to be a smartass, but should there be another revision of 
theh md5-style passwords (which would no doubt have a different magic)
this piece of code may be worth revisiting.

	


>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: phk 
State-Changed-When: Sun Jun 9 03:04:08 PDT 2002 
State-Changed-Why:  
Well, what can I say ?  I usually don't attain perfection, neither in first 
nor last attempt :-) 

Yes, there are certain things in the md5crypt which should have been 
thought better out.  The piece of code you point out is just one example. 

There have actually been a couple of revisions run over in OpenBSD, I've 
seen $2$ and $2a$ passwords already. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=39037 
>Unformatted:
