CIP-???? | Post Quantum signatures and native wallets

[mgajda]

This is preliminary draft for #413: PostQuantum signature primitives in Plutus and native wallets.

NIST Post Quantum Cryptography work group has selected three digital signature algorithms for standardization:

• DILITHIUM-CRYSTALS
• Falcon
• SPHINX+

Estimates for PQC migration are within next 15 years, so it those smart contracts that want PQC hardness would certainly benefit from option to check PQC signatures.

While PQC algorithms are expected to be more secure than previous generation, the main issue is the signature size (666 bytes for Falcon, 2420 bytes for Dilithium, 8080 bytes for Sphincs+).

For this reason, these signature algorithms may be chosen by long-term security applications.

Proposal would involve:

• implementing Falcon, Dilithium, and Sphincs+ as Crypto class instance,
• adding Plutus instructions to call these signature algorithms,
• providing a test "vesting" contract that releases funds after combination of signatures is given.

When additional PQC algorithms are standardized by NIST and enjoy shorter signature size, we may add these as well. (But we should not hold, since the process may take years, possibly more than estimated for migration.)

Future PQC-hardening of wallets and blockchain should be considered a sequel to this proposal.

---

(rendered proposal in branch)

[L-as]

I think we should hold off and wait for more research and stabilisation to happen in this space rather than rushing in. It's probable that more efficient solutions will appear. Trusting NIST is in general a bad idea IMO.

[mgajda]

@L-as The NIST recommends 4 PQC algorithms already, Biden administration "Quantum Computing Cybersecurity Preparedness Act" tells systems planned after July 2023 should have PostQuantum crypto.
Recent sublinear-resource quantum integer factorization algorithm may make hacking signatures practical with as little ~372 qubits.
IBM already announced 433-bit quantum computer and plans 4100 qubits by 2025.

Are you sure we will have the time for the attitude of waiting years to research an already reviewed NIST recommendations?
Waiting for further research sounds like waiting until the current signature algorithms are hacked.

We may wait for the next official NIST standard before merging implementation to production, but it would be best to have it tested by that time.

[L-as]

@mgajda I agree with this sentiment, disregard my previous comment (however, I still believe better algorithms will appear).

I however think we should support the algorithms noted natively everywhere signatures are used.

I think Cardano should as much as possible switch to a signature algorithm agnostic approach as it's likely we'll change again. Plutus should have a single verifySignature builtin, that takes an integer index to choose the algorithm. Every other part of the system should be changed similarly.

[mgajda]

@L-as It may be good idea to add a general verifySignature interface, since I sincerely hope even better signature algorithms appear. I will add this to a proposal.

This should not delay the implementation, so it is great improvement.
Of course we will need to keep existing signature verification functions with both interfaces to keep compatibility.

Please note that reviewing a signature algorithm is a lot of work, and NIST has simply provided a public venue for this review. Since review and criticisms are all public, it seems they went furthest towards proposing verified solutions.

[SebastienGllmt]

These signatures are:

• relatively expensive computationally & space-wise
• costly to implement (not just in Haskell, but every client that appears in the future)
• make it harder to replace Plutus with a ZK compute layer in the future (if there is interest in that)
• have no guarantee not to be replace by something better

So if we really want to implement one in Plutus, I would prefer if we picked one instead of all of them. However, I'm more convinced that if we want to handle PQCs in the short term, it may be better to prioritize using them in overlay networks like Mithril which is the same thing Algorand did by having Falcon-signed state proofs periodically generated for their chain.

[L-as]

I don't think it will affect verifying Cardano itself in a ZK manner. I don't think Mithril is an overlay network, it's just a stake-weighted multisignature scheme. It also wouldn't fix the issue. L1 needs to be resistant against the attacks.

[SebastienGllmt]

I don't think it will affect verifying Cardano itself in a ZK manner

Definitely it does in the same way any cryptography in a zk Plutus Core would need to be verifiable. Of course it doesn't stop you from building anything ZK that doesn't need to be isomorphic

I don't think Mithril is an overlay network, it's just a stake-weighted multisignature scheme

Sure, but this is like saying blockchains aren't peer-to-peer networks, but just a chain of cryptographic signatures

L1 needs to be resistant against the attacks.

It does in the same way State Proofs on Algorand does (which uses the same ideas as Mithril). If you mean it doesn't in the sense that individual transactions won't be secure (since state proofs are just quantum-resistant checkpoints), then I agree but I think the checkpoints are good enough to be able to kick the can a bit further down the road

