feat(nut12): deterministic DLEQ nonce derivation

[robwoodgate]

• Cashu-TS: feat(nut12): deterministic DLEQ nonce derivation cashu-ts#638
• CDK: TBC
• Nutshell: TBC

Problem

In a DLEQ proof, the mint publishes challenge and response values e and s, related by:

$$s = r + e \cdot a \pmod{n}$$

• a - the mint’s long-lived private key (from its keyset).
• r - a temporary, per-proof nonce used in the DLEQ signature.

If the same r is ever reused with two different challenges e₁ and e₂, the private key can be recovered immediately:

$$a = (s_1 - s_2) \cdot (e_1 - e_2)^{-1} \pmod{n}$$

It’s the same class of failure that affected Bitcoin Android wallets in 2013, where repeated ECDSA nonces (k) allowed attackers to derive private keys and drain funds.

Important

Current Cashu implementations are secure in practice, because they use modern CSPRNGs, such as crypto.getRandomValues() in browsers, crypto.randomBytes() in Node.

However, the current spec does not "fail safe". A poorly written RNG wrapper, re-used seed, or language-level entropy issue could silently break key safety while remaining spec-compliant.

Solution - The spec should "Fail Safe"

To remove the RNG "weak link", RFC 6979 and BIP-340 both moved from "random nonce" to deterministic nonce derivation: the nonce is derived from the private key and the signing context rather than sampled fresh each time.

This PR brings the same approach to NUT-12's DLEQ proof.

The nonce r is now derived via HMAC-SHA256, keyed on the mint's private key and bound to the proof context:

r = HMAC-SHA256(key=a, data="Cashu_DLEQ_R_v1" || A || B' || C' || ctr) mod n

Mints SHOULD use this derivation. Mints using random nonces MUST use a CSPRNG.

This is not a breaking change, as verifiers reconstruct R1 and R2 from (e, s) and never see r.

All existing proofs continue to verify.

Also adds a test vector section to tests/12-tests.md with fixed inputs and exact expected (e, s) output, so implementations can verify byte-for-byte conformance.

Proof

Here is a simplified TS proof showing how nonce reuse allows private key recoverability:

import { invert, mod } from "@noble/curves/abstract/modular.js";
import { expect, test } from "vitest";

const n = BigInt(
  "0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141",
);

const a = BigInt(
  "0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef",
);

const reusedNonce = BigInt(
  "0x4242424242424242424242424242424242424242424242424242424242424242",
);

const proof1 = {
  e: BigInt("0x1111111111111111111111111111111111111111111111111111111111111111"),
  s: BigInt("0xc49a2d11da2194415dfd54aa2a948adf95f5b1168422bb6386df3170690f28ca"),
};

const proof2 = {
  e: BigInt("0x3333333333333333333333333333333333333333333333333333333333333333"),
  s: BigInt("0xc94a02b109e0383f95737979fb391c1b82adb1d8589b0d6a5046b13fe672b499"),
};

test("reused DLEQ nonce reveals the mint private key", () => {
  // Prove s values were calculated using same private key
  expect(proof1.s).toBe(mod(reusedNonce + proof1.e * a, n));
  expect(proof2.s).toBe(mod(reusedNonce + proof2.e * a, n));

  const sDiff = mod(proof1.s - proof2.s, n);
  const eDiff = mod(proof1.e - proof2.e, n);
  const recoveredA = mod(sDiff * invert(eDiff, n), n);
  // Prove private key was recovered
  expect(recoveredA).toBe(a);
});

[a1denvalu3]

Why are we hashing the key a before inputting into the HMAC?

[robwoodgate]

Why are we hashing the key a before inputting into the HMAC?

Mostly for defense in depth - it keeps the raw scalar out of direct HMAC-key use, and ensures the HMAC key is always fixed-width 32-byte, regardless of keygen.

So just key-derivation hygiene (it doesn't add entropy or protect weak mint keys etc)

[a1denvalu3]

@robwoodgate I think it's an unnecessary measure and also a is always 32 bytes

[robwoodgate]

@robwoodgate I think it's an unnecessary measure and also a is always 32 bytes

Agree it's a bit belt and braces - am happy we just use the scalar without hashing if you think it adds nothing.

[robwoodgate]

@robwoodgate I think it's an unnecessary measure and also a is always 32 bytes

Addressed in e57b141