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 <mich...@paquier.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
