Re: Optimize scram_SaltedPassword performance

I initially intended to restrict the modification to the
scram_SaltedPassword(), but I'm unsure how to determine
whether the current implementation is OpenSSL.

Alternatively, could we modify pg_hmac_init() to allow `key=NULL`
in the native HMAC implementation, achieving semantics similar to
OpenSSL? However, without carefully designing the logic for reusing
the context, the performance difference would be minimal. In my tests,
I skipped the initialization of `i_pad` and `o_pad` when `key=NULL`,
but the execution time remained around 10ms. That said, we can avoid
using the pg_hmac_reuse(), though we may need to add additional
explanations in the comments of pg_hmac_init().

--

regards,
Zixuan

On Mon, Feb 3, 2025 at 4:16 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Mon, Feb 03, 2025 at 03:11:48PM +0800, Zixuan Fu wrote:
> > With this change, the performance improves by approximately **4x** (reducing
> > execution time from 4ms to 1ms). The built-in PostgreSQL HMAC implementation
> > does not support context reuse, and modifying it would require substantial
> > changes. Therefore, `pg_hmac_reuse()` simply calls `pg_hmac_init()` in that
> > case, maintaining the existing logic.
>
> I suspect that keeping an interface like pg_hmac_reuse() is going to
> encourage incorrect practices in the long term, for a behavior that's
> hidden in OpenSSL itself. In short, while I agree that the
> performance could be better based on the information you are providing
> (did not test nor check OpenSSL across the branches we support), your
> proposal to address the problem makes me wonder that we'd better limit
> this change localized into scram_SaltedPassword() rather than increase
> the footprint of the APIs in the two HMAC-specific files of
> src/common/.
> --
> Michael