Обсуждение: Adding deprecation notices to pgcrypto documentation

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?

--
Daniel Gustafsson

[0] https://postgr.es/m/2825088.1696539339@sss.pgh.pa.us

> 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

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] (commit d6464fd).  If there are
still objections to removing it, I think it should at least be given its
decennial update.

[0] https://postgr.es/m/CAPVvHdPj5rmf294FbWi2TuEy%3DhSxZMNjTURESaM5zY8P_wCJMg%40mail.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]:

    "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

[0]
https://web.archive.org/web/20161202063854/https://www.computerworld.com.au/article/46254/bruce_almighty_schneier_preaches_security_linux_faithful/?pp=3