RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Created attachment 1919136 [details]
reproducer that computes an HMAC using EVP_Q_mac() with a user-defined key length

Description of problem:
According to NIST Special Publication 800-131Ar2, Table 9: Approval Status of MAC Algorithms, key lengths < 112 bytes are disallowed for HMAC generation.

OpenSSL should either reject shorter keys with an error message, or provide an explicit indication that short keys are not FIPS-approved.

Version-Release number of selected component (if applicable):
3.0.1-41.el9_0

How reproducible:
Run the attached reproducer with values other than the permitted ones.

Steps to Reproduce:
1. gcc -std=c99 -Wall -Werror -pedantic -o hmac hmac.c -lcrypto
2. ./hmac 2 foo

Actual results:
e554d415b4a2c69a6afa1d8b154bcd89bba6371d5f6c5ebdcbc356096ce1cfc6 (or some other HMAC, the key is randomly generated)

Expected results:
Failure because a short key was used.

Additional info:

Correcting myself: it's key lengths < 112 bits, not bytes.

I'm attaching an updated reproducer that uses and EVP_MAC_CTX and also supports reading and printing the indicator status from that context.

I tested that this indicator correctly identifies short keys:

  $> $(head -n1 hmac.c | sed -E 's#^// ##g') && echo "" | ./hmac 14
  OK (indicator: approved): 24dce023336611b9485adf35c9cd9c1686db0eecab76aa1c9fbb1a4ccfe883c9
  $> $(head -n1 hmac.c | sed -E 's#^// ##g') && echo "" | ./hmac 13
  OK (indicator: unapproved): aaf492fa7114fcb1880d0906077e7f3f7cdb74fecbd787bc6cc93bc7df9ede04

Created attachment 1925084 [details]
Updated reproducer that uses EVP_MAC_CTX and supports indicators

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Low: openssl security and bug fix update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2023:2523