Colin Putney wrote:
>> ? (Note that they are exactly byte-reversed.) Of course, I could just 
>> say "... reverse hex asLowercase" instead, but it seems strange that I 
>> should need to. There must be something obvious I'm overlooking.
> 
> I don't know the answer to this, but I'm quite interested in it as well. 
> I'll let you know if I find anything.

I've done some more digging, and it looks like endianness:

  - the SHA1 tests in the Smalltalk code use "reversed asInteger", which
    tells me I'm not overlooking anything :-)

  - the definition of SHA1 is apparently "internally big-endian,"
    according to a few random mailing-list postings I found via google,
    but there seems to be some confusion about what that actually means
    (I know I'm confused, for one). I haven't read the RFC (3174) yet.

  - Squeak's digitLength and digitAt: methods treat integers as sequences
    of base-256 digits indexed from 1, with little-end at position 1.
    The asByteArray on Integer stores base-256 digits into the byte array
    with big-end at position 1.

  - Here's an interesting datapoint: note that in the code below,
    reg asInteger ~= reg asByteArray asInteger !

    16r01020304 = 16909060
    reg _ (ThirtyTwoBitRegister new load: 16r01020304)
    reg asInteger
    reg asByteArray asInteger

  - SHA1's primHasSecureHashPrimitive is true in my VM (win32), so I
    subclassed SHA1 and overrode it to always-false to exercise the
    software implementation, and fortunately it gives the same answers.

So perhaps there's an internal vs. external byte-order issue. I still 
haven't found it, but it looks like that's the reason for the required 
reversal.

Tony
-- 
  [][][] Tony Garnock-Jones  | Mob: +44 (0)7905 974 211
    [][] LShift Ltd          | Tel: +44 (0)20 7729 7060
  []  [] www.lshift.net      | Email: tonyg at lshift.net