Security Vulnerability: Implementation bias in __split_secret via rejection sampling (Entropy reduction)

[Pastorjetu]

While auditing the Shamir Secret Sharing implementation in the jsbtc library, I identified a cryptographic vulnerability in the coefficient generation process. This flaw violates the information-theoretic security of the SSSS by introducing a non-uniform distribution.

The vulnerability exists in src/functions/shamir_secret_sharing.js within the __split_secret function. Specifically, the implementation uses a rejection sampling loop:
while (q.includes(w))

This logic forces all polynomial coefficients to be distinct ($a_0 \neq a_1 \neq a_2 ... \neq a_n$).

In a standard Shamir scheme, coefficients must be chosen independently and uniformly from GF(256). By enforcing distinctness, the implementation leaks information about the secret to any attacker holding $k-1$ shares. For a threshold of 3, the keyspace for each byte is reduced from 256 to ~253 candidates. Across a 16-byte entropy (BIP-39), this results in a measurable reduction of the search space by a factor of approximately $(256/253)^{16} \approx 1.21$.

While some issues have touched on "non-uniformity," my report provides a full mathematical breakdown and a comparison with the pybtc implementation to confirm the intended behavior vs. the current JS flaw.

I have sent a comprehensive Security Advisory Report (PDF) including a Python-based Proof of Concept to admin@bitaps.com.

Reference Name in Email: VortexQuant171
Bounty Program: This report is submitted for the Shamir Secret Backup Scheme Bug Bounty.

Please let me know if you require further technical details.

My addres BTC: bc1q4y5sn0wxprx0yxjc7qejk4w7pvj9lc20uqsl4x

Thank you

[chris7ph]

Hi bitaps team,

I've been working through your 1 tBTC ZeroNights mnemonic challenge at tbtc.bitaps.com/mnemonic/challenge and wanted to reach out directly.

I've done a fairly thorough cryptographic analysis:

• Decoded both published shares (x=3 and x=15) and confirmed their entropy values
• Investigated the Issue Create Sjenica1 #23 coefficient bias in pybtc — ran full frequency analysis and confirmed the live challenge used a proper CSPRNG (flat 1.00x bias ratio), so that attack path is closed
• Verified there's no degree-reduction vulnerability exploitable with only 2 of 3 shares

The challenge is working exactly as intended — it's information-theoretically secure with 2 shares.

My question: Is the challenge still active? Is there any intention to ever release a third share, or is there a different intended solution path I'm missing?

I'm not asking for the answer handed to me — genuinely curious if there's a puzzle element I've overlooked, or if the challenge is purely a demonstration that proper SSS is unbreakable.

Thanks for building it — it's been a great deep-dive into GF(256) arithmetic.