Potential Vulnerability - Misuse of HKDF and Salt #21
Description
Now... I wouldn't really call this a vulnerability because the only way to abuse it is if an attacker knows 2 salts and 2 private keys that were generated with those 2 salts. The salts are secret—they are only used during key derivation, and the private keys are also kept secret. The only way an attacker could learn the keys and salts would be if they had access to the system that this code is running on, and if they were able to either look through a memory dump or perform some other kind of side channel attack, or if they were able to abuse a critical vulnerability on the host machine. If an attacker can learn private keys using zero days, exploiting the host machine's vulnerabilities when the host machine is at an AWS datacenter, then I'm sorry to say this, but nobody is safe. This library is the closest we can get to be "safe" on the cloud without spending a ton of money on cloud HSMs or by self-hosting on secure, dedicated hardware with on-board HSMs. I will add that other protocols can be just as "safe" as this one, that this one is not exactly the "best" but it is the one that I trust when paired with HTTPS/SSL.
This is how Gemini would write the Github Issue:
Title: Critical: HKDF Salt Misuse in info Parameter Leads to Vulnerable Key Derivation
Description:
Problem
The current protocol places the rotating, epoch-specific salt in the info parameter of the HKDF. This is a critical cryptographic misuse of the HKDF standard. The HKDF is designed to use the salt in the extract step, which is the first of its two phases. By placing the salt in the expand step's info parameter, we are effectively using the same, static Pseudo-Random Key (PRK) across all epochs.This creates a serious vulnerability. An attacker who obtains just two derived keys from different epochs (e.g., one from 2024 and one from 2025) can leverage a known-plaintext attack to reverse-engineer the single underlying PRK. Once the PRK is compromised, an attacker can generate any key for any epoch (past or future) and for any purpose within the protocol, as long as they know the format of the info parameter.
Proposed Solution
The protocol must be refactored to use the HKDF as intended, by properly salting the extract step. This can be achieved by writing a set of helper functions that handle the initialization of the HKDF with the correct salt for each epoch.Stop using a single, long-lived HKDF instance. The HKDF should not be a single object that persists across epochs.
Generate a new HKDF instance for each epoch. Every time the salt rotates (e.g., every year), a new HKDF instance should be initialized.
Properly place the salt. The epoch-specific salt must be supplied to the HKDF during its initialization, in the salt parameter, not the info parameter.
Use info for its intended purpose. The info parameter should be used to provide context for different keys within the same epoch (e.g., "authentication key," "encryption key").
Implementation Plan
Create a new module or set of functions dedicated to key derivation.Add a function like get_hkdf_for_epoch(epoch_salt) which takes the current epoch's salt and returns a new, initialized HKDF object.
Ensure all key generation calls use this new function to obtain an HKDF instance, rather than reusing a single, globally-scoped one.
Create a "legacy" branch to preserve the old, vulnerable protocol. All future development should occur on a new branch with the corrected protocol.
I will follow the implementation plan, but know it isn't 100% AI generated. This implementation plan was created after a discussion, where I had proposed some solutions. It is pretty generic, but I would be doing all of this anyway regardless of whether Gemini had "suggested" it. Just saying.