[iquerejeta]

I think PQ security is something that should definitely be in the roadmap of Cardano. However, I don't see the benefit of having a post-quantum signature in plutus while the node uses traditional signatures. In my opinion it makes more sense to go the other way. First include PQ security at the node/consensus level, and then include it in Plutus.

I think the suggestion of @SebastienGllmt of doing it in Mithril is a good starting point, as it provides quantum safe checkpoints without the need of having to do massive changes in the node.

[L-as]

Mithril (the part besides the signature scheme) isn't a thing yet AFAIK, so it doesn't make sense to start from Mithril, as no CIP can reasonably be made about changing it when there isn't a design.

However, I do think we should start from the other way around, allowing all signatures everywhere in Cardano to use other algorithms by abstracting over the algorithms in question everywhere.

[iquerejeta]

Mithril isn't a thing yet

Agree, but we can say it's an ongoing effort. More info can be found here: https://mithril.network/doc/. But you are right, some design decisions are not yet established.

allowing all signatures everywhere in Cardano to use other algorithms by abstracting over the algorithms in question everywhere.

This would be a cool feature I think, and might facilitate the addition of new signature schemes for plutus in the future (or switching between signing algorithms in the ledger). But wouldn't you say we already have something like that with DSIGN?

And as I said before, I don't think it makes sense to use quantum safe crypto in plutus if the ledger does not use it. Using quantum safe crypto in the ledger is non trivial, as it might affect network capabilities, diffusion times, computational requirements by the node, etc. I'm by no means suggesting that we shouldn't move forward with PQ crypto. I'm simply saying that maybe the first step is to make a proposal as to which algorithm could be used in the ledger, and how it would affect the network.

[SebastienGllmt]

However, I do think we should start from the other way around, allowing all signatures everywhere in Cardano to use other algorithms by abstracting over the algorithms in question everywhere.

Maybe the best path for this would be to add PQ crypto to native scripts and improve account abstraction using native scripts as well

[mgajda]

These signatures are:

• relatively expensive computationally & space-wise

That is why use of PQC will be opt-in at the smart contract level.

• make it harder to replace Plutus with a ZK compute layer in the future (if there is interest in that)

That would be totally orthogonal, and such ZK layer would also have to be quantum-resistant.

• have no guarantee not to be replace by something better

This is true for all cryptography. Especially classical cryptography in the face of Quantum Computing revolution.

So if we really want to implement one in Plutus, I would prefer if we picked one instead of all of them. However, I'm more convinced that if we want to handle PQCs in the short term, it may be better to prioritize using them in overlay networks like Mithril which is the same thing Algorand did by having Falcon-signed state proofs periodically generated for their chain.

Note that Plutus initially only supported Ed25519 and Blake2. Now we see that Schnorr and EcDSA are necessary.
Why not to add all feasible implementations?

Falcon is indeed recommended, since signature length is shortest.

Maybe the best path for this would be to add PQ crypto to native scripts and improve account abstraction using native scripts as well

This is also possible, but smart contract layer is much more flexible than native scripts.
If necessary, we can consider both, but that would need more work.

Note that Mithril is a way of blockchain hardening, but not adding to smart contract or transactional capability.

This CIP is specifically about smart contracts and end-user APIs for them.

This is because smart contract APIs take much longer to migrate to new cryptography schemes than the blockchain itself.

[mgajda]

Answers to some comments above:

• @SebastienGllmt I have added native wallets as you suggested.
• @iquerejeta We now include DSIGN instance as part of this CIP.
• Security properties have been emphasised, since latest research brings uncertainty about how much time do we have to migrate.

@L-as @rphair @SebastienGllmt @KtorZ @kevinhammond @abailly Can you please review?

[mgajda]

@michael-liesenfelt Would you review too?

[mgajda]

Since it may be easier to agree on the problem statement itself, I added CPS.

Please consider it a matter of possible urgency, given that IBM plans to double the quantum computing capacity by 2025.

Please let me know if you would prefer to accept CPS separately.

[rphair]

Thanks @mgajda for updates about the relevance of this proposal.

I believe the CIP and CPS should be submitted in separate PRs mainly because, as you say, the discussion & acceptance process will be different in each case. (cc @KtorZ)

[mgajda]

@michaelpj I made my best with respect to putting both motivation (CPS, intro), and implementation (long term signature scheme).
But I badly need your review, since entire CIP part of this MR falls under CIP-0035.

