CPS-0027? | Approaches to Post-Quantum Signatures

[kozross]

This CPS attempts to take a small bite out of the overall problem of making Cardano post-quantum secure. Specifically, it discusses making post-quantum digital signatures available to script developers by way of one (or more) builtins to verify such signatures.

Rendered

[rphair]

Thanks @kozross for reopening this problem space which hasn't seen a word in the CIP repository since:

• #413
• #441

Tagged Triage for introduction at next week's Tuesday CIP meeting (authors always encouraged to attend & everyone is invited): https://hackmd.io/@cip-editors/127

[rphair]

@Ryun1 please post what you think about use of TBD as a value here, instead of the ? called for by CIPs 1 & 9999, as you are going through #989 & related formatting massage... since your validator will run on CIPs & CPSs before merge.

Especially since the ? would have to be \ escaped to be valid YAML (and look ugly) I would rather admit other terms that the author wishes to write here as a placeholder... and possibly add TBD to a short list of placeholders suggested in CIPs 1 & 9999.

@kozross I would be happy to admit the TBD here & please forgive addressing this question in this thread for simplicity's sake.

[kozross]

The main reason I used TBD as such is exactly because ? broke YAML formatting on its own. I'm not attached to it either way.

[rphair]

@kozross before further review this file also needs to be renamed from CPS.md to README.md.

[kozross]

@rphair - thanks for the feedback! I've addressed everything, including renaming the file. Also thank you for directing me to the older issue and PR related to this topic: I will have a read of them and see if they bring up anything I should mention.

[rphair]

@kozross really looking forward to this PR & CPS bringing together past, present & future work on this 🙏

In that regard I also think this CPS title could be made more "open" or like a survey, rather than something suggesting a document providing the signatures... a bit like I tried to point out here for your other submission: #1143 (review) ... We can try to brainstorm some titles perhaps better for a CPS than a CIP on the subject, if possible without making the title too wordy, online & at the next CIP meeting.

[kozross]

Some feedback on a better title would be great. I have no experience in CPSes, only in CIPs, and would be happy to accept any help there.

[rphair]

OK @kozross how about to kick-start the discussion we leave a mediocre title in place which invites the reader & reviewer to come up with something better... rather than the current Post-quantum digital signatures with the known defect that it suggests the document presents a solution.

A working title Approaches to ... would reflect the similar uncertainty to #1143 and perhaps any better choice of words, or means of suggesting possible solutions, would apply to both during the concurrent review of these CPSs that will likely follow. So I'll set that title on this PR in the meantime and we can continue accumulating feedback here...

[rphair]

Suggested change

	Title: Post-quantum signatures
	Title: Approaches to Post-Quantum Signatures

(other candidates welcome: here & at upcoming CIP meeting)

@kozross I'm hoping it's OK to drop the word Digital here for the sake of generally required brevity because it's understood from the blockchain context (vs. "paper" signatures, "analog" signatures, etc.)... please correct me if wrong.

[kozross]

That seems fine to me. It's definitely clear from the context.

[perturbing]

@hjeljeli32 , could you be so kind as to review this and share your opinion on such a transition strategy? Loved your presentation in Porto about it; I think your view will be valuable here!

[perturbing]

Some feedback on a better title would be great. I have no experience in CPSes, only in CIPs, and would be happy to accept any help there.

I always approach a CPS with the mentality of a review paper; it tries to get an overview of what is and where things are heading (and how it is blocked).

A good CPS that I really like is this one, credits to @nhenin and @rrtoledo

[kozross]

@perturbing - that's a great suggestion, thank you! I'll have a read of the provided link.

[hjeljeli32]

@hjeljeli32 , could you be so kind as to review this and share your opinion on such a transition strategy? Loved your presentation in Porto about it; I think your view will be valuable here!

Thanks for tagging me, @perturbing. Much appreciated! I’m really glad to see this problem space being revisited, and excited about the direction toward quantum-ready signatures in Cardano. I’ll review the CPS in detail and share feedback later today.

[hjeljeli32]

This CPS is very well framed and clearly motivated. The direction it takes feels both timely and thoughtful, and it reads as a solid first step toward post-quantum readiness for the Cardano ecosystem. I’ve left a few small, optional suggestions above. Thank you for taking the initiative on this.

[perturbing]

IMO; we need a CPS that covers and indexes all attack surfaces for when a QC hits the scene, so I do not think it is just a plutus problem. As an overview

