Update OSV exported data

crates/RUSTSEC-2026-0073.json

@@ -1,8 +1,10 @@
 {
   "id": "RUSTSEC-2026-0073",
-  "modified": "2026-03-24T08:21:09Z",
+  "modified": "2026-03-27T05:55:06Z",
   "published": "2026-03-04T12:00:00Z",
-  "aliases": [],
+  "aliases": [
+    "GHSA-pv9v-5j35-xwcr"
+  ],
   "related": [],
   "summary": "Panic in Standalone MAC Operations",
   "details": "An incorrect constant for the key length in libcrux-poly1305 caused\nthe standalone MAC function `libcrux_poly1305::mac` to always panic\nwith an out-of-bounds memory access.\n\n## Impact\nApplications wishing to use libcrux-poly1305 as a standalone MAC would\nexperience panics. The use of libcrux-poly1305 in\nlibcrux-chacha20poly1305 is unaffected.\n\n## Mitigation\nStarting from version `0.0.5`, the correct value is used for the key\nlength constant.",

crates/RUSTSEC-2026-0074.json

@@ -1,8 +1,10 @@
 {
   "id": "RUSTSEC-2026-0074",
-  "modified": "2026-03-24T08:21:09Z",
+  "modified": "2026-03-27T05:55:06Z",
   "published": "2026-03-04T12:00:00Z",
-  "aliases": [],
+  "aliases": [
+    "GHSA-q29p-9pfr-j652"
+  ],
   "related": [],
   "summary": "Incorrect Output of Incremental Portable SHAKE API",
   "details": "The incremental squeeze functions in the portable SHAKE XOF API, when\n attempting to squeeze more than `RATE` (168 for SHAKE128, 136 for\n SHAKE256) bytes, performed an additional permutation of the state\n before producing the first output block, thus discarding the first\n block of `RATE` bytes of valid XOF output.\n\n## Impact\nThis bug impacts users that rely on this XOF API to squeeze more than\n`RATE` bytes. It does not impact the use of libcrux-sha3 in\nlibcrux-ml-kem or libcrux-ml-dsa.\n\n## Mitigation\nStarting from version `0.0.8` the squeeze functions correctly output\nall blocks including the first block.",

crates/RUSTSEC-2026-0075.json

@@ -1,8 +1,10 @@
 {
   "id": "RUSTSEC-2026-0075",
-  "modified": "2026-03-24T08:21:09Z",
+  "modified": "2026-03-27T05:55:06Z",
   "published": "2026-03-04T12:00:00Z",
-  "aliases": [],
+  "aliases": [
+    "GHSA-434v-x5qv-pmh6"
+  ],
   "related": [],
   "summary": "All-Zero Key Generation on Catastrophic RNG Failure",
   "details": "The libcrux-ed25519 key generation samples Ed25519 secret keys from a\nprovided CSPRNG in a loop for up to 100 attempts until a non-zero key\nis found.  If a non-zero key could not be sampled within 100 attempts\nthe key generation function would silently continue with an all-zero buffer as\nthe secret key.\n\n## Impact\nThis bug only occurs in the event of a catastrophic failure of the\nCSPRNG, but would allow anyone to forge signatures under the resulting\nstatic signing key.\n\n## Mitigation\nInstead of silently continuing with an all-zero signing key, starting\nfrom version `0.0.7` key generation will error in the case of 100\nfailed attempts at sampling a valid key.",

crates/RUSTSEC-2026-0076.json

@@ -1,8 +1,10 @@
 {
   "id": "RUSTSEC-2026-0076",
-  "modified": "2026-03-24T08:21:09Z",
+  "modified": "2026-03-27T05:55:06Z",
   "published": "2026-03-04T12:00:00Z",
-  "aliases": [],
+  "aliases": [
+    "GHSA-xrf2-5r3p-5wgj"
+  ],
   "related": [],
   "summary": "Panic in Signature Hint Decoding During Verification",
   "details": "During ML-DSA verification the serialized hint values are decoded as\nspecified in algorithm 22 `HintBitUnpack` of [FIPS 204, subsection\n7.1](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf#%5B%7B%22num%22%3A120%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22FitH%22%7D%2C657%5D). The\nalgorithm requires that the cumulative hint counters per row of the\nhint vector are strictly increasing and below a maximum value which\ndepends on the choice of ML-DSA parameter set (line 4).\n\nIn libcrux-ml-dsa, hint decoding did not check the boundedness of the\ncumulative hint counter of the last row of the hint vector.\n\n## Impact\nA manipulated invalid hint can cause an out-of-bounds memory access\nsince the hint decoding logic may attempt to read outside the bounds\nof the serialized signature, causing a runtime panic.\n\n## Mitigation\nStarting from version `0.0.8`, hint decoding will check the cumulative\nhint counter of the last row as well.",

crates/RUSTSEC-2026-0077.json

@@ -1,8 +1,10 @@
 {
   "id": "RUSTSEC-2026-0077",
-  "modified": "2026-03-24T08:21:09Z",
+  "modified": "2026-03-27T05:55:06Z",
   "published": "2026-03-04T12:00:00Z",
-  "aliases": [],
+  "aliases": [
+    "GHSA-cp57-fq8g-qh6v"
+  ],
   "related": [],
   "summary": "Incorrect Check of Signer Response Norm During Verification",
   "details": "The ML-DSA verification algorithm as specified in [FIPS 204,\nsubsection\n6.3](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf#subsection.6.3)\nrequires verifiers to check that the infinity norm of the deserialized\nsigner response $z$ does not exceed $\\gamma_1 - \\beta$ (line 13 of\nAlgorithm 8).\nThe same check is required to be performed during signature generation.\n\nlibcrux-ml-dsa did not perform this check correctly during signature\nverification, accepting signatures with signer response norm above the\nallowed maximum value.  The check is correctly performed during\nsigning.\n\n## Impact\nApplications using libcrux-ml-dsa for signature verification would\nhave accepted signatures that would be rejected by a conforming\nimplementation.\n\n## Mitigation\nStarting from version `0.0.8`, signature verification uses the correct\nvalue for $\\gamma_1$ in the signer response norm check.",