@abailly Fixed markdown rendering issue just now.
I tried my best to provide links to a PQClean implementation of crypto algorithms using standard reference code published by NIST.

While exact urgency level maybe disputed, US published an order to consider PQC transition for any information systems from July 2023 on. Conservative security analysis is a necessity in cryptography, so I believe we should look into this sooner rather than later.

[mgajda]

@SebastienGllmt I have added note on native wallets. Do you believe it is sufficient?

[michaelpj]

Needs some work, there is a lot going on here and it needs to be disentangled.

I'm not against adding more cryptography primitives if there's clear need for them. I'd prefer not to have to add several if we can avoid it, it's not that easy (witness how long it took us to get the SECP stuff in).

I'm sceptical about the "extensibility" thing.

[michaelpj]

From reading this, I'm not clear what things need to change. We use signatures in lots of places. Do we need to migrate e.g. the signature scheme used for public key outputs? That would be a big deal.

I would really like to see the different cases spelled out carefully.

[mgajda]

Yes, ultimately we will need to migrate all signature schemes.

It is only Plutus that needs to migrate sooner, if we want our smart contracts to survive more than few years.

[mgajda]

@michaelpj Is it clear why we need to start migration of smart contracts and wallets even before we start migration of the blockchain?

Do you agree with the need for a gradual crypto upgrade process, and gradual migration process?

Should we include Cardano crypto team to discuss the need for such a gradual migration processes?

[michaelpj]

"Adding multiple PQC signature algorithms" is the solution, no? Can you specify the usecases without reference to the solution?

[mgajda]

Problem: "pre-quantum signature algorithms will ultimately get hacked".

What other solution may there be than replacing them?

[michaelpj]

who is complying here? smart contract developers?

[mgajda]

Smart contract developers and dApp authors in general.

[mgajda]

Suggested change

	* compliance with US government regulations past July 2023, when all agencies
	* compliance of smart contracts with US government regulations past July 2023, when all agencies

[michaelpj]

Again I'm confused about what we're talking about: are we talking about signature verification in scripts, or in the blockchain, both? I'm lost.

[mgajda]

You are right. The "fast migration" item should be moved to CIP.

Suggested change

* allow fast migration of entire blockchain to post-quantum resistance when it becomes necessary.

[michaelpj]

Is this the "Implementation Plan"? I think there should be more steps.

Also you probably want to also write the "Acceptance Criteria"

[iquerejeta]

Could we extend this section to describe how having post quantum plutus scripts is of any benefit if consensus and ledger layer are still vulnerable? Maybe you could describe an example were having quantum safe crypto in a script would protect the funds/UTxO from a quantum adversary.

