Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 19 Jul 2023 09:33:47 -0400
From: Jeffrey Walton <>
Cc:, Matt Caswell <>
Subject: Re: OpenSSL Security Advisory

On Wed, Jul 19, 2023 at 7:38 AM Tomas Mraz <> wrote:
> Hash: SHA256
> OpenSSL Security Advisory [19th July 2023]
> ==========================================
> Excessive time spent checking DH keys and parameters (CVE-2023-3446)
> ====================================================================
> Severity: Low
> Issue summary: Checking excessively long DH keys or parameters may be very slow.
> Impact summary: Applications that use the functions DH_check(), DH_check_ex()
> or EVP_PKEY_param_check() to check a DH key or DH parameters may experience long
> delays. Where the key or parameters that are being checked have been obtained
> from an untrusted source this may lead to a Denial of Service.
> The function DH_check() performs various checks on DH parameters. One of those
> checks confirms that the modulus ("p" parameter) is not too large. Trying to use
> a very large modulus is slow and OpenSSL will not normally use a modulus which
> is over 10,000 bits in length.
> However the DH_check() function checks numerous aspects of the key or parameters
> that have been supplied. Some of those checks use the supplied modulus value
> even if it has already been found to be too large.
> An application that calls DH_check() and supplies a key or parameters obtained
> from an untrusted source could be vulnerable to a Denial of Service attack.
> The function DH_check() is itself called by a number of other OpenSSL functions.
> An application calling any of those other functions may similarly be affected.
> The other functions affected by this are DH_check_ex() and
> EVP_PKEY_param_check().
> Also vulnerable are the OpenSSL dhparam and pkeyparam command line applications
> when using the "-check" option.
> [...]

It is not clear (to me) what the actual issue being flagged is.

Whenever an application receives security parameters from an untrusted
source, the parameters must be validated. You never apply a
transformation to a message using key material that has not been
validated. So calling DH_check() and friends on untrusted DH
parameters is perfectly reasonable. In fact, if untrusted parameters
are not validated, then I would consider that a security bug.

I guess that leaves calling DH_check() multiple times on the same
[untrusted] parameters? Or maybe calling DH_check() on trusted
parameters generated by the program itself? Or maybe something else?

Another possibility is, OpenSSL should reject parameters if the prime
field is too large, for some definition of "too large". In this case,
I would argue it is _not_ OpenSSL's place to make that decision.
That's a policy decision that must be made by the application using
the OpenSSL library. In this case, maybe OpenSSL needs a configuration
parameter or user API to reject prime fields larger than a certain
size, like 4096- or 8192-bits.


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.