CVE-2024-54137 - How a Critical Indexing Bug in liboqs’ HQC KEM Could Break Shared Secrets

tl;dr
A serious bug in the C-language liboqs post-quantum crypto library (used for quantum-resistant crypto) caused secret key parts to be handled like non-secret data in the HQC KEM algorithm. Mess with the ciphertext, and callers could get the wrong shared secret. Here’s how it worked, why it’s serious, and what the fix looks like.

What is liboqs and HQC?

liboqs is a popular C cryptography library aimed at making systems resistant to quantum attacks. It provides lots of new “post-quantum” algorithms, including HQC, a Key Encapsulation Mechanism (KEM) for key exchange.

- liboqs on GitHub
- HQC KEM details (IACR Paper)

About the Vulnerability

CVE-2024-54137 is a *correctness error* found in how liboqs implemented HQC KEM’s secret key handling.

There’s a function to recover a shared secret from a ciphertext and your own secret key:

int OQS_KEM_hqc_decaps(uint8_t *shared_secret, const uint8_t *ciphertext, const uint8_t *secret_key);
- If the input ciphertext is malformed, *part of the secret key* gets read using the wrong index (due to miscalculation or a typo), and that data ends up in the wrong place.
- This “leak” means the decapsulation process could return an *incorrect* shared secret, opening up the chance for protocol failures or attacks.

Reference Code (Vulnerable)

Below is a simplified version of the problematic decapsulation area in HQC as originally implemented:

// Assume secret_key = [sk_seed | pk | random_bytes]
void HQC_decaps(uint8_t *ss, const uint8_t *ct, const uint8_t *sk) {
    // ... lots of crypto code ...
    if (hqc_decrypt_ok) {
        // shared secret is derived as expected
        derive_ss(ss, ct, sk);
    } else {
        // If decryption fails, use part of sk to generate ss
        memcpy(ss, sk + (sk_offset), SHARED_SECRET_BYTES);
    }
}

The bug:
Here, sk_offset could point into a *public* section, or be off-by-one (or more), leading to incorrect data being used for the shared secret.

Suppose Alice and Bob use HQC KEM in liboqs (pre v.12.)

1. Attacker Mallory sends a *malformed ciphertext* to Alice, perhaps flipping a bit or truncating it.

Alice calls decaps and expects a correct, securely derived shared secret.

3. But: Due to the indexing bug, Alice’s implementation might produce a predictable or invalid “shared secret”—based on part of her secret key that’s not meant to be used this way.

Break forward secrecy if protocols rely on correct outputs even after decryption failure.

Note: This is a correctness bug, not a direct key leak. But it opens the door to *side-channel* issues, protocol failures, and potential security bypasses.

Here's a conceptual code snippet

// Pseudo-code for demonstrating the bug
uint8_t fake_ct[HQC_CIPHERTEXT_BYTES] = {}; // Malformed
uint8_t bad_ss[HQC_SHARED_SECRET_BYTES] = {};

// Assume sk is generated with liboqs
OQS_KEM_hqc_decaps(bad_ss, fake_ct, sk);
printf("Broken shared secret is: ");
for (int i = ; i < HQC_SHARED_SECRET_BYTES; i++)
    printf("%02x", bad_ss[i]);
printf("\n");

Result:
bad_ss could contain bytes from the wrong section of the secret key.

The Proper Fix

In liboqs v.12., the bug was patched:

// new: always uses dedicated random_bytes section properly
if (hqc_decrypt_ok) {
    derive_ss(ss, ct, sk);
} else {
    memcpy(ss, sk + correct_offset, SHARED_SECRET_BYTES);
}

The developers adjusted the correct_offset logic to use only the intended (truly secret) segment.

- Release note: liboqs .12. changelog
- Fix commit diff: GitHub commit

Should You Worry?

If you depend on liboqs and HQC before v.12.:

*Update right now.*

- If you built systems or test cases with HQC+liboqs .11.x or earlier, double-check that secrets derived during decryption failures cannot be confused with real keys.
- If you’re writing other PQC code: audit how you index key/secret buffers!

References

- CVE-2024-54137 at NVD (Coming Soon)
- Official liboqs Security Advisory
- Original HQC Crypto Spec

Always check updates: Stay secure by keeping crypto dependencies current.

- *Thanks to liboqs devs for fast response and fix!*

Timeline

Published on: 12/06/2024 16:15:22 UTC