It's something I can't get my head around. How a quantum safe plutus validator can help protect a quantum vulnerable (don't know if this is a term) UTxO.

[L-as]

You can lock your funds in a quantum secure way. No one can steal your funds, until Ouroboros Leios happens, because controlling even all stake won't let you do invalid things.

[L-as]

Even then, it will be obvious that it was done illegally, and will be trivial to revert.

[mgajda]

@iquerejeta Quantum and wallet scripts will need much more time to migrate.
We can do ledger and consensus migration as a last step, since they do not change API.

Post-quantum migration is a major effort, and we should consider it both as technical and social challenge.

[mgajda]

@L-as Concern about old generation of signatures is that Quantum Computing can hack them in the foreseeable future, so we need PQC wallets to protect against it.

Migration to PQC wallets will take some time, so it would be nice to provide PQC wallets even before entire blockchain is PQC-protected.

[L-as]

Is this CIP worth it when users can lock their funds in a quantum-resistant way using Plutus?
It currently doesn't matter much for consensus, because all consensus does is prevent double-spending.
If someone takes over a majority of the stake and does a double spend, we'd notice and move swiftly without any issue.
SPOs would have their funds locked in a quantum-resistant way, even though the address they stake to isn't.
With Leios, now we rely on the stake to validate logic too, however, there is very likely to be at least one node that notices something is off, meaning that the community will switch to a quantum-resistant Cardano, retroactively undoing any transaction that was illegal.

The issue remains that most people aren't storing their funds in a quantum-resistant way. Wallets should support it, and such a script needs to be developed. It would likely depend on bitwise operations (IntersectMBO/plutus#4733), which we don't have yet. A bigger problem is that Plutus discriminates scripts from PKHs, and most scripts only work with PKHs, meaning that most dApps will be inaccessible to such users. This is however not a reason to support quantum-resistant signature schemes, rather, we should fix Plutus.

[MicroProofs]

I think if quantum resistance went to being in Plutus only the major issue that comes up is "what about collateral?"

Collateral requires a vkey signer and currently any ada held to be used as collateral would be susceptible to a quantum attack. I don't have an answer, but it's something that points toward a quantum vkey being essential unless we rework collateral.

[SebastienGllmt]

@MicroProofs I agree, which is why I made this comment originally. I think if we were to introduce PQC in would have to be part of a larger discussion on account abstract

However, I do think we should start from the other way around, allowing all signatures everywhere in Cardano to use other algorithms by abstracting over the algorithms in question everywhere.

Maybe the best path for this would be to add PQ crypto to native scripts and improve account abstraction using native scripts as well

In an ideal world, we could solve the problem through #749 because you could then encode the PCQ as a Plutus script and then have your account abstraction by using a native script whose execution depends on a Plutus script (that could delegate verification to a PCQ verifier).

It doesn't quite work because although currently native scripts can't pay collateral, there is no reason why they shouldn't be able to in the current implementation of Cardano. This possibility gets hampered a bit with #749 because if you native script depends on a Plutus script, it can't pay collateral anymore

That is to say, I think if we want proper abstraction while still keeping #749, we would need a version of #749 that works with ZK proofs of Plutus execution because that way you could have a native script paying collateral while using a ZK proof of PCQ verification (but now you run into a new problem where you need your ZK proof system to be post-quantum secure such as STARKs, but Cardano in its current form is more friendly to STARKs anyway)

[mgajda]

@MicroProofs The goal was to have "soft integration" schedule for PQC into Plutus, which is easier than migrating entire blockchain.

First we integrate PQC code as an option for smart contract, dealing with collateral and migration of user accounts later.

[mgajda]

@L-as

Is this CIP worth it when users can lock their funds in a quantum-resistant way using Plutus?
(...)

Our goal is to enable choice of signature mechanism for Plutus Smart Contracts, so that migration from current signature schemes to PQC signature schemes can be done gradually.

Otherwise PQC would imply obsoleting old signatures overnight, without providing an alternative.

[mgajda]

@rphair Is there any hope that this CIP will get a number assigned soon?
Given Mithril, is it something that will be supported within CIP process?

[rphair]

@mgajda since it's coming up to a year since the last community review I would be in favour of adding it to the next CIP meeting agenda but there's still the pending question about separation between

👉 an implementation oriented CIP (which will be hairy: as @michaelpj points out (#441 (comment)) a complete overhaul of the cryptography chain) and

👉 a CPS for the general problem: especially if as @SebastienGllmt says in #441 (comment) there are multiple signature algorithms to consider, plus different approaches to handling this in Core and/or Plutus first, etc.

I would be in favour of giving this a number as soon as the material can be divided between a CIP and CPS since we have to set the CIP scope properly first. You had offered to do this in #441 (comment) "as soon as a preliminary review is made" ... we have that in #441 (review) and though some of @michaelpj's points have been might have been answered, many of these comments haven't been answered and I personally can't tell whether they've all been answered in the document.

The document actually has some CPS sections in it like Use Cases so even editorially it needs to be "disentangled" between problem statement & the actual proposal for improvement. Could you proceed by decomposing this into a separate CIP and CPS (with another PR for the separated material) that takes into account @michaelpj's last review?

We have an editor's meeting coming up later tomorrow (https://hackmd.io/@cip-editors/82) and if the documents are ready, the agenda seems light so we should have time to discuss it there. But as generally agreed there is no rush so feel free to take more time & we would make space for it at the following meeting.

[Ryun1]

Hey @mgajda!

Thanks for this pull request
this was reviewed in CIP editors call # 82
In order for this proposal to progress we will require that this PR is split into two, one for the CPS and one for the CIP.
Furthermore, please do adhere to the template provided (here) as well guidance outlined within CIP-0001.

[rphair]

@mgajda are you still pursuing this? Marking Waiting for Author in the hope of keeping this moving forward.

[rphair]

NIST progress posted in last month: NIST Releases First 3 Finalized Post-Quantum Encryption Standards

@mgajda after not hearing from you for a couple months, this submission might be considered Abandoned. Even if it's closed that way (if continuing not to have any progress or updates from you, especially the consideration of this work as a CPS rather than a CIP due to the perceived time frame & current uncertainty), we would welcome you opening this up again or (you or other author) submitting a newer work once more is known about the subject.