Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Priority: P2 — NUT-13 residue-collision guard is dead code in gonuts v0.13.0 (Conduition disclosure): CheckCollidingKeysets never invoked; wallet-level fix belongs in gonuts-tollgate, tracked here

Open
  • Is something wrong?
#705 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@Amperstrand is already working on this.

Since Oct 8, 2026.

  • #781 by @Amperstrand — open

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
32/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
go
Domain
backend, security

Research direction

Start by tracing keyset registration and persistence in AddMint, keyset refresh, and restore, then locate CheckCollidingKeysets and the existing SaveKeyset guard. The issue requires checking every registration path and adding tests for collisions, unaffected non-colliding registration, rotation, and partial-state prevention; done means collisions are refused before state is written. The proposed keyset-ID verification also needs validation against the applicable ID variants.

Written by the indexing model from the issue text.

Description

area: payments release:post-0.6.0

What (all refs at tag v0.13.0)

The deterministic-derivation implementation is exactly the BIP32 shape the Conduition NUT-13 disclosure (https://conduition.io/code/cashu-disclosure/, 2026-01, bounty-paid) describes as attackable, and the mitigation that already exists in this repo is never invoked:

  • cashu/nuts/nut13/nut13.go:24,40 — the keyset ID is reduced mod (2^31 - 1) to keyset_id_int
  • nut13.go:51-63 — path m/129372'/0'/keyset_id_int'
  • nut13.go:94-116 / :72-75 — DeriveSecret = .../counter'/0, DeriveBlindingFactor = .../counter'/1
  • nut13.go:119-143 — CheckCollidingKeysets(currentKeysetIds, newMintKeysetIds) implements precisely the disclosure's short-term fix (refuse keysets whose 2^31 - 1 residues collide; also refuses exact duplicate IDs across mints) — and a grep across the whole module (wallet, mint, cmd, tests) finds zero call sites. Dead code.
  • No wallet-path verification that a mint-fetched keyset ID actually derives from the mint's published keys (DeriveKeysetId) — only per-proof DLEQ checks, which do not constrain the ID.

Why it matters

Per the disclosure: a malicious mint can pick a keyset ID whose 31-bit residue collides with a target mint's; a wallet that transacts with both then derives the same secrets and blinding factors for both keysets, and the malicious mint can use the target mint's NUT-09 /restore endpoint as an oracle to harvest blind signatures and construct valid proofs at the target mint. Most NUT-13 wallets were affected; the short-term fix advised for every wallet is exactly the collision guard this repo already has, unwired.

TollGate-side exposure (context from OpenTollGate/tollgate-module-basic-go#703 item 7): mints are operator-curated (accepted_mints + trust allow/blocklists) and the daemon does not auto-transfer between mints, so the no-user-interaction variant does not apply. The realistic vector is an operator running an untrusted mint alongside an honest one. Moderate severity; not a release blocker; the wiring is small.

Proposed fix

  1. Wire the existing guard into every keyset-registration writer — AddMint, keyset refresh, and restore: before persisting a new keyset, run CheckCollidingKeysets against all already-registered keysets; on collision, refuse registration with an error naming both mints and both IDs. This follows the same pattern as the SaveKeyset monotonic-counter guard (the #480/#496 writer-audit class: a guard that exists must be on every writer's path).
  2. Cheap hardening: verify mint-fetched keyset IDs against DeriveKeysetId(pubkeys) where the ID variant permits, rejecting forged IDs at registration.
  3. Explicitly not proposed now: switching derivation to the disclosure's long-term fix (single HMAC over full keyset ID + counter, no BIP32 path). That changes every derived secret and silently invalidates determinism for existing wallets' counter ranges — it needs a versioned derivation plus a migration design, not a patch. Note also that V2 keyset IDs alone do not fix this: keysetIdToBigInt funnels V2 IDs through the same 2^31 - 1 residue.

Required tests

  • Registering a second mint with a residue-colliding keyset ID → refused, error names both mints/IDs.
  • Non-colliding multi-mint registration unaffected.
  • The collision check runs before any counter or derivation state is written (registration refusal leaves no partial state).
  • Keyset rotation/refresh that produces a colliding ID → refused.
  • An attacker-chosen ID that does not hash to the mint's published keys → rejected by the verification in fix 2.

References

  • Disclosure: https://conduition.io/code/cashu-disclosure/
  • Short-term/long-term fix definitions quoted in the disclosure ("Improving security of keyset IDs", "keyset ID v2")
  • TollGate tracking: OpenTollGate/tollgate-module-basic-go#703 (fund-safety program, deep-dive item 7), #665 (pre-tag readiness — this audit's report)
  • Amperstrand/cashu-audit — divergence database context
Dominant language
Go
Stars
12
Forks
14
Avg merge
1d 6h
Merged PRs (30d)
217

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from OpenTollGate/tollgate-module-basic-go

All issues in OpenTollGate/tollgate-module-basic-go

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.