I've been comparing the two and have noticed more than an accidental bit shift mentioned long ago.

But my observations have come from the BNCS Util source.  I haven't looked at any ASM.  Could someone explain to me some of the inconsistencies in Battle.net's take on SHA-1?

The greatest deviation that I've noticed is the fact that Broken SHA-1 in the BNCS Util source does absolutely none of the message padding that's in standard SHA-1.  I'm assuming I've made a mistake in reading the source.

Another deviation are the constants used.  The first two 'K' values are the same as SHA-1, but the next two are different.  There's a few other small inconsistencies as well.  But I'de like to get an answer to the padding problem first

But it's clear that BNCS Util works (I'm assuming the source released is up to date).

Also, the documentation I've been using for SHA-1 is http://www.itl.nist.gov/fipspubs/fip180-1.htm

Well, I'm guessing that the message padding is just general convention for hashing non-string msgs.  But this introduces another problem.  SHA-1 uses 512bit blocks for hashing.  And as far as I can tell from BNCS Util, it only processes one block.

Does this limit the password length in actuality to only 64 bytes?  Any bytes after the first 64 are never touched by XSHA-1?

If BNCS util is as you describe, either it's wrong or I'm wrong. :)  The X-SHA1 implementation that I remember is capable of digesting up to 1kb at a time, and updates enough internal state information that you can process as many 1kb blocks as you want.

[quote author=Kp link=topic=11594.msg112635#msg112635 date=1116255921]
If BNCS util is as you describe, either it's wrong or I'm wrong. :)  The X-SHA1 implementation that I remember is capable of digesting up to 1kb at a time, and updates enough internal state information that you can process as many 1kb blocks as you want.
[/quote]

But SHA-1 digests 64 bytes at a time, what are the parameter boundaries for XSHA-1 in clients?  How does it create the 'message to be digested' from the password?

Not quite sure what you mean by "parameter boundaries."  If you mean, how much can be put into X-SHA1 in a single call, 1kbyte (as I said above).  The 'message to be digested' is the password.  Unlike most modern designers, Blizzard's people weren't particularly devious when they put this together; when in doubt, guess the most straightforward solution.  If you're wrong, try a straightforward solution coupled with a stupid mistake. ;)

But SHA-1 requires the message to be a certain size (512bit blocks) to be digested.

So unless the password is that size, the client must be formatting it in some way before any actual hashing begins.

I'd asume padding on the front or back with 0x30's or 0x00's.

* bump *

There is also a diffrence in the way the... first... thingy... is done.

Regular Sha-1: (I think, I am doing this from memory)
[code]
W[i+16] = SPIN_SHIFT(1, (W[i+2] ^ W[i+8] ^ W[i+14] ^ W[i+16]) % 32 );
[/code]

X-Sha-1:
[code]
W[i+16] = SPIN_SHIFT(1, (W[i] ^ W[i+2] ^ W[i+8] ^ W[i+13] ^ W[i+3]) % 32);
[/code]

So it seems that this... part... is done diffrently.

I really do not understand the padding on the messages in the orginal Sha-1. Could someone find it in their kind heart to explain this to me? Please?

Nice hair. :)

[quote author=Joe[x86] link=topic=11594.msg113826#msg113826 date=1117097901]
Nice hair. :)
[/quote]

Har.

There are only three differences between standard SHA-1 and Blizzard's hack.

1) Standard SHA-1 wants the message to be in big endian, while Blizzard's message should be little endian.

2) Blizzard typo'd the rotates for the MsgSchedule functions.  Instead of rotating X by Y bits, they rotated Y by X bits.  Example:

Standard:
[code]return W[i & 15] = _lrotl(
                        W[(i + 13) & 15] ^ W[(i + 8) & 15] ^
                        W[(i +  2) & 15] ^ W[ i      & 15], 1);[/code]

Blizzard:
[code]return W[i & 15] = _lrotl(1,
                        W[(i + 13) & 15] ^ W[(i + 8) & 15] ^
                        W[(i +  2) & 15] ^ W[ i      & 15]);[/code]

With _lrotl being:
[code]static inline unsigned int _lrotl(const unsigned int x, const unsigned char bits)
{
        return (x << bits) | (x >> ((sizeof(unsigned int) * 8) - bits));
}[/code]

3) Message padding.  Blizzard's message padding is memset(message + currentPosition, 0, sizeof(block) - currentPosition);  The standard SHA-1 has the memset, but then is padded by appending a bit of 1 to the end of the message (for example if the message to be hashed was 15 bits, and all zeros, the message would be 0000000000000001).  After that, the length (in bits) of the message is appended to the end of the block (not the end of the message) in big endian form.

There are more rules to follow for the padding depending on the length of the message, but if you want a truely in depth read about the padding, find the RFC and start reading.