ghsa-73g8-5h73-26h4
Vulnerability from github
Published
2025-11-20 17:36
Modified
2025-11-21 22:18
Severity ?
Summary
@hpke/core reuses AEAD nonces
Details

Summary

The public SenderContext Seal() API has a race condition which allows for the same AEAD nonce to be re-used for multiple Seal() calls. This can lead to complete loss of Confidentiality and Integrity of the produced messages.

Details

The SenderContext Seal() implementation allows for concurrent executions to trigger computeNonce() with the same sequence number. This results in the same nonce being used in the suite's AEAD.

PoC

This code reproduces the issue (and also checks for more things that could be wrong with the implementation).

```js import { CipherSuite, KdfId, AeadId, KemId } from "hpke-js";

const suite = new CipherSuite({ kem: KemId.DhkemP256HkdfSha256, kdf: KdfId.HkdfSha256, aead: AeadId.Aes128Gcm, });

const keypair = await suite.kem.generateKeyPair(); const skR = keypair.privateKey; const pkR = keypair.publicKey;

const sender = await suite.createSenderContext({ recipientPublicKey: pkR, });

const [message0, message1] = await Promise.all([ sender.seal( new TextEncoder().encode("Secret message 1: Attack at dawn").buffer ), sender.seal( new TextEncoder().encode("Secret message 2: Withdraw troops").buffer ), ]);

const recipient = await suite.createRecipientContext({ recipientKey: skR, enc: sender.enc, });

const plaintext0 = await recipient.open(message0); console.log("✓ Decrypted message seq=0", new TextDecoder().decode(plaintext0));

try { console.log( "✓ Decrypted message seq=1", new TextDecoder().decode(await recipient.open(message1)) ); console.log("\n✓ nonce-reuse reproduction completed, code is NOT vulnerable"); } catch (error) { // re-sequence the recipient to verify same nonce was used for two messages recipient._ctx.seq = 0; console.log( "❌ Decrypted a different message with seq=0", new TextDecoder().decode(await recipient.open(message1)) );

console.log( "\n✓ nonce-reuse reproduction completed, code is vulnerable, nonces are reused when concurrent calls to .seal() are used" ); }

// Test that failed Open() doesn't increment sequence const recipient2 = await suite.createRecipientContext({ recipientKey: skR, enc: sender.enc, });

const invalidMessage = new Uint8Array(message0.byteLength); invalidMessage.set(new Uint8Array(message0)); invalidMessage[0] ^= 0xff; // Corrupt the first byte

try { await recipient2.open(invalidMessage.buffer); } catch {}

// Now try to open the first valid message - should still work with seq=0 try { await recipient2.open(message0); console.log("✓ Successfully decrypted message with seq=0 after failed open()"); console.log("✓ Failed open() did NOT increment sequence"); } catch (error) { console.log("❌ Failed to decrypt message - sequence was incorrectly incremented"); }

// Test that same message produces same ciphertext due to nonce reuse const sender2 = await suite.createSenderContext({ recipientPublicKey: pkR, });

const sameMessage = new TextEncoder().encode("Identical message").buffer; const [cipher0, cipher1] = await Promise.all([ sender2.seal(sameMessage), sender2.seal(sameMessage), ]);

const cipher0Array = new Uint8Array(cipher0); const cipher1Array = new Uint8Array(cipher1);

let identical = true; if (cipher0Array.length !== cipher1Array.length) { identical = false; } else { for (let i = 0; i < cipher0Array.length; i++) { if (cipher0Array[i] !== cipher1Array[i]) { identical = false; break; } } }

if (identical) { console.log("\n❌ Same message produced IDENTICAL ciphertext (nonce reuse confirmed)"); } else { console.log("\n✓ Same message produced different ciphertext (nonces are unique)"); } ```

Recommendation

Implement a synchronization mechanism such that only one seal()/open() per context can be executed at a time.

Notes

Refs: https://github.com/hpkewg/hpke/issues/38

https://www.rfc-editor.org/rfc/rfc9180.html#section-9.7.5 The AEADs specified in this document are not secure in case of nonce reuse.

https://www.rfc-editor.org/rfc/rfc9180.html#section-5-6 A context is an implementation-specific structure that encodes the AEAD algorithm and key in use, and manages the nonces used so that the same nonce is not used with multiple plaintexts.

The context implementation in @hpke/core is not correct given its AEAD Seal() is awaited/asynchronous.

Show details on source website


