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
signature.asc
Description: PGP signature
