Re: Refactor SCRAM code to dynamically handle hash type and key length

On Wed, Dec 14, 2022 at 02:39:43PM +0100, Peter Eisentraut wrote:
> On 14.12.22 03:38, Michael Paquier wrote:
>> While investigating on what it would take to extend SCRAM to use new
>> hash methods (say like the RFC draft for SCRAM-SHA-512), I have been
>> quickly reminded of the limitations created by SCRAM_KEY_LEN, which is
>> the key length that we use in the HMAC and hash computations when
>> creating a SCRAM verifier or when doing a SASL exchange.
>
> then the obvious fix there is to change the definition of SCRAM_KEY_LEN to
> PG_SHA512_DIGEST_LENGTH, which would be a much smaller and simpler change.
> We don't have to support arbitrary key sizes, so a fixed-size array seems
> appropriate.

Yeah, I was considering doing that as well for the static arrays, with
something like a Max() to combine but perhaps that's not necessary for
the digest lengths anyway. Perhaps I just over-engineered the
approach.

However, that's only half of the picture. The key length and the hash
type (or just the hash type to know what's the digest/key length to
use but that's more invasive) still need to be sent across the
internal routines of SCRAM and attached to the state data of the
frontend and the backend or we won't be able to do the hash and HMAC
computations dependent on that.
--
Michael