{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.7.4"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@hpke/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.7.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-64767"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-323"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-11-20T17:36:13Z",
    "nvd_published_at": "2025-11-21T19:16:03Z",
    "severity": "CRITICAL"
  },
  "details": "### Summary\n\nThe public SenderContext Seal() API has a race condition which allows for the same AEAD nonce to be re-used for multiple Seal() calls. This can lead to complete loss of Confidentiality and Integrity of the produced messages.\n\n### Details\n\nThe SenderContext Seal() [implementation](https://github.com/dajiaji/hpke-js/blob/b7fd3592c7c08660c98289d67c6bb7f891af75c4/packages/core/src/senderContext.ts#L22-L34) allows for concurrent executions to trigger `computeNonce()` with the same sequence number. This results in the same nonce being used in the suite\u0027s AEAD.\n\n### PoC\n\nThis code reproduces the issue (and also checks for more things that could be wrong with the implementation).\n\n```js\nimport { CipherSuite, KdfId, AeadId, KemId } from \"hpke-js\";\n\nconst suite = new CipherSuite({\n  kem: KemId.DhkemP256HkdfSha256,\n  kdf: KdfId.HkdfSha256,\n  aead: AeadId.Aes128Gcm,\n});\n\nconst keypair = await suite.kem.generateKeyPair();\nconst skR = keypair.privateKey;\nconst pkR = keypair.publicKey;\n\nconst sender = await suite.createSenderContext({\n  recipientPublicKey: pkR,\n});\n\nconst [message0, message1] = await Promise.all([\n  sender.seal(\n    new TextEncoder().encode(\"Secret message 1: Attack at dawn\").buffer\n  ),\n  sender.seal(\n    new TextEncoder().encode(\"Secret message 2: Withdraw troops\").buffer\n  ),\n]);\n\nconst recipient = await suite.createRecipientContext({\n  recipientKey: skR,\n  enc: sender.enc,\n});\n\nconst plaintext0 = await recipient.open(message0);\nconsole.log(\"\u2713 Decrypted message seq=0\", new TextDecoder().decode(plaintext0));\n\ntry {\n  console.log(\n    \"\u2713 Decrypted message seq=1\",\n    new TextDecoder().decode(await recipient.open(message1))\n  );\n  console.log(\"\\n\u2713 nonce-reuse reproduction completed, code is NOT vulnerable\");\n} catch (error) {\n  // re-sequence the recipient to verify same nonce was used for two messages\n  recipient._ctx.seq = 0;\n  console.log(\n    \"\u274c Decrypted a different message with seq=0\",\n    new TextDecoder().decode(await recipient.open(message1))\n  );\n\n  console.log(\n    \"\\n\u2713 nonce-reuse reproduction completed, code is vulnerable, nonces are reused when concurrent calls to .seal() are used\"\n  );\n}\n\n// Test that failed Open() doesn\u0027t increment sequence\nconst recipient2 = await suite.createRecipientContext({\n  recipientKey: skR,\n  enc: sender.enc,\n});\n\nconst invalidMessage = new Uint8Array(message0.byteLength);\ninvalidMessage.set(new Uint8Array(message0));\ninvalidMessage[0] ^= 0xff; // Corrupt the first byte\n\ntry {\n  await recipient2.open(invalidMessage.buffer);\n} catch {}\n\n// Now try to open the first valid message - should still work with seq=0\ntry {\n  await recipient2.open(message0);\n  console.log(\"\u2713 Successfully decrypted message with seq=0 after failed open()\");\n  console.log(\"\u2713 Failed open() did NOT increment sequence\");\n} catch (error) {\n  console.log(\"\u274c Failed to decrypt message - sequence was incorrectly incremented\");\n}\n\n// Test that same message produces same ciphertext due to nonce reuse\nconst sender2 = await suite.createSenderContext({\n  recipientPublicKey: pkR,\n});\n\nconst sameMessage = new TextEncoder().encode(\"Identical message\").buffer;\nconst [cipher0, cipher1] = await Promise.all([\n  sender2.seal(sameMessage),\n  sender2.seal(sameMessage),\n]);\n\nconst cipher0Array = new Uint8Array(cipher0);\nconst cipher1Array = new Uint8Array(cipher1);\n\nlet identical = true;\nif (cipher0Array.length !== cipher1Array.length) {\n  identical = false;\n} else {\n  for (let i = 0; i \u003c cipher0Array.length; i++) {\n    if (cipher0Array[i] !== cipher1Array[i]) {\n      identical = false;\n      break;\n    }\n  }\n}\n\nif (identical) {\n  console.log(\"\\n\u274c Same message produced IDENTICAL ciphertext (nonce reuse confirmed)\");\n} else {\n  console.log(\"\\n\u2713 Same message produced different ciphertext (nonces are unique)\");\n}\n```\n\n### Recommendation\n\nImplement a synchronization mechanism such that only one seal()/open() per context can be executed at a time.\n\n### Notes\n\nRefs: https://github.com/hpkewg/hpke/issues/38\n\n\u003e https://www.rfc-editor.org/rfc/rfc9180.html#section-9.7.5\n\u003e The AEADs specified in this document are not secure in case of nonce reuse.\n\n\u003e https://www.rfc-editor.org/rfc/rfc9180.html#section-5-6\n\u003e A context is an implementation-specific structure that encodes the AEAD algorithm and key in use, and manages the nonces used so that the same nonce is not used with multiple plaintexts.\n\nThe context implementation in @hpke/core is not correct given its AEAD Seal() is awaited/asynchronous.",
  "id": "GHSA-73g8-5h73-26h4",
  "modified": "2025-11-21T22:18:25Z",
  "published": "2025-11-20T17:36:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/dajiaji/hpke-js/security/advisories/GHSA-73g8-5h73-26h4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64767"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dajiaji/hpke-js/commit/94a767c9b9f37ce48d5cd86f7017d8cacd294aaf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dajiaji/hpke-js"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dajiaji/hpke-js/blob/b7fd3592c7c08660c98289d67c6bb7f891af75c4/packages/core/src/senderContext.ts#L22-L34"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "@hpke/core reuses AEAD nonces"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.


Loading…

Loading…