[ZIP 2005] Quantum Recoverability

[daira]

This is the discussion issue for draft-ecc-quantum-recoverability (to be ZIP 2005).

[AntoineRondelet]

Small comments on the ZIP, in no specific order:

• https://github.com/zcash/zips/blob/main/zips/draft-ecc-quantum-recoverability.md?plain=1#L1340-L1342

$\mathsf{H^rcm}$ should be $\mathsf{H^{rcm}}$, i.e. surround rcm by {}.

• There seem to be some inconsistent notations between noterepr, note_repr and note. Why not use the same notation everywhere?
  • https://github.com/zcash/zips/blob/main/zips/draft-ecc-quantum-recoverability.md?plain=1#L1166-L1168 -> uses note
  • https://github.com/zcash/zips/blob/main/zips/draft-ecc-quantum-recoverability.md?plain=1#L1262-L1268 -> use noterepr
  • https://github.com/zcash/zips/blob/main/zips/draft-ecc-quantum-recoverability.md?plain=1#L934-L936 -> uses note_repr

I guess using noterepr in https://zips.z.cash/draft-ecc-quantum-recoverability#repairingnotecommitments and using note_repr in https://zips.z.cash/draft-ecc-quantum-recoverability#proposedrecoveryprotocol is ok given that they're both defined in each section, but using note in https://zips.z.cash/draft-ecc-quantum-recoverability#informalsecurityargument seems off given that it isn't defined defined there AFAIK - hence why I think using a single notation across the doc for note_repr makes more sense.

[AntoineRondelet]

Some additional comments in no specific order (last version checked: 29/11/2025)

• In the FROST section (https://zips.z.cash/draft-ecc-quantum-recoverability#usagewithfrost)

This ZIP further constrains FROST key generation for Orchard as follows: participants MUST privately agree on a value sk, and then use it with use_qsk=true to derive nk, qsk, qk, and (using the ak output by the DKG protocol)

When I look at the recovery protocol (highlight is mine...):

AFAICT, ak is known to all FROST participants (who own shares of the corresponding ask). Here given that we assume that all participants agree on the value for sk, the only thing preventing ANY FROST participant (instead of the threshold number of participants) from recovering the funds is RedDSA, right?

• Also: How are FROST participants supposed to agree on the value of sk? Using some DKG here again? Is that left "as an implementation detail?"

---

• In "Informal Security Argument" (https://zips.z.cash/draft-ecc-quantum-recoverability#informalsecurityargument)

There are two cases depending on use_qk [...]

The two cases described below are for use_qk = 0. The part below

Should be for use_qk = 1, right?

• In "Orchard Key Components" (https://zips.z.cash/draft-ecc-quantum-recoverability#%C2%A74.2.3%E2%80%98orchardkeycomponents%E2%80%99)

AFAICT the 2 last bullets should be nested under the first (not on the same level) - no?

• I think there's a typo in the blurb below (it's written H^{rivk_ext}_q, shouldn't it be H^{rivk_ext}_{qk}?

• Nitpick: AFAICT use_qk is defined as a bit in the circuit (0 / 1) while it's used as a boolean in most of the ZIP (true / false). These are obviously "logically equivalent", but I'm wondering if we should aim for type consistency across the doc, in which case logical expressions like use_qk => P and \not use_qk => Q can be turned into (use_qk == 1) => P (where == is a predicate taking 2 arguments of the same type and testing their equality, then returning true / false) etc. Otherwise, if we stick to bits (0 / 1) then the circuit can be expressed as smthg like (use_qk) * (P) + (1 - use_qk) * (Q) provided that use_qk is properly constrained to being a bit - but then we start arithmetizing.. so seems more appropriate to stick to logical expressions (and maybe just say "we use bits and booleans interchangeably" to make it crystal clear that we're implying a type conversion from Bit to Boolean when we use use_qk in expressions like use_qk => P. Again it's a nitpick...

[daira]

ZIP 2005 should reference #895 for the changes to ZIP 312, not #883.

[daira]

@AntoineRondelet wrote:

AFAICT, ak is known to all FROST participants (who own shares of the corresponding ask). Here given that we assume that all participants agree on the value for sk, the only thing preventing ANY FROST participant (instead of the threshold number of participants) from recovering the funds is RedDSA, right?

That is correct. There's no way to do better without having a post-quantum multisig scheme available now.

Also: How are FROST participants supposed to agree on the value of sk? Using some DKG here again? Is that left "as an implementation detail?"

This will be resolved in #895.

• In "Informal Security Argument" (https://zips.z.cash/draft-ecc-quantum-recoverability#informalsecurityargument)

There are two cases depending on use_qk [...]

The two cases described below are for use_qk = 0. The part below

Should be for `use_qk = 1`, right?

Yes.

• In "Orchard Key Components" (https://zips.z.cash/draft-ecc-quantum-recoverability#%C2%A74.2.3%E2%80%98orchardkeycomponents%E2%80%99)

AFAICT the 2 last bullets should be nested under the first (not on the same level) - no?

Yes.

• I think there's a typo in the blurb below (it's written H^{rivk_ext}_q, shouldn't it be H^{rivk_ext}_{qk}?

Yes.

• Nitpick: AFAICT use_qk is defined as a bit in the circuit (0 / 1) while it's used as a boolean in most of the ZIP (true / false).

$\mathsf{true} = 1$ and $\mathsf{false} = 0$, so technically there is no type inconsistency. But yes this should be made consistent.