Horton

Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2

Daniel Gustafsson <daniel@yesql.se>

View thread View on postgr.es
From: Daniel Gustafsson <daniel@yesql.se>
To: Michael Paquier <michael@paquier.xyz>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Tom Lane <tgl@sss.pgh.pa.us>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-11-30T13:29:29Z
Lists: pgsql-hackers 
> On 30 Nov 2020, at 14:13, Michael Paquier <michael@paquier.xyz> wrote:
> On Mon, Nov 30, 2020 at 01:43:24PM +0100, Daniel Gustafsson wrote:

>> Since the cryptohash support is now generalized behind an abstraction layer,
>> wouldn't it make sense to roll the resource ownership there as well kind of
>> like how JIT is handled?  It would make it easier to implement TLS backend
>> support, and we won't have to inject OpenSSL headers here.
> 
> So, you are referring here about using a new API in the abstraction
> layer.  This makes sense.  What about naming that
> pg_cryptohash_context_free(void *)?

Yeah, that's along the lines of what I was thinking of.

cheers ./daniel

Commits

  1. Change SHA2 implementation based on OpenSSL to use EVP digest routines

  2. Move SHA2 routines to a new generic API layer for crypto hashes

  3. Use OpenSSL EVP API for symmetric encryption in pgcrypto.