ML-DSA signatures in CCF

[maxtropets]

Dumping here my investigation results so far

• Signing with ML-DSA-44 goes ~10x slower than a regular EC384 signature, but verification is roughly the same - 1.2x slower.
• Option A
  • Reuse current Dual/COSE signing, but replace COSE_alg and use different COSE key.
  • Implies much less work on CCF KV, but brings in extra changes for the service/node keys infrastructure.
• Option B
  • Have extra COSE-PQC signature alongside the current Dual/COSE
  • Requires some table re-org which we wanted to do anyway
  • Not clear how to trust/distribute signing/verification keys
    • For replication, we can distributes via node-to-node channel
    • But for audit?
• A/B?
  • A makes more sense as a complete replacement, if the application want to be fully quantum resistant
  • B will be more of an add-on, to protect certain parts of the system (ledger integrity, for instance)

[achamayou]

A is a non-starter because it would mean that we would stop producing EC COSE signatures and break existing SCITT relying parties. Compatibility with Dual is not required, but COSE EC + COSE PQ is necessary for the foreseeable future.

I am wary about table re-org, I would have thought that we could just add a new key to the existing one.

[maxtropets]

I am wary about table re-org, I would have thought that we could just add a new key to the existing one

Current SIGNATURES / COSE_SIGNATURES are single value tables, they have no keys, so there's compatibility work required anyway

[achamayou]

That's what it looks like type-wise, but really (i.e. when serialised) they have a single key, a size_t 0.

[achamayou]

Ideally btw what we have is configurable PQC signatures, which support ML-DSA only at first, but can be set to other values later on as well. See the curve_id setting for node keys (except here it's for the PQC service identity).