forgejo-admin/nuts

Fork 0

feat(nut12): deterministic DLEQ nonce derivation #368

Open

robwoodgate wants to merge 2 commits from robwoodgate/nut12-deterministic-nonce into main

robwoodgate commented

2026-05-04 12:08:53 +00:00

(Migrated from github.com)

Cashu-TS: https://github.com/cashubtc/cashu-ts/pull/638
CDK: https://github.com/cashubtc/cdk/issues/1980
Nutshell: https://github.com/cashubtc/nutshell/pull/1010

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);
});

test("the same proof used twice reveals nothing (0 = a · 0)", () => {
    // Nonce reuse alone is not sufficient, the two challenges must differ.
    // With one proof, both diffs are zero: recovery solves 0 = a · 0,
    // which every key in the field satisfies, so no information leaks.
    const sDiff = mod(proof1.s - proof1.s, n); // 0n
    const eDiff = mod(proof1.e - proof1.e, n); // 0n

    expect(sDiff).toBe(0n);
    expect(eDiff).toBe(0n);

    // invert(0, n) has no solution; recovery throws rather than
    // returning a key (BigInt has no Infinity / NaN sentinel).
    expect(() => invert(eDiff, n)).toThrow();
  });

- [x] Cashu-TS: https://github.com/cashubtc/cashu-ts/pull/638 - [ ] CDK: https://github.com/cashubtc/cdk/issues/1980 - [x] Nutshell: https://github.com/cashubtc/nutshell/pull/1010 ## 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: ```typescript 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); }); test("the same proof used twice reveals nothing (0 = a · 0)", () => { // Nonce reuse alone is not sufficient, the two challenges must differ. // With one proof, both diffs are zero: recovery solves 0 = a · 0, // which every key in the field satisfies, so no information leaks. const sDiff = mod(proof1.s - proof1.s, n); // 0n const eDiff = mod(proof1.e - proof1.e, n); // 0n expect(sDiff).toBe(0n); expect(eDiff).toBe(0n); // invert(0, n) has no solution; recovery throws rather than // returning a key (BigInt has no Infinity / NaN sentinel). expect(() => invert(eDiff, n)).toThrow(); }); ```

a1denvalu3 commented

2026-05-07 11:20:40 +00:00

(Migrated from github.com)

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

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

robwoodgate commented

2026-05-07 11:27:19 +00:00

(Migrated from github.com)

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)

> 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 commented

2026-05-07 11:32:09 +00:00

(Migrated from github.com)

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

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

👍 1

robwoodgate commented

2026-05-07 11:35:07 +00:00

(Migrated from github.com)

@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 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.

👍 1

robwoodgate commented

2026-05-07 13:29:28 +00:00

(Migrated from github.com)

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

Addressed in e57b141

> @robwoodgate I think it's an unnecessary measure and also `a` is always 32 bytes Addressed in [e57b141](https://github.com/cashubtc/nuts/pull/368/commits/e57b1412414f5686df554f4ba0cba96cd244a312)

TheMhv (Migrated from github.com) approved these changes

2026-05-19 16:56:04 +00:00

TheMhv (Migrated from github.com) left a comment

LGTM.

ACK e57b141241

LGTM. ACK e57b1412414f5686df554f4ba0cba96cd244a312

This pull request can be merged automatically.

You are not authorized to merge this pull request.

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin robwoodgate/nut12-deterministic-nonce:robwoodgate/nut12-deterministic-nonce

git switch robwoodgate/nut12-deterministic-nonce

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch main

git merge --no-ff robwoodgate/nut12-deterministic-nonce

git switch robwoodgate/nut12-deterministic-nonce

git rebase main

git switch main

git merge --ff-only robwoodgate/nut12-deterministic-nonce

git switch robwoodgate/nut12-deterministic-nonce

git rebase main

git switch main

git merge --no-ff robwoodgate/nut12-deterministic-nonce

git switch main

git merge --squash robwoodgate/nut12-deterministic-nonce