Date: Thu, 15 Mar 2001 22:23:29 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jonathan@graehl.org (Jonathan Graehl) Cc: freebsd-arch@FreeBSD.ORG (freebsd-Arch) Subject: Re: ftpd SITE MD5 and "really bad links" Message-ID: <200103152223.PAA23296@usr05.primenet.com> In-Reply-To: <NCBBLOALCKKINBNNEDDLIEIPDMAA.jonathan@graehl.org> from "Jonathan Graehl" at Mar 15, 2001 11:52:26 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103152223.PAA23296>