Date: Tue, 10 Jan 2006 14:10:33 +1100 From: Peter Jeremy <PeterJeremy@optushome.com.au> To: Pavel Gorshkov <gorshkov.pavel@gmail.com> Cc: freebsd-stable@freebsd.org Subject: Re: SHA1_Update() produces wrong results for large buffers Message-ID: <20060110031033.GB60380@cirb503493.alcatel.com.au> In-Reply-To: <20060109235953.GA2868@localhost> References: <20060109235953.GA2868@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2006-Jan-10 02:59:53 +0300, Pavel Gorshkov wrote: >The problem is that the asm-optimized version fails on large input >buffers. Attached is a test program, which mmaps a file and then >just feeds its contents to SHA1_Update(): "openssl sha1" agrees with the shared version on -current. > # exits immediately, displaying a WRONG hash value > ./sha1test.md-static test-1.5G > 747cd7172ce7737d1735cf936c0d69ce0f733fcd I get this on 7-current as well. Copying the relevant bits from libmd and compiling it myself, I get the same behaviour. The fact that this exits virtually instantly strongly suggests that it is broken (rather than the shared version). My initial guess is that an operation on the length is overflowing 32 bits. Unfortunately, the asm is rather opaque - it was auto-generated by a perl script that doesn't seem to included in the repository. (There is a sha1-586.pl in openssl but it generates different code). As far as I can determine, the asm code (sha1_block_x86) is designed to process an integral number of SHA1 blocks of input, leaving the remainder to be processed in the C code. Using the debugger, the asm code is not looping when passed 1610612736 (1.5G) - which explains the rapid exit and incorrect result. -- Peter Jeremy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060110031033.GB60380>