SHA1 reversed bytes?
Tony Garnock-Jones
tonyg at lshift.net
Thu Mar 10 10:09:40 UTC 2005
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
More information about the Squeak-dev
mailing list
|