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

Iain Shigeoka iainshigeoka at yahoo.com
Tue Oct 16 15:57:09 UTC 2001


At 11:07 PM 10/15/2001 +0200, you wrote:
>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"

Well, either the server implementation is wrong or the protocol spec is 
wrong as the spec clearly says you digest the hash not the lower case, 
ascii hex representation of the hash.  I know historically that the 
implementation has always been held as higher authority over the spec so if 
that holds true here, we should probably go with the server implementation.

>>  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).

Yes. And this is something for the foundation to decide (or 
security-jig).  I can certainly see the validity of going with the current 
de facto implementation standard.  However the spec is only a draft 
proposal so implementors should have been aware of that it may change 
before being accepted!

Just from a logical and "clean" perspective, it would really bother me to 
make the spec follow the current implementation.  Using the ascii 
representation introduces a lot of unnecessary complexity to the standard 
(you must enforce lower case hex, and do you pad left with zeros or not, 
etc) and computational overhead doing the string conversions for each hash.

This seems like an argument for the security-jig though.

-iain


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com




More information about the Standards mailing list