On Mon, Feb 19, 2018 at 08:43:44AM -0500, Peter Eisentraut wrote:
> I also noticed while working on some SSL code that we have perfectly
> good SHA-2 functionality in the server already, but it has no test
> coverage outside the SCRAM tests.
Yep, the refactoring in src/common/ has been done for SCRAM. As The
first versions of the patch were for SCRAM-SHA-1, only SHA-1 functions
were moved. With SCRAM-SHA-256, the full set of APIs for 256, 386 and
512 has been moved as they share much code.
> So I suggest these patches that expose the new functions sha224(),
> sha256(), sha384(), sha512(). That allows us to make the SSL and SCRAM
> tests more robust, and it will allow them to be used in general purpose
> contexts over md5().
Huge +1 as well. This also makes sure that the non-SSL implementation
carried in Postgres is consistent what what OpenSSL has. This would
matter as well if new SSL implementations are added in the future.
+ <entry><literal>sha224('abc')</literal></entry>
+ <entry><literal>\x23097d223405d8228642a477bda255b32aadbce4bda0b3f7e36c9da7</literal></entry>
Some bytea characters from the hash are not able to show up correctly?
This does not result in spaces.
+ Note that for historic reasons, the function <function>md5</function>
+ returns a hex-encoded value of type <type>text</type> whereas the SHA-2
+ functions return type <type>bytea</type>. Use the functions
+ <function>encode</function> and <function>decode</function> to convert
+ between the two.
Adding an example would be nice.
varlena.c is already large and messy. I would suggest to split into a
new file all the user-facing cryptographic functions, including md5 and
hex functions, say in src/backend/utils/adt/crypt.c.
--
Michael