[standards-jig] 0k & hash (was: Doc feedback - things that should be fixed)

Max Horn max at quendi.de
Mon Oct 15 21:07:18 UTC 2001


At 10:26 Uhr -0500 15.10.2001, Iain Shigeoka wrote:

[...]

>Yes.  I certainly agree.  Jer has said he is working on a new draft 
>of 0k anyhow so perhaps we can have him make sure he addresses these 
>concerns.
>
>If it is case sensitive, I think it is an implementation bug in the 
>server not an issue for the standard

We are hashing the hex representation over and over again. It will 
make a big difference if we hash a lowercase or an uppercase 
representation. Hence this is a thing that is inherent to the 
protocol, and certainly not an "implementation bug in the server"



>For message digests, the hash values (and info to be hashed) are raw 
>byte data (even if the input happens to be text).  The hex 
>representation is just a way to represent the data in ascii/utf8 (so 
>it is xml friendly).
>   SHA should produce a 160 bit message digest.  Raw bit data.  If 
>you are doing subsequent hashes on the return digest data, you need 
>to re-hash that 160 bit message digest as raw data.
>  At least that is the spec.

No. The specs do not say this clearly. And I think we should then go 
with the real world.


>  Bits are bits and the hex representation of the 160 bit md should 
>be the same whether you use capitol 'A' or lower 'a' to represent 
>the hex number.  It is an extra step that gains you nothing to turn 
>the raw md to text, then hash that although it may be done that way 
>because of the implementation...  I don't think so though.

True it gains us nothing. But hashing hex is the de-facto standard, 
as jer implemnted it (and he came up with it in the first place, too, 
after all, so he should know best what he meant). If you now change 
it to hash the digest binary instead of the lower case hex, you break 
all clients that already support it.

While hashing the hex-represntation doesn't gain us anything, I see 
no advantage to be gained by changing it either; but I see some 
drawbacks (namely breaking clients).


Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:max at quendi.de>
phone: (+49) 6151-494890



More information about the Standards mailing list