Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Daniel Gustafsson <daniel@yesql.se>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-11-13T03:14:29Z
Lists: pgsql-hackers
Attachments
- v4-0001-Rework-SHA2-and-crypto-hash-APIs.patch (text/x-diff) patch v4-0001
- v4-0002-Switch-cryptohash_openssl.c-to-use-EVP.patch (text/x-diff) patch v4-0002
- v4-0003-Move-pgcrypto-to-use-in-core-resowner-facility-fo.patch (text/x-diff) patch v4-0003
On Thu, Nov 05, 2020 at 03:41:23PM +0900, Michael Paquier wrote: > This conflicted on HEAD with pgcrypto. Please find attached a rebased > set. I got to think more about this stuff and attached is a new patch set that redesigns the generic interface used for the crypto hash functions, in order to use the same entry point at the end for SHA2, SHA1, MD5 or even HMAC. This is part of 0001: - Introduction of a single file called cryptohash[_openssl].c, which includes five functions to create, initialize, update, finalize and free a crypto hash context. The attached does the work for SHA2. - The fallback implementations are in their own file in src/common/, and get included in cryptohash.c. cryptohash_openssl.c is much more simple as it needs to use EVP for everything. - Adding a new crypto function in the set is simple once this is done, as a type needs to be added with the correct options plugged in. 0002 and 0003 don't have any changes. I think that we could also rename the existing cryptohashes.c to crypohashfuncs.c to be more consistent, but I have left that out for now. -- Michael
Commits
-
Change SHA2 implementation based on OpenSSL to use EVP digest routines
- 4f48a6fbe2b2 14.0 landed
- e21cbb4b893b 14.0 landed
-
Move SHA2 routines to a new generic API layer for crypto hashes
- 87ae9691d253 14.0 landed
-
Use OpenSSL EVP API for symmetric encryption in pgcrypto.
- 5ff4a67f63fd 10.0 cited