Re: [http-auth] Definition of SHA256 and SHA512/256 algorithms in RFC 7616

Hi Chaim,

I do not think that the intention was to truncate any of these hashes.
It seems that the example is incorrect.

Can you please open a new errata against the RFC?
https://www.rfc-editor.org/errata.php

Thanks,
 Rifaat

On Thu, Dec 29, 2016 at 1:20 PM, Chaim Geretz <chaim.geretz@idt.net> wrote:

> As a follow up, FIPS 180-3 does not have a definition of SHA512/256, other
> than the inference from section 7 that allows truncation of the result of
> an existing algorithm. That aligns with the example given in RFC 7616.
>
> FIPS 180-4 introduced the possibility of a different implementation of
> SHA512/256, but still leaves open the possibility of truncation of the
> results of an existing algorithm.
>
>
> On Thu, Dec 29, 2016 at 1:12 PM, Chaim Geretz <chaim.geretz@idt.net>
> wrote:
>
>> Sophie,
>>
>> Thanks for your response
>>
>> > The linked IANA registry for the hash algorithms clarifies the use as
>> in FIPS 180-3.
>>
>> The reference to FIPS 180-3 is only for the HTTP Digest Algorithm Values SHA-256
>> and SHA-512.
>>
>> http://www.iana.org/assignments/http-dig-alg/http-dig-alg.txt does not
>> include any specification information for SHA-512-256 save for a pointer to
>> RFC 7616.
>>
>> Chaim
>>
>>
>> On Thu, Dec 29, 2016 at 12:43 PM, Sophie Bremer <
>> sophie.bremer@netzkonform.de> wrote:
>>
>>> Hi Chaim,
>>>
>>> thank you for pointing this out!
>>> It explains some problems I had myself with the implementation for proxy
>>> servers.
>>>
>>> > Am 28.12.2016 um 20:19 schrieb Chaim Geretz <chaim.geretz@idt.net>:
>>> >
>>> > Greetings,
>>> >
>>> > I think that RFC 7616 needs to define or point to a document
>>> describing how the various hash algorithms mentioned in Section 3.2 are to
>>> be implemented.
>>>
>>> The linked IANA registry for the hash algorithms clarifies the use as in
>>> FIPS 180-3.
>>> On the other hand the registry may change in the future and so the
>>> definition of the algorithm value too.
>>> If this is a possible scenario, I agree with you.
>>> I like to see more opinions for this proposal.
>>>
>>> > Inspecting the values used in Section 3.9.2 for userhash and response
>>> shows that they are generated by truncating the hex output of a sha512 hash
>>> to the initial 64 hex characters.
>>>
>>> You are right.
>>>
>>> > If this is the desired implementation of SHA512/256 then this should
>>> be mentioned in the RFC.
>>>
>>> The example is not in sync with the IANA registry and has to be updated.
>>>
>>> > If the intention is to use SHA512/256 as described in FIPS 180.4 then
>>> this should be mentioned, and the values changed to
>>> userhash="793263caabb707a56211940d90411ea4a575adeccb7e360aeb624ed06ece9b0b"
>>> and response="3798d4131c277846293534c3edc11bd8a5e4cdcbff78b05db9
>>> d95eeb1cec68a5"
>>>
>>> I will look into your provided values and clarify/correct the example.
>>>
>>> Once again, thank you for this catch!
>>>
>>> Best Regards,
>>> Sophie
>>>
>>
>>
>
> _______________________________________________
> http-auth mailing list
> http-auth@ietf.org
> https://www.ietf.org/mailman/listinfo/http-auth
>
>