On Thu, Dec 17, 2020 at 12:10:22PM -0500, Bruce Momjian wrote: > On Thu, Dec 17, 2020 at 11:39:55AM -0500, Stephen Frost wrote: >> I don't think there's any need for us to implement a fallback >> implementation of AES. I'm not entirely sure we need it for hashes >> but since we've already got it...
We need fallback implementations for cryptohashes (MD5, SHA1/2) and HMAC because we have SCRAM authentication, pgcrypto and SQL functions that should be able to work even when not building with any SSL libraries. So that's here to stay to ensure compatibility with what we do. All this stuff is already in the tree for ages, it was just not shaped for a more centralized reuse. > Agreed. I think there is serious risk we would do AES in a different > way than OpenSSL, especially if I did it. ;-) We can add a native AES > one day if we want, but as stated by Michael Paquier, it has to be > tested so we are sure it returns exactly the same values as OpenSSL. I think that it would be good to put some generalization here, and look at options that are offered by other SSL libraries, like libnss so as we don't finish with a design that restricts the use of a given feature only to OpenSSL. -- Michael
signature.asc
Description: PGP signature
