Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The libcrux-ed25519 key generation samples Ed25519 secret keys from a provided CSPRNG in a loop for up to 100 attempts until a non-zero key is found. If a non-zero key could not be sampled within 100 attempts the key generation function would silently continue with an all-zero buffer as the secret key. Impact This bug only occurs in the event of a catastrophic failure of the CSPRNG, but would allow anyone to forge signatures under the resulting static signing key. Mitigation Instead of silently continuing with an all-zero signing key, starting from version 0.0.7 key generation will error in the case of 100 failed attempts at sampling a valid key.
Recommended action: Upgrade to 0.0.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In accordance with our security policy for libcrux, we publish a GitHub security advisory for any releases whose CHANGELOG includes bug-fixes, and encourage our users to upgrade. The latest releases of the libcrux-ecdh, libcrux-ed25519 and libcrux-psq crates contain the following bug-fixes: libcrux-ecdh - #1301: Check length and clamping in X25519 secret validation. This is a breaking change since errors are now raised on unclamped X25519 secrets or inputs of the wrong length libcrux-ed25519 - #1320: Remove duplicated clamping step during key generation The issue fixed in #1320 was first reported by Nadim Kobeissi. libcrux-psq - #1319: Propagate AEADError instead of panicking - #1301: Fix broken clamping check for imported X25519 secret keys The issue fixed in #1319 was first reported by Nadim Kobeissi.
Recommended action: Upgrade to 0.0.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.