Push libcrux-psq and hpke-rs advisory proposals

[nadimkobeissi]

These are proposals for the more impactful vulnerabilities discovered as part of this research work:

Verification Theatre: False Assurance in Formally Verified Cryptographic Libraries

Cryspen has not issued any security advisory for any of these bugs despite patching them four days after I initially submitted my fixes.

In November 2025, another serious security issue was discovered in the libcrux-intrinsics crate, and Cryspen also did not issue a security advisory; other people had to take it upon themselves to submit one to this database, and hope that a direct announcement from Cryspen would follow (it never did).

Hence, I am doing the same thing here.

The full disclosure timeline, including Cryspen's response, is documented in the paper.

Happy to accept any feedback on the wording of any of the submitted issues. Thanks.

[nadimkobeissi]

Run rustsec-admin lint
error: RustSec error: git operation failed: expected ./crates/hpke-rs/RUSTSEC-0000-0001.md to be named "RUSTSEC-0000-0000.md"
Caused by:
  -> git operation failed: expected ./crates/hpke-rs/RUSTSEC-0000-0001.md to be named "RUSTSEC-0000-0000.md"
Error: Process completed with exit code 1.

I can't name both files RUSTSEC-0000-0000.md, so I'm ignoring this.

[djc]

We generally don't merge advisories without buy-in from the maintainer(s), and given the upstream response to your PRs I'm certainly not going to do so here.

Even though I think it would be good to have advisories for (some of) these issues.

@jschneider-bensch and/or @franziskuskiefer how do you want to move forward?

[nadimkobeissi]

given the upstream response to your PRs I'm certainly not going to do so here.

@djc In most cases where my PRs were rejected, the maintainers ended up simply merging my exact same fixes four days later by copy-pasting them from my PRs. Which is basically (if we're being charitable) "merging my PRs with extra steps".

The response from the maintainers was uncalled for, counterproductive, and doesn't help making sure these issues are fixed quickly and that those affected receive the notice that they need.

I just want an advisory to be issued and a new release to be pushed so that these vulnerabilities are fixed and users downstream are informed. I'm sick of dealing with the maintainers.

[nadimkobeissi]

Even though I think it would be good to have advisories for (some of) these issues.

You'll note that my paper has five issues, but I only submitted advisories for three. The three I submitted advisories for are those I believe non-negotiably should have advisories, and for which a lack of advisory would be irresponsible. The remaining two are debatable and thus I didn't go out of my way to write advisories for them.

[djc]

I don't care for the pressure you seem to be trying to exert. If the maintainers have not responded in two weeks, we can see about moving forward without their involvement.

[nadimkobeissi]

I don't care for the pressure you seem to be trying to exert.

I am absolutely not trying to exert any pressure, and I absolutely don't appreciate your accusing me of that. I was responding to what you wrote, explaining my point of view, contextualizing my PR and justifying why I think these advisories are important.

Nobody is trying to exert pressure on anyone.

[jschneider-bensch]

@jschneider-bensch and/or @franziskuskiefer how do you want to move forward?

@djc We have updated the security policy for libcrux and going forward we will issue GitHub security advisories for any releases whose CHANGELOG includes bug-fixes.

We published releases for libcrux-ecdh, libcrux-ed25519 and libcrux-psq today, as well as a GitHub security advisory covering those releases.

A release and accompanying advisory is forthcoming for hpke-rs.

[nadimkobeissi]

While this is an improvement (hard for it to be anything else), the security advisory is incomplete since it doesn’t have any discussion on impact.

@jschneider-bensch I don't mean to give you directions, but I would strongly advise you to please update the security advisory to note impact for each issue.

Notably, the libcrux-psq issue where a malformed AES-GCM ciphertext led to crashes meant that the libcrux-psq crate implemented PSQ in a way which wasn't IND-CCA secure. This is a very important distinction both on the practical and academic level, and not mentioning it in the security advisory (or, worse, not having an impact discussion for any section at all) simply makes no sense.

Thank you.

[nadimkobeissi]

We published releases for libcrux-ecdh, libcrux-ed25519 and libcrux-psq today,

@jschneider-bensch Looks like the releases are indeed on crates.io, but I missed them because they don't show up on the GitHub releases page like all previous releases. I would urge you to make sure that both sources reflect the new releases, so that downstream users are not given conflicting information.

[franziskuskiefer]

A release and accompanying advisory is forthcoming for hpke-rs.

We similarly published GHSA-g433-pq76-6cmf and the corresponding releases.

[nadimkobeissi]

@franziskuskiefer Respectfully, GHSA-g433-pq76-6cmf is a highly problematic advisory:

• It classifies the severity of a nonce reuse vulnerability, which leads to full plaintext recovery, as moderate. This is completely misleading. According to CVSS 4.0, this is a 9.3/10 critical vulnerability (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N/AU:Y/RE:L).
• Similarly to the above, it does not include any discussion of the vulnerability itself, its impact or its mitigation.

This is simply not what a responsible security advisory looks like. Let's look at another example (GHSA-hcp2-x6j4-29j7). Note how it has sections for:

• Details
• Impact
• Mitigation

Your security advisories should have all three sections. Simply linking to some commit headline that says “Fix panic” or "fix potential overflow in context counter" provides the user with absolutely no information and doesn’t allow them to judge their risk profile.

I will not be accepting credit for this security advisory until it is updated such that the severity is no longer misleading and such that it includes all of the appropriate details. In its current state, it's wholly inappropriate.

Quoting the Cryspen code of conduct:

• Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
• Focusing on what is best not just for us as individuals, but for the overall community

An advisory structured to cover up problems almost entirely does not meet your own conduct standards.

[pinkforest]

We generally don't merge advisories without buy-in from the maintainer(s)

That is not simply true. RustSec has merged advisories before without maintainer buy-in.

[pinkforest]

I also reviewed the said security policy that would have existed which did not exist at all.

• Security policy is undocumented cryspen/hpke-rs#132

Cryspen or @franziskuskiefer ought to apologize to @nadimkobeissi

[pinkforest]

I don't care for the pressure you seem to be trying to exert.

This is both untrue and such inflammatory unproductive way to respond. Please can we treat people with respect and keep away from personal attacks just like Cryspen should not personally attack security researchers when in fact they (Cryspen) dropped the ball here by not having a policy at all.

@djc If I would be you, I would apologize and think how to respond as a maintainer little bit more in delicate manner.

[nadimkobeissi]

They went and merged a nonce reuse vulnerability leading to full plaintext recovery into the GitHub Advisory Database as a moderate-severity vulnerability, without discussing impact or even naming what went wrong beyond "Fix potential overflow in context counter and switch to use u64.". GHSA-g433-pq76-6cmf

My above comment urging @franziskuskiefer didn't result in anything other than him blocking me on GitHub, which he appears to have done today. He completely ignored my request for a discussion on details, impact or mitigation and did not update the severity: #2637 (comment)

The level of sustained dishonesty that Cryspen is demonstrating here is unreal. In my view this only makes it more urgent to ensure that the RustSec advisory at least gets things right.

This is really unbelievable stuff.

[nadimkobeissi]

@djc I believe that the above shows that the Cryspen maintainers are obviously working in bad faith in order to obfuscate the true severity of the vulnerabilities and that they are both non-receptive to feedback and actively antagonizing those who report vulnerabilities.

How would you suggest we proceed in light of these circumstances?