Re: x86 SHA1: Faster than OpenSSL
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 6, 2009, 02:04 UTC
- Message-ID
- <7vocqtu286.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <alpine.LFD.2.00.0908052144430.16073@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
Show 13 quoted lines
> On Wed, 5 Aug 2009, Linus Torvalds wrote:
>
>> But while looking at 32-bit issues, I noticed that I really should also
>> cast 'len' when shifting it. Otherwise the thing is limited to fairly
>> small areas (28 bits - 256MB). This is not just a 32-bit problem ("int" is
>> a signed 32-bit thing even in a 64-bit build), but I only noticed it when
>> looking at 32-bit issues.
>
> Even better is to not shift len at all in SHA_update() but shift
> ctx->size only at the end in SHA_final(). It is not like if
> SHA_update() could operate on partial bytes, so counting total bytes
> instead of total bits is all you need. This way you need no cast there
> and make the code slightly faster.Like this?
By the way, Mozilla one calls Init at the end of Final but block-sha1 doesn't. I do not think it matters for our callers, but on the other hand FInal is not performance critical part nor Init is heavy, so it may not be a bad idea to imitate them as well. Or am I missing something?
diff --git a/block-sha1/sha1.c b/block-sha1/sha1.c index eef32f7..8293f7b 100644 --- a/block-sha1/sha1.c +++ b/block-sha1/sha1.c @@ -31,7 +31,7 @@ void blk_SHA1_Update(blk_SHA_CTX *ctx, const void *data, unsigned long len) { int lenW = ctx->lenW; - ctx->size += (unsigned long long) len << 3; + ctx->size += (unsigned long long) len; /* Read the data into W and process blocks as they get full */ @@ -68,6 +68,7 @@ void blk_SHA1_Final(unsigned char hashout[20], blk_SHA_CTX *ctx) /* Pad with a binary 1 (ie 0x80), then zeroes, then length */ + ctx->size <<= 3; /* bytes to bits */ padlen[0] = htonl(ctx->size >> 32); padlen[1] = htonl(ctx->size);