Adding deprecation notices to pgcrypto documentation
In the "Allow tests to pass in OpenSSL FIPS mode" thread [0]/messages/by-id/2825088.1696539339@sss.pgh.pa.us it was discovered
that 3DES is joining the ranks of NIST disallowed algorithms. The attached
patch adds a small note to the pgcrypto documentation about deprecated uses of
algorithms. I've kept it to "official" notices such as RFC's and NIST SP's.
There might be more that deserve a notice, but this seemed like a good start.
Any thoughts on whether this would be helpful?
--
Daniel Gustafsson
Attachments:
pgcrypto_disallow_v2.diffapplication/octet-stream; name=pgcrypto_disallow_v2.diff; x-unix-mode=0644Download
diff --git a/doc/src/sgml/pgcrypto.sgml b/doc/src/sgml/pgcrypto.sgml
index 2e29f1d6f7..dae9cf0ee7 100644
--- a/doc/src/sgml/pgcrypto.sgml
+++ b/doc/src/sgml/pgcrypto.sgml
@@ -1221,6 +1221,34 @@ gen_random_uuid() returns uuid
</para>
</sect3>
+ <sect3 id="pgcrypto-notes-disallowed">
+ <title>Deprecated Algorithms</title>
+
+ <para>
+ <filename>pgcrypto</filename> supports a number of algorithms which are
+ known to be vulnerable to attacks, and are widely advised against be used
+ for new applications.
+ </para>
+ <para>
+ DES and 3DES cipher algorithms, are listed as disallowed for encryption in
+ <ulink url="https://doi.org/10.6028/NIST.SP.800-131Ar2">NIST SP800-131A</ulink>.
+ In order to be compliant with NIST guidelines, these algorithms should
+ only be used for decryption of already encrypted data.
+ </para>
+ <para>
+ <ulink url="https://datatracker.ietf.org/doc/html/rfc6151">RFC6151</ulink>
+ documents why MD5 should not be used for digital signatures.
+ </para>
+ <para>
+ SHA-1 was deprecated for digital signature generation in
+ <ulink url="https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-107r1.pdf">
+ NIST SP800-107</ulink> and later disallowed in
+ <ulink url="https://doi.org/10.6028/NIST.SP.800-131Ar2">NIST SP800-131A</ulink>.
+ In order to be compliant with NIST guidelines, SHA-1 should only be used
+ for validating digital signatures.
+ </para>
+ </sect3>
+
<sect3 id="pgcrypto-notes-useful-reading">
<title>Useful Reading</title>
On 16 Nov 2023, at 21:49, Daniel Gustafsson <daniel@yesql.se> wrote:
In the "Allow tests to pass in OpenSSL FIPS mode" thread [0] it was discovered
that 3DES is joining the ranks of NIST disallowed algorithms. The attached
patch adds a small note to the pgcrypto documentation about deprecated uses of
algorithms. I've kept it to "official" notices such as RFC's and NIST SP's.
There might be more that deserve a notice, but this seemed like a good start.Any thoughts on whether this would be helpful?
Cleaning out my inbox I came across this which I still think is worth doing,
any objections to going ahead with it?
--
Daniel Gustafsson
On Mon, Mar 04, 2024 at 10:03:13PM +0100, Daniel Gustafsson wrote:
Cleaning out my inbox I came across this which I still think is worth doing,
any objections to going ahead with it?
I think the general idea is reasonable, but I have two small comments:
* Should this be a "Warning" and/or moved to the top of the page? This
seems like a relatively important notice that folks should see when
beginning to use pgcrypto.
* Should we actually document the exact list of algorithms along with
detailed reasons? This list seems prone to becoming outdated.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On 4 Mar 2024, at 23:49, Nathan Bossart <nathandbossart@gmail.com> wrote:
On Mon, Mar 04, 2024 at 10:03:13PM +0100, Daniel Gustafsson wrote:
Cleaning out my inbox I came across this which I still think is worth doing,
any objections to going ahead with it?I think the general idea is reasonable, but I have two small comments:
* Should this be a "Warning" and/or moved to the top of the page? This
seems like a relatively important notice that folks should see when
beginning to use pgcrypto.
Good question. If we do we'd probably need to move other equally important
bits of information from "Security Limitations" as well so perhaps it's best to
keep it as is for now, or putting it under Notes.
* Should we actually document the exact list of algorithms along with
detailed reasons? This list seems prone to becoming outdated.
If we don't detail the list then I think that it's not worth doing, doing the
research isn't entirely trivial as one might not even know where to look or
what to look for.
I don't think this list will move faster than we can keep up with it,
especially since it's more or less listing everything that pgcrypto supports at
this point.
Looking at this some more I propose that we also remove the table of hash
benchmarks, as it's widely misleading. Modern hardware can generate far more
than what we list here, and it gives the impression that these algorithms can
only be broken with brute force which is untrue. The table was first published
in 2008 and hasn't been updated since.
Attached is an updated patchset.
--
Daniel Gustafsson
Attachments:
v3-0002-pgcrypto-Document-deprecation-notices-against-alg.patchapplication/octet-stream; name=v3-0002-pgcrypto-Document-deprecation-notices-against-alg.patch; x-unix-mode=0644Download
From c6e7e28de5dbd181d17332852c3b85604fc0aef1 Mon Sep 17 00:00:00 2001
From: Daniel Gustafsson <dgustafsson@postgresql.org>
Date: Tue, 5 Mar 2024 11:32:11 +0100
Subject: [PATCH v3 2/2] pgcrypto: Document deprecation notices against
algorithms
Many of the algorithms supported by pgcrypto have since pgcrypto was
first included been deprecated and/or found to be vulnerable. List
deprecation notices and links to further reading to inform our users
about the available algorithms.
Discussion: https://postgr.es/m/29070C1D-9E91-47FB-9250-C5135FA269BC@yesql.se
---
doc/src/sgml/pgcrypto.sgml | 33 +++++++++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/doc/src/sgml/pgcrypto.sgml b/doc/src/sgml/pgcrypto.sgml
index e66d60878f..d0bbb20bc8 100644
--- a/doc/src/sgml/pgcrypto.sgml
+++ b/doc/src/sgml/pgcrypto.sgml
@@ -1086,6 +1086,39 @@ gen_random_uuid() returns uuid
ciphertexts of a given size.
</para>
</sect3>
+
+ <sect3 id="pgcrypto-notes-disallowed">
+ <title>Deprecated Algorithms</title>
+
+ <para>
+ <filename>pgcrypto</filename> supports a number of algorithms which are
+ known to be vulnerable to attacks, and are widely advised against to be
+ used for new applications.
+ </para>
+ <para>
+ DES and 3DES cipher algorithms, are listed as disallowed for encryption in
+ <ulink url="https://doi.org/10.6028/NIST.SP.800-131Ar2">NIST SP800-131A</ulink>.
+ In order to be compliant with NIST guidelines, these algorithms should
+ only be used for decryption of already encrypted data.
+ </para>
+ <para>
+ <ulink url="https://datatracker.ietf.org/doc/html/rfc6151">RFC6151</ulink>
+ documents why MD5 should not be used for digital signatures.
+ </para>
+ <para>
+ Blowfish is vulnerable to the <ulink url="https://sweet32.info/">SWEET32</ulink>
+ birthday attack and is adviced against for new applications.
+ </para>
+ <para>
+ SHA-1 was deprecated for digital signature generation in
+ <ulink url="https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-107r1.pdf">
+ NIST SP800-107</ulink> and later disallowed in
+ <ulink url="https://doi.org/10.6028/NIST.SP.800-131Ar2">NIST SP800-131A</ulink>.
+ In order to be compliant with NIST guidelines, SHA-1 should only be used
+ for validating digital signatures.
+ </para>
+ </sect3>
+
</sect2>
<sect2 id="pgcrypto-author">
--
2.32.1 (Apple Git-133)
v3-0001-pgcrypto-Remove-hash-speed-comparison-table.patchapplication/octet-stream; name=v3-0001-pgcrypto-Remove-hash-speed-comparison-table.patch; x-unix-mode=0644Download
From f752214db776a52a0e6ba635c7c50d869807fafb Mon Sep 17 00:00:00 2001
From: Daniel Gustafsson <dgustafsson@postgresql.org>
Date: Tue, 5 Mar 2024 11:28:31 +0100
Subject: [PATCH v3 1/2] pgcrypto: Remove hash speed comparison table
The table comparing relative hash speed is at best misleading, and
at worst misinforming. The benchmarks are old and do not reflect
the current state of the art. The table also imply security due to
brute-force protection, which is no longer true for many algorithms
which have published vulnerabilities which avoid the need for brute
force.
---
doc/src/sgml/pgcrypto.sgml | 134 -------------------------------------
1 file changed, 134 deletions(-)
diff --git a/doc/src/sgml/pgcrypto.sgml b/doc/src/sgml/pgcrypto.sgml
index 2db159be71..e66d60878f 100644
--- a/doc/src/sgml/pgcrypto.sgml
+++ b/doc/src/sgml/pgcrypto.sgml
@@ -300,140 +300,6 @@ gen_salt(type text [, iter_count integer ]) returns text
Slower than 4 hashes per second would probably dampen usability.
Faster than 100 hashes per second is probably too fast.
</para>
-
- <para>
- <xref linkend="pgcrypto-hash-speed-table"/> gives an overview of the relative slowness
- of different hashing algorithms.
- The table shows how much time it would take to try all
- combinations of characters in an 8-character password, assuming
- that the password contains either only lower case letters, or
- upper- and lower-case letters and numbers.
- In the <literal>crypt-bf</literal> entries, the number after a slash is
- the <parameter>iter_count</parameter> parameter of
- <function>gen_salt</function>.
- </para>
-
- <table id="pgcrypto-hash-speed-table">
- <title>Hash Algorithm Speeds</title>
- <tgroup cols="5">
- <thead>
- <row>
- <entry>Algorithm</entry>
- <entry>Hashes/sec</entry>
- <entry>For <literal>[a-z]</literal></entry>
- <entry>For <literal>[A-Za-z0-9]</literal></entry>
- <entry>Duration relative to <literal>md5 hash</literal></entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry><literal>crypt-bf/8</literal></entry>
- <entry>1792</entry>
- <entry>4 years</entry>
- <entry>3927 years</entry>
- <entry>100k</entry>
- </row>
- <row>
- <entry><literal>crypt-bf/7</literal></entry>
- <entry>3648</entry>
- <entry>2 years</entry>
- <entry>1929 years</entry>
- <entry>50k</entry>
- </row>
- <row>
- <entry><literal>crypt-bf/6</literal></entry>
- <entry>7168</entry>
- <entry>1 year</entry>
- <entry>982 years</entry>
- <entry>25k</entry>
- </row>
- <row>
- <entry><literal>crypt-bf/5</literal></entry>
- <entry>13504</entry>
- <entry>188 days</entry>
- <entry>521 years</entry>
- <entry>12.5k</entry>
- </row>
- <row>
- <entry><literal>crypt-md5</literal></entry>
- <entry>171584</entry>
- <entry>15 days</entry>
- <entry>41 years</entry>
- <entry>1k</entry>
- </row>
- <row>
- <entry><literal>crypt-des</literal></entry>
- <entry>23221568</entry>
- <entry>157.5 minutes</entry>
- <entry>108 days</entry>
- <entry>7</entry>
- </row>
- <row>
- <entry><literal>sha1</literal></entry>
- <entry>37774272</entry>
- <entry>90 minutes</entry>
- <entry>68 days</entry>
- <entry>4</entry>
- </row>
- <row>
- <entry><literal>md5</literal> (hash)</entry>
- <entry>150085504</entry>
- <entry>22.5 minutes</entry>
- <entry>17 days</entry>
- <entry>1</entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- Notes:
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- The machine used is an Intel Mobile Core i3.
- </para>
- </listitem>
- <listitem>
- <para>
- <literal>crypt-des</literal> and <literal>crypt-md5</literal> algorithm numbers are
- taken from John the Ripper v1.6.38 <literal>-test</literal> output.
- </para>
- </listitem>
- <listitem>
- <para>
- <literal>md5 hash</literal> numbers are from mdcrack 1.2.
- </para>
- </listitem>
- <listitem>
- <para>
- <literal>sha1</literal> numbers are from lcrack-20031130-beta.
- </para>
- </listitem>
- <listitem>
- <para>
- <literal>crypt-bf</literal> numbers are taken using a simple program that
- loops over 1000 8-character passwords. That way the speed
- with different numbers of iterations can be shown. For reference: <literal>john
- -test</literal> shows 13506 loops/sec for <literal>crypt-bf/5</literal>.
- (The very small
- difference in results is in accordance with the fact that the
- <literal>crypt-bf</literal> implementation in <filename>pgcrypto</filename>
- is the same one used in John the Ripper.)
- </para>
- </listitem>
- </itemizedlist>
-
- <para>
- Note that <quote>try all combinations</quote> is not a realistic exercise.
- Usually password cracking is done with the help of dictionaries, which
- contain both regular words and various mutations of them. So, even
- somewhat word-like passwords could be cracked much faster than the above
- numbers suggest, while a 6-character non-word-like password may escape
- cracking. Or not.
- </para>
</sect3>
</sect2>
--
2.32.1 (Apple Git-133)
On Tue, Mar 05, 2024 at 11:50:36AM +0100, Daniel Gustafsson wrote:
On 4 Mar 2024, at 23:49, Nathan Bossart <nathandbossart@gmail.com> wrote:
* Should this be a "Warning" and/or moved to the top of the page? This
seems like a relatively important notice that folks should see when
beginning to use pgcrypto.Good question. If we do we'd probably need to move other equally important
bits of information from "Security Limitations" as well so perhaps it's best to
keep it as is for now, or putting it under Notes.
Fair point.
* Should we actually document the exact list of algorithms along with
detailed reasons? This list seems prone to becoming outdated.If we don't detail the list then I think that it's not worth doing, doing the
research isn't entirely trivial as one might not even know where to look or
what to look for.I don't think this list will move faster than we can keep up with it,
especially since it's more or less listing everything that pgcrypto supports at
this point.
Also fair. Would updates to this list be back-patched?
Looking at this some more I propose that we also remove the table of hash
benchmarks, as it's widely misleading. Modern hardware can generate far more
than what we list here, and it gives the impression that these algorithms can
only be broken with brute force which is untrue. The table was first published
in 2008 and hasn't been updated since.
It looks like it was updated in 2013 [0]/messages/by-id/CAPVvHdPj5rmf294FbWi2TuEy=hSxZMNjTURESaM5zY8P_wCJMg@mail.gmail.com (commit d6464fd). If there are
still objections to removing it, I think it should at least be given its
decennial update.
[0]: /messages/by-id/CAPVvHdPj5rmf294FbWi2TuEy=hSxZMNjTURESaM5zY8P_wCJMg@mail.gmail.com
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On 05.03.24 11:50, Daniel Gustafsson wrote:
* Should we actually document the exact list of algorithms along with
detailed reasons? This list seems prone to becoming outdated.If we don't detail the list then I think that it's not worth doing, doing the
research isn't entirely trivial as one might not even know where to look or
what to look for.I don't think this list will move faster than we can keep up with it,
especially since it's more or less listing everything that pgcrypto supports at
this point.
The more detail we provide, the more detailed questions can be asked
about it. Like:
The introduction says certain algorithms are vulnerable to attacks. Is
3DES vulnerable to attacks? Or just deprecated?
What about something like CAST5? This is in the OpenSSL legacy
provider, but I don't think it's know to be vulnerable. Is its status
different from 3DES?
It says MD5 should not be used for digital signatures. But is password
hashing a digital signature? How are these related? Similarly about
SHA-1, which has a different level of detail.
Blowfish is advised against, but by whom? By us?
On 6 Mar 2024, at 10:57, Peter Eisentraut <peter@eisentraut.org> wrote:
On 05.03.24 11:50, Daniel Gustafsson wrote:
* Should we actually document the exact list of algorithms along with
detailed reasons? This list seems prone to becoming outdated.If we don't detail the list then I think that it's not worth doing, doing the
research isn't entirely trivial as one might not even know where to look or
what to look for.
I don't think this list will move faster than we can keep up with it,
especially since it's more or less listing everything that pgcrypto supports at
this point.The more detail we provide, the more detailed questions can be asked about it.
To make it more palatable then, let's remove everything apart from the NIST
recommendations?
The introduction says certain algorithms are vulnerable to attacks. Is 3DES vulnerable to attacks? Or just deprecated?
Both, 3DES in CBC mode is vulnerable to birthday attacks (CVE-2016-2183) and is
disallowed for encryption (NIST-SP800-131A) after 2023.
What about something like CAST5? This is in the OpenSSL legacy provider, but I don't think it's know to be vulnerable. Is its status different from 3DES?
CAST is vulnerable but CAST5, which is another name for CAST-128, is not known
to be vulnerable as long as a 128 bit key is used (which is what pgcrypto use).
It is AFAIK considered a legacy cipher due to the small block size.
It says MD5 should not be used for digital signatures. But is password hashing a digital signature? How are these related? Similarly about SHA-1, which has a different level of detail.
A digital signature is a mathematical construction to verify the authenticity
of a message, so I guess password hashing falls under that. The fact that MD5
is vulnerable to collision attacks makes MD5 a particularly poor choice for
that particular application IMO.
Blowfish is advised against, but by whom? By us?
Blowfish in CBC mode is vulnerable to birthday attacks (CVE-2016-6329). The
author of Blowfish among others, he had this to say in 2007 [0]https://web.archive.org/web/20161202063854/https://www.computerworld.com.au/article/46254/bruce_almighty_schneier_preaches_security_linux_faithful/?pp=3:
"There weren't enough alternatives to DES out there. I wrote Blowfish
as such an alternative, but I didn't even know if it would survive a
year of cryptanalysis. Writing encryption algorithms is hard, and it's
always amazing if one you write actually turns out to be secure. At
this point, though, I'm amazed it's still being used. If people ask, I
recommend Twofish instead."
--
Daniel Gustafsson