SerpApi.Org
Researchers at zkSecurity ran an AI-powered dual-agent pipeline over bron-crypto — the open-source Go cryptography library that powers Bron Wallet's MPC-based key management — and confirmed four zero-day vulnerabilities before any attacker could find them first. The most serious flaw silently stores the wrong ciphertext during distributed key generation for threshold-ECDSA signing, meaning any wallet that generated keys through that code path cannot produce a valid signature. All four bugs have been patched upstream by Bron Labs.
The case makes a specific, practical argument for what AI-assisted security auditing can and cannot do: it is reliably good at surfacing what the researchers call "typo bugs" — operand swaps, inverted return values, copy-paste errors — but it is not yet a replacement for expert human review of the structural cryptographic choices underneath.
Bron Labs Built a Real Consumer Wallet on This Library
bron-crypto is not an experimental prototype. Bron Labs — founded in 2025 by Dmitry Tokarev, former CEO of institutional custodian Copper Technologies — raised $15 million from investors including LocalGlobe, Fasanara Digital, and GSR to build a consumer-grade MPC wallet aimed at bringing institutional-level key security to individual users. The Bron Wallet replaces traditional private keys with three cryptographic shards distributed across the user, Bron, and a trusted third party. Any two shards are sufficient to authorize a transaction; no single party ever holds the complete key.
The library that underpins this architecture — bron-crypto, hosted at github.com/bronlabs/bron-crypto — supports the Lindell17 and DKLs23 threshold-ECDSA protocols, plus Poseidon hashing and arithmetic over BLS12-381, k256, Pallas, and Vesta elliptic curves. A security defect anywhere in that primitive layer propagates silently into every higher-level protocol built on top of it.
How the AI Pipeline Worked
zkSecurity ran bron-crypto through a dual-agent pipeline that pitted two AI models against each other: Claude Opus 4.6 served as primary auditor and GPT-5.3 as an independent cross-validator, then the roles were reversed. The combined scan produced 30 candidate findings. Human experts on the team validated each one, confirmed exploitability, minimized proof-of-concept demonstrations, and handled coordinated disclosure — a step the researchers describe as still essential, because AI candidate findings are cheap while trustworthy reports are not.
This is the third consecutive open-source cryptography project in a series that began in early July. The first post covered Cloudflare's CIRCL library, where the same pipeline confirmed seven real bugs, including a critical access-control break in ciphertext-policy attribute-based encryption that zkSecurity's commercial zkao tool found entirely autonomously.
The dual-agent framing matters because of something zkSecurity documented in the CIRCL post: model pairings are not symmetric, and the roles can flip across model generations. In the CIRCL run, Claude Opus 4.6 found most bugs and GPT-5.3 mostly validated. A few weeks later, rerunning with Opus 4.7 and GPT-5.4, the roles had essentially reversed — GPT-5.4 found more bugs, Opus 4.7 confirmed. The practical implication is that no single model should be treated as the definitive auditor, and a pipeline designed to be model-agnostic outperforms one built around a specific version.
Bug One: Swapped Operands Corrupt Threshold-ECDSA Key Shares
Severity: High (confirmed by Bron Labs)
The most consequential finding sits inside bron-crypto's implementation of the Lindell17 distributed key generation protocol. To understand why, a brief explanation of the protocol's structure is necessary.
Lindell17 threshold ECDSA uses Paillier encryption — a cryptosystem that is additively homomorphic, meaning you can compute the encryption of a sum from the encryptions of the parts, without ever decrypting. In the DKG phase, each party decomposes its private share x into two sub-pieces, x′ and x″, and publishes Paillier-encrypted versions of each. Other parties then use the additive property to reconstruct the full encrypted share as Enc(3x′ + x″). The coefficient 3 must multiply the first sub-piece.
bron-crypto had the operands transposed. The implementation computed Enc(x′ + 3x″) instead — applying the coefficient to the wrong sub-piece. The resulting ciphertext does not encrypt the participant's actual share. Threshold-ECDSA signing operations that depend on these shares produce incorrect partial signatures or fail entirely.
The private key is not exposed. But any wallet that ran DKG through the vulnerable code path stored incorrect key material. The practical consequence: funds held in such a wallet cannot be moved, because a valid signature cannot be assembled from corrupted shares. The fix was a one-line operand swap in PR #197.
Important for current users: This fix corrects the code going forward. It does not regenerate key shares that were produced before the patch. Users who generated Lindell17 key shares using a vulnerable version of bron-crypto should confirm with Bron Labs whether their key material was generated on a patched build, or initiate a key-share regeneration if it was not. Bron Labs has not published explicit public guidance on this point at the time of writing.
Bug Two: Poseidon Hash Breaks Go's Standard Interface Contract
Severity: Low (confirmed by Bron Labs)
Poseidon is a sponge-based hash function optimized for use inside zero-knowledge proof circuits — it can be evaluated efficiently inside ZK arithmetic, whereas standard SHA-3 cannot. bron-crypto exposes it both through a native Update/Digest API and as an adapter for Go's standard hash.Hash interface, which the rest of the Go ecosystem uses for interoperable hashing.
Go's hash.Hash contract has two guarantees that the bron-crypto adapter violated. First, successive Write calls must accumulate: Write(a) followed by Write(b) must produce the same digest as hashing a||b in one call. Second, Sum(b) must append the digest to b as a prefix without mutating the hasher's state.
The adapter implemented Write by calling the library's one-shot Hash() entry point, which resets the sponge on every invocation. Every Write call therefore discarded all prior input, hashing only the last thing written. Sum routed its argument through Write as if it were additional input data, violating the non-mutating contract, and would panic on any prefix that was not a multiple of 32 bytes.
Because bron-crypto's own MPC protocols use the direct sponge API rather than the hash.Hash adapter, the damage was confined to external callers reaching Poseidon through the standard interface. PR #202 rewires Write to use Update (which accumulates without resetting) and rewrites Sum to append without disturbing state.
Bug Three: IsOnCurve Returns the Opposite of What It Should
Severity: Medium (confirmed by Bron Labs)
Before operating on an elliptic-curve point received from an external source, a well-implemented library verifies that the point actually lies on the intended curve. Failing to do this, or getting it wrong, opens the door to invalid-curve attacks — a well-documented attack class in which an adversary supplies a point on a weaker related curve, and subsequent scalar multiplications with secret data leak information about that secret.
bron-crypto wraps three curves — k256, Pallas, and Vesta — in Go's elliptic.Curve interface, which includes an IsOnCurve method. The adapter for all three had its return value inverted. It returned err != nil from an underlying routine that signals an error precisely when the point is not on the curve. The correct return is err == nil (no error means the point is valid).
The practical consequence of this one-character inversion: valid curve points, including the standard curve generator, are rejected as invalid. Off-curve points are accepted as legitimate. Because Go's elliptic.Unmarshal function calls IsOnCurve internally, deserializing a correctly encoded point fails and deserializing a malformed one succeeds. External callers who unmarshal curve points through the standard Go path are the affected population; bron-crypto's own MPC protocols do not use this adapter path. PR #196 corrects the single character across three files.
Bug Four: IsZero Checks for One Instead of Zero
Severity: Low (confirmed by Bron Labs)
In the BLS12-381 G2 field element implementation, the IsZero method was written by copy-pasting the IsOne method from immediately above it in the source file — and the predicate was never updated. IsZero therefore returns true for the field element 1 and false for zero.
Every construct built on the method inherits the inversion, including identity-point detection and the Euclidean valuation used in field arithmetic. Both zkSecurity and Bron Labs rated this Low, because the method is not currently reachable through any call path in production. The fix is a single-word correction in PR #222. Its severity rating should be understood as library-context-dependent: a Low in bron-crypto's current call graph could become a Medium or High in a downstream library that relies on this interface.
What This Series Is Teaching Security Teams About AI Auditing
zkSecurity's broader finding across the series is a precise statement of where LLM-based auditing currently sits: it converges. Across repeated runs with a fixed model and similar prompts, the same bugs resurface. The same issues appear independently from different angles.
The team notes that several of its bron-crypto findings appear to have been grouped together in Bron Labs's own omnibus pull requests — suggesting the library's maintainers may have run a parallel model pass and swept the overlapping results into bulk "robustness" commits. This is consistent with convergence: two independent LLM passes on the same code are likely to surface the same "typo bug" set.
The practical implication for security teams: running the same model more times against the same code yields diminishing returns quickly. What moves the set of discoverable bugs is the harness — how code is decomposed for the model, how context is structured, and how expert cryptographic knowledge is encoded into the audit workflow. The bugs that AI currently finds reliably are the ones with a straightforward surface signature: a transposed argument, an inverted boolean, a copy-paste that wasn't updated. Deeper, structurally cryptographic vulnerabilities — the kind that require reasoning across protocol layers to assess impact — require more sophisticated tooling and remain the province of expert human review, at least for now.
The broader industry context is that AI-assisted auditing is accelerating across the cryptography ecosystem. The same week that bron-crypto was patched, TrendAI's FENRIR static analysis tool was credited with finding eight of nine vulnerabilities patched in X.Org Server — the fourth such batch this year from AI-assisted scanning of that aging C codebase.
Earlier in the summer, Claude Opus 4.8 helped surface a four-year-old soundness bug in Zcash's Orchard shielded pool — a protocol-level vulnerability that required human reasoning to fully assess and that caused ZEC to fall more than 30% following disclosure.
Responsible Disclosure and Patch Status
zkSecurity followed a coordinated disclosure process, working privately with Bron Labs before publication. Bron Labs triaged and patched all four findings before the report went public on July 22, 2026. The researchers were acknowledged in Bron's bug bounty program. The full technical write-up, including code diffs and proof-of-concept details, is available at zkSecurity's blog.
For any team maintaining or building on bron-crypto, the recommended action is immediate: confirm the upstream version in use is past the patched commits for PRs #197, #202, #196, and #222. For Bron Wallet users, the practical question is whether their key shares were generated before or after the patch for Bug 1 — and direct outreach to Bron Labs is the fastest path to a definitive answer.
Frequently Asked Questions
If I use Bron Wallet, are my funds at risk?
If your wallet generated threshold-ECDSA key shares using bron-crypto before Bug 1 (PR #197) was patched, those key shares may be corrupted — meaning the wallet cannot produce a valid signature to move your funds. The patch fixes the code for future key generation; it does not automatically repair existing corrupted shares. Contact Bron Labs support to confirm whether your account was set up on a patched version of the library, or whether you need to initiate a key-share regeneration.
What is an MPC wallet and why does a bug in the key generation code matter?
In an MPC (multi-party computation) wallet, your private key is never held by any single party or device. Instead, multiple parties each hold a mathematical "share," and any threshold number of those shares can cooperate to produce a valid signature without any one party ever seeing the full key. The distributed key generation (DKG) step is where those shares are created. A bug in DKG — like the operand swap in bron-crypto Bug 1 — corrupts the shares at the point of creation. The signed output later will not match what the network expects, making the wallet unable to authorize transactions.
Can AI replace human security auditors for cryptographic code?
Not yet, and possibly not for the hardest class of flaws. zkSecurity's data from the bron-crypto and CIRCL audits shows that AI reliably finds implementation bugs with a clear surface signature — swapped operands, inverted booleans, copy-paste errors. These are real vulnerabilities; Bug 1 could have frozen user funds. But AI severity ratings remain unreliable (it over-rated some bugs and under-rated a critical rogue-key flaw in the CIRCL series), and structural, protocol-level vulnerabilities — the kind that require reasoning about what a bug means across a full cryptographic system — still require expert human judgment. The current best practice is human-AI collaboration: the model generates candidate findings efficiently; the human validates exploitability, assesses impact, and handles disclosure.
What should a developer do if their project depends on bron-crypto?
Verify that the version you are using includes the fixes for all four bugs: PR #197 (Bug 1 — threshold-ECDSA DKG operand swap), PR #202 (Bug 2 — Poseidon hash.Hash adapter), PR #196 (Bug 3 — IsOnCurve inversion), and PR #222 (Bug 4 — IsZero copy-paste). If you are using bron-crypto's k256, Pallas, or Vesta curve wrappers through Go's standard elliptic.Curve interface from external code, Bug 3 is the most operationally significant for your use case. If you are using the Poseidon hash through Go's hash.Hash interface, Bug 2 is your primary concern. No exploitation of any of these bugs has been publicly documented.
Related Articles
