ghsa-w3hj-wr2q-x83g
Vulnerability from github
Published
2021-04-06 17:22
Modified
2025-12-02 01:28
Summary
Discovery uses the same AES/GCM Nonce throughout the session
Details

Discovery uses the same AES/GCM Nonce throughout the session though it should be generated on per message basis which can lead to the leaking of the session key. As the actual ENR record is signed with a different key it is not possible for an attacker to alter the ENR record. Note that the node private key is not compromised, only the session key generated to communicate with an individual peer.

From discovery spec:

The number of messages which can be encrypted with a certain session key is limited because encryption of each message requires a unique nonce for AES-GCM. In addition to the keys, the session cache must also keep track of the count of outgoing messages to ensure the uniqueness of nonce values. Since the wire protocol uses 96 bit AES-GCM nonces, it is strongly recommended to generate them by encoding the current outgoing message count into the first 32 bits of the nonce and filling the remaining 64 bits with random data generated by a cryptographically secure random number generator.

Show details on source website


{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "tech.pegasys.discovery:discovery"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.4.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-23688"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-323",
      "CWE-330"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-03-30T17:04:34Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "Discovery uses the same AES/GCM Nonce throughout the session though it should be generated on per message basis which can lead to the leaking of the session key.  As the actual ENR record is signed with a different key it is not possible for an attacker to alter the ENR record. Note that the node private key is not compromised, only the session key generated to communicate with an individual peer.\n\nFrom [discovery spec](https://github.com/ethereum/devp2p/blob/f97b8a5b8e9589d3355ebbd9d4a58d5d1644bdf7/discv5/discv5-theory.md#session-cache):\n\u003e The number of messages which can be encrypted with a certain session key is limited because encryption of each message requires a unique nonce for AES-GCM. In addition to the keys, the session cache must also keep track of the count of outgoing messages to ensure the uniqueness of nonce values. Since the wire protocol uses 96 bit AES-GCM nonces, it is strongly recommended to generate them by encoding the current outgoing message count into the first 32 bits of the nonce and filling the remaining 64 bits with random data generated by a cryptographically secure random number generator.",
  "id": "GHSA-w3hj-wr2q-x83g",
  "modified": "2025-12-02T01:28:16Z",
  "published": "2021-04-06T17:22:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ConsenSys/discovery/security/advisories/GHSA-w3hj-wr2q-x83g"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23688"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ConsenSys/discovery"
    },
    {
      "type": "WEB",
      "url": "https://vulncheck.com/advisories/vc-advisory-GHSA-w3hj-wr2q-x83g"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Discovery uses the same AES/GCM Nonce throughout the session"
}


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…