rustsec-2024-0398
Vulnerability from osv_rustsec
Published
2024-11-16 12:00
Modified
2025-10-28 06:02
Summary
Bias of Polynomial Coefficients in Secret Sharing
Details

Affected versions of this crate allowed for a bias when generating random polynomials for Shamir Secret Sharing, where instead of being within the range [0, 255] they were instead in the range [1, 255]. A description from Cure53, who originally found the issue, is available:

The correct method to select a random polynomial would be to select all coefficients (including the most significant coefficient) uniformly in the range 0..255 (inclusive). Otherwise, knowledge that a coefficient in a polynomial cannot be 0 permits the exclusion of single byte values for the shared secret given one share less than required. [...] Exploiting this weakness necessitates sharing the same secret multiple times. In this scenario, an attacker could exclude an exponential number of values for each of the shared bytes until sufficiently few values remain for brute forcing. Cure53 estimates that under ideal circumstances (e.g., a 2-out-of-N scheme) a shared secret can be reconstructed if the same secret has been distributed 500-1500 times.

Secrets that have been shared a low amount of times (ideally, once) would not be impacted. However, secrets that are repeatedly shared may be vulnerable, especially if the shares are still available, and should be rotated.

The vulnerability does not impact reconstitution of secrets: secrets that have already been split can be recombined without issue.

The flaw can be corrected by changing the lower bound of the polynomial coefficient range in the sharks::math::random_polynomial function to 0. The blahaj crate has been made available with a fixed version of the code, after attempts to reach the maintainer of the sharks crate were unsuccessful.

To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "categories": [
          "crypto-failure"
        ],
        "cvss": null,
        "informational": null
      },
      "ecosystem_specific": {
        "affected_functions": null,
        "affects": {
          "arch": [],
          "functions": [],
          "os": []
        }
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "sharks",
        "purl": "pkg:cargo/sharks"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.0.0-0"
            }
          ],
          "type": "SEMVER"
        }
      ],
      "versions": []
    }
  ],
  "aliases": [
    "GHSA-jp37-5qhw-mffw"
  ],
  "database_specific": {
    "license": "CC0-1.0"
  },
  "details": "Affected versions of this crate allowed for a bias when generating random\npolynomials for Shamir Secret Sharing, where instead of being within the range\n`[0, 255]` they were instead in the range `[1, 255]`. A description from\nCure53, who originally found the issue, is available:\n\n\u003e The correct method to select a random polynomial would be to select\nall coefficients (including the most significant coefficient) uniformly\nin the range 0..255 (inclusive). Otherwise, knowledge that a coefficient\nin a polynomial cannot be 0 permits the exclusion of single byte values\nfor the shared secret given one share less than required. [...]\nExploiting this weakness necessitates sharing the same secret multiple\ntimes. In this scenario, an attacker could exclude an exponential number\nof values for each of the shared bytes until sufficiently few values\nremain for brute forcing.  Cure53 estimates that under ideal\ncircumstances (e.g., a 2-out-of-N scheme) a shared secret can be\nreconstructed if the same secret has been distributed 500-1500 times.\n\nSecrets that have been shared a low amount of times (ideally, once) would not\nbe impacted. However, secrets that are repeatedly shared may be vulnerable,\nespecially if the shares are still available, and should be rotated.\n\nThe vulnerability does not impact reconstitution of secrets: secrets that have\nalready been split can be recombined without issue.\n\nThe flaw can be corrected by changing the lower bound of the polynomial\ncoefficient range in the `sharks::math::random_polynomial` function to `0`. The\n`blahaj` crate has been made available with a fixed version of the code, after\nattempts to reach the maintainer of the `sharks` crate were unsuccessful.",
  "id": "RUSTSEC-2024-0398",
  "modified": "2025-10-28T06:02:18Z",
  "published": "2024-11-16T12:00:00Z",
  "references": [
    {
      "type": "PACKAGE",
      "url": "https://crates.io/crates/sharks"
    },
    {
      "type": "ADVISORY",
      "url": "https://rustsec.org/advisories/RUSTSEC-2024-0398.html"
    },
    {
      "type": "WEB",
      "url": "https://git.distrust.co/public/blahaj/commit/4faab1cd33d455f0ca2ccc7208093fd6c18e0767"
    }
  ],
  "related": [],
  "severity": [],
  "summary": "Bias of Polynomial Coefficients in Secret Sharing"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Detection rules are retrieved from Rulezet.