NUT-11: length-frame the SIG_ALL message aggregation

[robwoodgate]

• Cashu-TS - feat(crypto): sign SIG_ALL over the length-framed NUT-11 message cashu-ts#811
• Nutshell - feat: verify and sign the length-framed NUT-11 SIG_ALL message nutshell#1088
• CDK - feat: verify and sign the length-framed NUT-11 SIG_ALL message cdk#2232

This PR re-encodes the NUT-11 SIG_ALL message aggregation to the domain-separated, length-framed byte format already used by NUT-20/29, and adds canonical test vectors.

msg_to_sign = b"Cashu_SigAllSig_v1"
              || len32(quote) || quote
              || for each input i (in request order):
                   len32(secret_i) || secret_i
                   || len32(C_i)   || C_i
              || for each output j (in request order):
                   len32(amount_j) || amount_j
                   || len32(B_j)   || B_j

Notes:

• The quote id is framed directly after the tag and is empty for a swap (len32(quote) = 0), so one layout serves both transaction types and a swap message can never collide with a melt message: the first framed field is always the quote, and a real quote id is never empty.
• Amounts are canonical minimal big-endian bytes and points are raw bytes, exactly as in NUT-20/29. The output keyset id remains unbound, also as in NUT-20/29: it is already pinned by mint invariants (outputs from active keysets only, one unit per transaction), and leaving it out keeps pre-signed transactions valid across keyset rotation.
• A new normative signature validation rule makes the transition workable: mints MUST ignore signatures that do not verify and MUST count unique public keys with valid signatures towards thresholds. Wallets can then include signatures over several message formats in one witness while mints upgrade independently.
• Canonical message vectors, including signatures by the well-known test key, are added to tests/11-test.md and are pinned byte-for-byte in the three implementation PRs above.

EDIT:

Have removed the legacy MTS which does not bind amount from the implementations.

This PR actions for CTS: cashubtc/cashu-ts#947

CDK and Nutshell PRs above edited to remove the legacy signing

[KvngMikey]

I think we can explicitly also state that:
A mint MUST NOT accept any SIG_ALL message format that fails to bind the quote, all input secret+C, and all output amount+B_.
Otherwise a naive mint could read "ignore what doesn't verify" as "accept any historical format," reintroducing amount malleability.

[robwoodgate]

I think this is a decision we need to make - Nutshell only recently adopted the current MTS (with amount, B_) in the latest releases and CDK adopted from v0.14.0.

I agree that keeping the legacy MTS around longer than needed is not ideal. it should be dropped asap.

I don't think the spec needs to change necessarily - ignoring sigs that do not verify is "enough" to allow historic support by policy. Mints should then just (for example) accept latest and most recent MTS for a few versions.

[robwoodgate]

For avoidance of doubt - I'm saying the spec should (as it does now) just specify the current MTS, and the mint implementations should make policy as to which previous versions they support and for how long.

My recommendation would be current ('v0') and the proposed 'v1' only, the legacy MTS should be dropped unilaterally. SIG_ALL is a pretty niche feature, so I think the benefit of dropping it outweighs the inconvenience to older wallets.

[KvngMikey]

here we say secret_i is "UTF-8 bytes of the input's unescaped secret string."
the current Nutshell implementation signs p.secret.encode("utf-8"), whether that's escaped or unescaped depends on the Proof model's internal representation and CTS may store it differently. This can make signatures just fail to verify with no obvious cause.

i think we can add one canonical vector whose secret contains a character that differs between escaped/unescaped JSON (a /, a unicode escape, a quote), so CTS, CDK and Nutshell can't quietly disagree.

[robwoodgate]

The test vectors show the canonical MTS bytes and the escaped proof structs. A mismatch with escaping would produce different bytes and would be obvious?

eg:

"secret": "[\"P2PK\",{\"nonce\":\"859d4935c4907062a6297cf4e663e2835d90d97ecdd510745d32f6816323a41f\",\"data\":\"0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798\",\"tags\":[[\"sigflag\",\"SIG_ALL\"]]}]",

contains backslash characters, from escaping secret for wire.

[robwoodgate]

Here is a worked collision under the old unframed transcript that length-prefixing removes

The old transcript concatenates str(amount) || B_ per output with no delimite: a leading digit of one amount can migrate across the boundary into the neighbouring blinded point. Both points below are valid compressed curve points.

Two output allocations, both summing to 205:

• approved: [(2, 0202c96265458f975a9389e7ff3fd6d11052cec5076711adad0664b2404a112286), (203, 038ec853d65ae1b79b5cdbc2774150b2cb288d6d26e12958a16fb33c32d9a86c39)]
• reallocated: [(202, 02c96265458f975a9389e7ff3fd6d11052cec5076711adad0664b2404a11228620), (3, 038ec853d65ae1b79b5cdbc2774150b2cb288d6d26e12958a16fb33c32d9a86c39)]

Both produce the byte-identical output transcript:

20202c96265458f975a9389e7ff3fd6d11052cec5076711adad0664b2404a112286203038ec853d65ae1b79b5cdbc2774150b2cb288d6d26e12958a16fb33c32d9a86c39

So a single signature over the approved allocation also authorises the reallocation, moving value to a different blinded output while conservation still holds. Under the v1 framing in this PR (len32(amount) || amount || len32(B_) || B_) the two allocations produce different messages, so the collision goes away.

Note this specific example uses non-power-of-2 amounts; against a mint that only issues power-of-2 denominations I could not construct a collision (searched the two-output case up to 2^64), but denominations are not mandated by the protocol, so the framing closes it regardless.