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

[Chaim Geretz <[e-mail]>]

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 <[e-mail]> 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 <
> [e-mail]> 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 <[e-mail]>:
>> >
>> > 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
>>
>
>