Re: Optimize scram_SaltedPassword performance

On Mon, Feb 03, 2025 at 12:17:27PM +0100, Daniel Gustafsson wrote:
> The numbers are quite outdated but the gist of it holds. If we speed it up
> serverside we need to counter that with a higher iteration count, and for a
> rogue client it's unlikely to matter since it wont use our code anyways.
> Speeding up HMAC for other usecases is a different story (but also likely to
> have less measurable performance impact).

Thanks, I've managed to somewhat forget this point. Note that this
has come up as well when adding the GUC scram_iterations in
b577743000cd, where a lower count can be used for a faster connection.

> Storing any part of a cryptograhic calculation, let alone a key, in a static
> variable doesn't seem entirely like a best practice, and it also wont be
> threadsafe.

Agreed.

By the way, something I have forgotten to mention yesterday.. If a
fast-path gets implemented in these HMAC APIs (perhaps not), it sounds
to me that it would be better to achieve the same for the fallback
non-OpenSSL implementation in src/common/hmac.c, as it would reflect
things properly in the interface. My 2c.
--
Michael