• For Praos we have a KES key, which under the hood uses a tree of keys on the ed25519 curve
• The cold key that ultimately binds a stake pool also uses keys from the ed25519 curve.
• The VRF that we use for Praos leadership selection is also using the ed25519 curve
• Then we have in plutus various built-ins that use curves that will break (ecds/schnorr over Secp256k1, and bls pairing crypto).
• the security of our hash functions will also be halved (Grover's algorithm), so we would need to go from sha256 -> sha512 for example, in all places (probably the easiest fix, though block/tx hashes will get bigger)

As you can see, if we get a quantum computer, our consensus and settlement layer will probably be attacked first, so the problem is wider.

But from this overview we also see what kind of quantum tools and construction we will need (not only signature schemes); we will also need a VRF, KES construction, and most likely some quantum secure ZK scheme.

A complex problem with many open questions. And from a presentation that @hjeljeli32 gave once, I think the best we can do now, is redesign our code base that we can swap in and out our underlying crypto primitives (which is also probably not trivial). This way, we can adapt ourselves to new schemes that pop up, but research needs to drive this solution space.

[perturbing]

Given this broader context, another open question is; given that QC has broken the above schemes, how can we ensure that bootstrapping nodes follow the right chain?

E.g, QC breaks the forward security of the KES keys that sign blocks

[kozross]

I don't disagree with any of this - in fact, I agree very strongly! However, the sheer magnitude of this problem means that no single CPS will cover it reasonably. In fact, the last one that tried got severely bogged down in details and ended up not progressing as a result.

The reasons behind why we (meaning 'MLabs') wanted to focus on a specific case of post-quantum security was to prevent exactly this kind of scope blowout and death by details. Specifically, we tried to make for a CPS such that:

• It addresses post-quantum security with regard to Cardano somehow;
• The scope is well-defined, allowing a CIP or at least an action plan without death by detail;
• Any potential solution could be used to inform further work, whether it's by choice of implementation, research required, resources expended, etc.

It's not that we feel this is necessarily the only, or even the most important, task or set of questions, merely the one we feel most able to tackle in future work (and want feedback on), and the one residing in the area we understand best (as MLabs are responsible for the implementation of quite a few builtins, including CIPs and working with Plutus Core maintainers).

Does this help answer your questions?

[rrtoledo]

Thanks a lot for the CPS!

PQC is quite a tricky subject as there is not obvious, perfect solution. You detail here the reasons why we need to tackle this issue and finish by saying which digital signatures schemes would be broken and suggesting selecting one to many PQ resistant schemes.

I would go a bit farther, as @hjeljeli32 and @perturbing already mentioned, and add some other problematics such as transitionning, long term attacks, and potential impacts on the blockchain (necessity to have larger blocks, required hardware...). One, if not perhaps the most, contentious point will be the calendar: when should we start using PQC and depreciating current cryptography? Another one would be regulation: is it acceptable to use exotic cryptography or should we focus on standardized schemes (e.g. NIST candidates such as Crystal-Dilithium).

You are focusing in this CPS on digital signatures, but we may be using other assymetric cryptography algorithms, or require specific properties, that would be broken, and potentially whose PQ resistant solutions are not designed yet (VRF, multi-signatures, VDF perhaps...). I am not sure however if having one generic CPS for all PQ questions would better than distinct ones for each subject.

[perturbing]

I am not sure however if having one generic CPS for all PQ questions would better than distinct ones for each subject.

I think a CPS for the initial problem space is wanted. Having a clear overview of what needs to be replaced and what constraints are current there (like time/space wise) are already of big value!

[kozross]

@rrtoledo - again, I disagree with none of this. The problem space is enormous, and potentially affects a great many things. However, we at MLabs feel that writing one huge CPS that tries to address everything will end up overly general and just get bogged down.

You can check my reply to @perturbing for further thoughts on this subject.

[kozross]

@hjeljeli32 - I have addressed your feedback, and left some follow-up questions as well. Thanks for the review!

[rphair]

@kozross this was considered a well researched production at the CIP meeting today and continued the immediate interest from online review. This was a packed meeting and conversation didn't turn to signature algorithms or families so I hope can tag others who can provide review suitable for the long-term consideration of this CPS.

The technical reservations were somewhat the same as #1143 in the questions of costing. As in your other PR I don't think costing is so much a CPS as a CIP requirement (cc @perturbing @colll78) and likely not as much an issue for signatures as for the concurrent homomorphic problem.

If you do think that costing is an issue that CIPs will face, perhaps you can do some preliminary research about the actual costing beyond just relative comparisons of computational expense. In the meantime I hope general Plutus reviewers would be interested in commenting on this (I don't have a corresponding list of cryptography reviewers): cc @zliu41 @effectfully @kwxm @MicroProofs

Please change the containing directory to CPS-0027 and update the "rendered" link in your original posting 🎉

[kozross]

@rphair - Thanks for this! Costing this should be pretty easy in principle, as it'll follow the same model(s) as used by existing builtins. The challenge here is more minimizing what this cost is, both in terms of the builtin to verify the signed message, but also the size(s) of the verification key and message we would need.

Edit: Made your requested changes.