From owner-freebsd-arch Thu Mar 15 14:23:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id AFC6F37B718 for ; Thu, 15 Mar 2001 14:23:48 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id PAA17880; Thu, 15 Mar 2001 15:17:08 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpdAAAIdaWQI; Thu Mar 15 15:16:52 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id PAA23296; Thu, 15 Mar 2001 15:23:29 -0700 (MST) From: Terry Lambert Message-Id: <200103152223.PAA23296@usr05.primenet.com> Subject: Re: ftpd SITE MD5 and "really bad links" To: jonathan@graehl.org (Jonathan Graehl) Date: Thu, 15 Mar 2001 22:23:29 +0000 (GMT) Cc: freebsd-arch@FreeBSD.ORG (freebsd-Arch) In-Reply-To: from "Jonathan Graehl" at Mar 15, 2001 11:52:26 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > If the probability of errors (which pass 32-bit-1s-complement muster) > on the net route between the client and FTP server is as high as once > in a gigabyte, then SITE MD5 could save lives, not just make life > easier for ports people. This is a specious argument. Such errors would occur only in the event that the file was transferred. A SITE MD5 would come out correct, and the error would occur anyway during subsequent file transfer. Which make me think of a good use for /dev/random: put it out there as an mp3 file named for a Metallica song, and lie about it's size. 8-). The cryptographic value of the SITE MD5 is nonexistant, as we all already agree; at best, it's cryptographically misleading to users who will equate it with security. It seems to me that it _might_ have limited utility in the case of a post-download verification of the file contents, in the case where you don't have a precalculated MD5 on hand, and you don't trust your transport to not have one of those near-magical errors that you describe (above). This wouldn't be useful in the "ports" case, since it doesn't care _why_ the MD5 failed, only that it invalidates the file from consideration (since the ports mechanism _is_ a security mechanism, based on the trust of the /usr/ports hierarchy you are using for the install). So the new limited utility would be: 1) download the file 2) SITE HASH MD5 foo 3) compare the local hash to the site hash 4) tell the user the 9 Terabytes they just spent the better part of their life downloading are "no good": sorry, there is a 4 bit error in that copy of "Sweet Child of Mine" that you just got from the mp3.com site. If you want to implement it for post-download checking, go ahead. Realize that any FTP server where I'm forced to support it, however, will be operating off of cached data, and it will be a cold day in hell before I let you DOS-attack my FTP server with the frigging thing operating on demand. I think your time would be better spent fixing the protocols you distrust, so that it would be unnecessary. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message