Date: Wed, 09 Mar 2005 12:00:06 -0800 From: Colin Percival <cperciva@freebsd.org> To: Richard Coleman <rcoleman@criticalmagic.com> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libmd Makefile sha256.3 sha256.h sha256c.c shadriver.c src/sbin/md5 Makefile md5.c Message-ID: <422F55C6.3000207@freebsd.org> In-Reply-To: <422F50A6.907@criticalmagic.com> References: <200503091923.j29JN4Ti063868@repoman.freebsd.org> <422F50A6.907@criticalmagic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Richard Coleman wrote: > Is there a reason that there are multiple versions of > md5/sha1/sha256/etc in the source tree? As far as I could tell, we didn't have sha256 in the tree until I added it. As for md5 and sha1, it's useful to have a minimalist libmd for applications which don't require the bloated monst^W^W^W OpenSSL, and these are small enough that a bit of duplication really doesn't matter. > It seems if these could be centralized, then it would be easier to have > assembly accelerated versions for each platform, or better yet to > utilize crypto hardware. I'd be surprised if you could find crypto hardware which could accelerate hashing -- the time it takes to send large amounts of data to a crypto processor would probably exceed the time it takes to perform the hashing on the host cpu. Assembly optimization might be worthwhile; but for this sort of code, I think you'd need to have a version optimized for each *processor* rather than each *platform* in order to get any significant gain. These hash functions are designed for 32-bit processors in a manner which makes it fairly hard for the compiler to get things wrong. Colin Percival
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?422F55C6.3000207>