Red Hat Bugzilla – 2136492 – In FIPS mode, libgcrypt PBKDF2 should not limit input passphrase size and should limit gcry_md_setkey() size when used for HMAC
Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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 1919259[details]
gcry_hmac with both the gcry_mac and the gcry_md API
Description of problem:
libgcrypt fails ACVP testing for PBKDF2 because it rejects short passphrases. See https://dev.gnupg.org/T6039#164435 and https://dev.gnupg.org/rC857e6f467d0fc9fd858a73d84122695425970075.
libgcrypt also fails to impose a lower bound for the HMAC key size of 14 bytes when HMAC is computed using the gcry_md_open/gcry_md_setkey/gcry_md_write/gcry_md_read APIs. The limit is correctly enforced when using gcry_mac_open/gcry_mac_setkey/gcry_mac_write/gcry_mac_read.
Version-Release number of selected component (if applicable):
1.10.0-7.el9_0 (!)
How reproducible:
- Run ACVP testing (or perform PBKDF2 with an 8-byte passphrase)
- Run the attached reproducer with less than 14 bytes of keylength
Steps to Reproduce:
1. Enable FIPS mode
2. cc -std=c99 -Wall -Werror -pedantic -D_XOPEN_SOURCE=600 -o gcry_hmac gcry_hmac.c -lgcrypt
3. ./gcry_hmac 14 inputstring
4. ./gcry_hmac 13 inputstring
Actual results:
./gcry_hmac 14 works both with the gcry_mac API and the gcry_md API
./gcry_hmac 13 does not work with the gcry_mac API but works with the gcry_md API
Expected results:
./gcry_hmac 14 works both with the gcry_mac API and the gcry_md API
./gcry_hmac 13 does not work with neither the gcry_mac API nor the gcry_md API
Additional info:
Note that from what I could see, hmac_setkey() calls _gcry_md_setkey(), so this could probably be achieved by moving the length check into _gcry_md_setkey().
Additionally, when I run the same test with LIBGCRYPT_FORCE_FIPS_MODE=1 on f36 (libgcrypt-1.10.1-3.fc36), both gcry_mac_setkey() and gcry_md_setkey() fail correctly with 13 bytes or less.
The https://dev.gnupg.org/T6039 explains the reasons why the check was moved from prepare_macpads() to gcry_mac_setkey() in visibility.c as they wanted to allow internal use, which sounds reasonable.
To avoid any side effects of moving this check, I would probably propose to write the same check we have in gcry_mac_setkey() into the gcry_md_setkey(). I will comment with the proposed patch in the above upstream bug.