Proposal: Quanton (Post-Quantum Cryptography on Canton)

Thank you for your proposal.

• The proposal appears to be the development of a custom library implementing the PQC algorithms (one per milestone). However, many of the existing public libraries are already implementing PQC ciphers i.e. OpenSSL, Java JCE, so why not use these instead of a proprietary implementation? The testing to NIST KAT appears to be only necessary to validate the custom library.
• The proposal does not explain how the implementation will stop the need for party migration or the impact on the protocol. How do you propose to take the existing EC key and associated namespace and not change this?
• The statement on encryption underplays the concerns of store-now-decrypt-later. Whilst the current data on ledger may not have a long lifespan value, cracking the underlying key sharing aspects would put in at risk. This is just as much at risk as the signing portion
• The current expectation is that TLS security (specifically merkle tree certificates) will also not be standardised until Q3 2027 and PKI issuers like LetsEncrypt will not be issuing soon. This is also a key part of data in-flight protection.
• It would help to have clearer details on which jurisdictions are requiring other PQC standards, particularly if any of mandating any non-NIST standards.

Estimates for the uplift of PQC come in at lower engineering effort than proposed here.

The proposal does not define the license terms that this would be delivered under. Generally the expectation is that this is APACHE2 or equivalent.

Thank you for the detailed review. Addressing each point:

1. Why not existing PQC libraries? We are not reimplementing ML-DSA from scratch. The cryptographic core builds on vetted implementations (Bouncy Castle PQC, liboqs via JNI, or Botan, depending on what fits Canton's JVM model best). The engineering work is the Canton-specific integration layer: Daml-callable verification interface, benchmarking against Canton's actual transaction processing model, hash function optimization (SHAKE vs. Keccak-256), and KAT validation scoped to Canton's deployment configurations.

2. Key migration and namespace preservation Scoped out intentionally. This proposal delivers verification; migration is a separate follow-up. The mechanism is published. Our FC 2026 paper (eprint 2025/1368) describes a dual-mode construction where a one-time on-chain attestation binds a new PQ verification key to the existing account. No address change, no asset transfer, no namespace disruption. Validators accept both classical and PQ-authenticated transactions during the transition. The verification library here is what makes that attestation verifiable. Happy to walk through the details over a call.

3. Encryption and SNDL We do not dismiss encryption risk. We argue for sequencing. Encrypted data has a time buffer (ciphertext value degrades). Signatures have none: a forged transaction authorization is exploitable the moment a CRQC exists. Both need addressing; signatures are the correct first priority. We can add an optional Milestone 4 covering PQ key exchange evaluation if the committee prefers to make the encryption commitment concrete.

4. TLS and Merkle tree certificates Agreed on the Q3 2027 timeline for PQ certificates. Two distinctions: hybrid PQ key exchange (X25519Kyber768 in TLS 1.3) is deployable today and does not depend on certificate PQC. And this proposal addresses application-layer transaction authentication, not transport-layer data-in-flight. A forged transaction signature is a consensus-level event. Both layers need PQC; they are different attack surfaces requiring different solutions.

5. Jurisdictional requirements Concrete divergence across NIST-standardized signature schemes:

• CNSA 2.0 (NSA/US): ML-DSA (high security, e.g., ML-DSA-87) as the mandatory baseline. Does not include SLH-DSA in the CNSA suite, but defines a constrained profile rather than the full set of acceptable PQ schemes.
• BSI (Germany): ML-DSA (Levels 3/5) and SLH-DSA. Emphasizes SLH-DSA (hash-based) for long-term and high-value signatures due to conservative security assumptions.
• ANSSI (France): ML-DSA, FN-DSA (Falcon) Levels 3/5, and SLH-DSA. Maintains a diversified portfolio including lattice and hash-based schemes.
• NCSC (UK): ML-DSA, SLH-DSA, and stateful hash-based schemes (LMS/XMSS) for specific use cases. Focus on flexibility and crypto-agility rather than a single mandated scheme.
• ASD (Australia): Aligns with NIST PQC (including ML-DSA) with a migration target around 2030. Emphasizes transition planning and interoperability over prescribing a single scheme.

A Canton participant under BSI guidance may prefer or require SLH-DSA for long-term or high-value signatures, while one operating under CNSA 2.0 is expected to use ML-DSA (e.g., ML-DSA-87) within that profile. FN-DSA (Falcon) addresses compact signature use cases and is explicitly included in ANSSI guidance. No jurisdiction we are aware of currently mandates non-NIST PQC signature schemes for general-purpose use, although some national programs (e.g., Korea’s KpqC selections) exist and may be adopted domestically.

6. Engineering effort Open to discussing budget structure. We can restructure around two milestones (ML-DSA + SLH-DSA combined, then FN-DSA + documentation) if that better matches expectations.

7. License Apache 2.0. Will add explicitly to the revised proposal.

Some further comments below

Edward Newman CISO Digital Asset https://digitalasset.com/, creators of Daml https://daml.com/

On May 4, 2026, at 8:25 AM, Soundness Labs @.***> wrote:

SoundnessAdmin left a comment (canton-foundation/canton-dev-fund#222) https://github.com/canton-foundation/canton-dev-fund/pull/222#issuecomment-4371010378 Thank you for the detailed review. Addressing each point:

1. Why not existing PQC libraries? We are not reimplementing ML-DSA from scratch. The cryptographic core builds on vetted implementations (Bouncy Castle PQC, liboqs via JNI, or Botan, depending on what fits Canton's JVM model best). The engineering work is the Canton-specific integration layer: Daml-callable verification interface, benchmarking against Canton's actual transaction processing model, hash function optimization (SHAKE vs. Keccak-256), and KAT validation scoped to Canton's deployment configurations.

Please could you clarify whether your intent is to add crypto primitives to the Daml language or to the underlying Canton protocol. In general for the former we have offer a language primitive for signature verification and not for signing. This is mainly becuase the majority of cryptographic concerns are abstracted aware from the developer and it also requires that the execution of Daml is deterministic.

2. Key migration and namespace preservation Scoped out intentionally. This proposal delivers verification; migration is a separate follow-up. The mechanism is published. Our FC 2026 paper (eprint 2025/1368) describes a dual-mode construction where a one-time on-chain attestation binds a new PQ verification key to the existing account. No address change, no asset transfer, no namespace disruption. Validators accept both classical and PQ-authenticated transactions during the transition. The verification library here is what makes that attestation verifiable. Happy to walk through the details over a call.

Your paper assumes that the EdDSA seed key is available and that you construct a ZKP linking the seed to the PQC key. The expectation is that the majority of users are using a ECDSA key pair and thus the seed is not available. For those using EdDSA, there is also a belief that the original sed is not retained today. So the implementation the ZKP you would need to migrate users to EdDSA (the less common use today) and capture a seed key to then use for PQC.

The current protocol semantics already support classical and PQC vairants as the various parts of the protocol are driven by one side (i.e. signatures are defined by singer and the receiver just needs to support all sender algorithms and the topology TX for the signing public key; encryption is the recipient topology, etc)

3. Encryption and SNDL We do not dismiss encryption risk. We argue for sequencing. Encrypted data has a time buffer (ciphertext value degrades). Signatures have none: a forged transaction authorization is exploitable the moment a CRQC exists. Both need addressing; signatures are the correct first priority. We can add an optional Milestone 4 covering PQ key exchange evaluation if the committee prefers to make the encryption commitment concrete.

4. TLS and Merkle tree certificates Agreed on the Q3 2027 timeline for PQ certificates. Two distinctions: hybrid PQ key exchange (X25519Kyber768 in TLS 1.3) is deployable today and does not depend on certificate PQC. And this proposal addresses application-layer transaction authentication, not transport-layer data-in-flight. A forged transaction signature is a consensus-level event. Both layers need PQC; they are different attack surfaces requiring different solutions.

We are evaluating other hybrid schemes for encryption (i.e. XWing) key exchange. I more raise TLS as an example of other dependencies that need to be planned to fully be PQC secure.

5. Jurisdictional requirements Concrete divergence across NIST-standardized signature schemes:

CNSA 2.0 (NSA/US): ML-DSA (high security, e.g., ML-DSA-87) as the mandatory baseline. Does not include SLH-DSA in the CNSA suite, but defines a constrained profile rather than the full set of acceptable PQ schemes. BSI (Germany): ML-DSA (Levels 3/5) and SLH-DSA. Emphasizes SLH-DSA (hash-based) for long-term and high-value signatures due to conservative security assumptions. ANSSI (France): ML-DSA, FN-DSA (Falcon) Levels 3/5, and SLH-DSA. Maintains a diversified portfolio including lattice and hash-based schemes. NCSC (UK): ML-DSA, SLH-DSA, and stateful hash-based schemes (LMS/XMSS) for specific use cases. Focus on flexibility and crypto-agility rather than a single mandated scheme. ASD (Australia): Aligns with NIST PQC (including ML-DSA) with a migration target around 2030. Emphasizes transition planning and interoperability over prescribing a single scheme. A Canton participant under BSI guidance may prefer or require SLH-DSA for long-term or high-value signatures, while one operating under CNSA 2.0 is expected to use ML-DSA (e.g., ML-DSA-87) within that profile. FN-DSA (Falcon) addresses compact signature use cases and is explicitly included in ANSSI guidance. No jurisdiction we are aware of currently mandates non-NIST PQC signature schemes for general-purpose use, although some national programs (e.g., Korea’s KpqC selections) exist and may be adopted domestically.

This is useful. Thank you.

6. Engineering effort Open to discussing budget structure. We can restructure around two milestones (ML-DSA + SLH-DSA combined, then FN-DSA + documentation) if that better matches expectations.

7. License Apache 2.0. Will add explicitly to the revised proposal.

— Reply to this email directly, view it on GitHub https://github.com/canton-foundation/canton-dev-fund/pull/222#issuecomment-4371010378, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD6MV37T4SVJLSLWQ4WYK5T4ZCD4ZAVCNFSM6AAAAACX2WCIW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGNZRGAYTAMZXHA. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you commented.

-- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at  http://www.digitalasset.com/emaildisclaimer.html http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

Thanks for the follow up.

Please could you clarify whether your intent is to add crypto primitives to the Daml language or to the underlying Canton protocol.

To the underlying Canton protocol. Concretely, the work extends SigningKeySpec and SigningAlgorithmSpec (in community/base/src/main/scala/com/digitalasset/canton/crypto) with ML-DSA-44/65/87, SLH-DSA at NIST Levels 1/3/5 (small and fast variants), and FN-DSA-512/1024. The integration touches the JCE provider path (Bouncy Castle PQC covers ML-DSA and SLH-DSA today, FN-DSA is still in flight), the KMS driver API where HSM support is available, topology TX serialization, and synchronizer minimum-scheme negotiation. As you noted, signature algorithm choice is signer-defined via the topology TX for the verification key, so classical and PQ keys can coexist on the same synchronizer, and parties can migrate on their own schedule.

The three schemes fit different custody architectures:

• ML-DSA is the most tractable to thresholdize. Fiat-Shamir-with-aborts has decent MPC literature behind it, which matters for Canton's institutional MPC custody users.
• SLH-DSA is the conservative hash-based option BSI prefers for high-value long-lived signatures, but it is hard to thresholdize because of the WOTS+/Merkle internals.
• FN-DSA gives a compact signature (useful for bandwidth-constrained deployments and ANSSI compliance), but threshold variants are still research.

Your paper assumes that the EdDSA seed key is available and that you construct a ZKP linking the seed to the PQC key...

Fair point on coverage. Seed-holding users are a subset: MPC custodians sample shares directly through DKG with no seed, many ECDSA deployments sample uniformly over the curve, and some EdDSA implementations discard the seed after keygen. Afaik, the migration question splits along Canton's key hierarchy.

Intermediate namespace keys, sequencer-authentication keys, protocol signing keys, encryption keys. Migration is the existing protocol primitive: a topology transaction (NamespaceDelegation, OwnerToKeyMapping, or PartyToKeyMapping) signed by an authorized namespace key, registering a new PQ key. Namespace fingerprint stays stable, no party UID changes, no contract reassignment. The same machinery already used for classical key rotation, extended to PQ keys once the algorithm specs are in. No seed required.

Root namespace key. Today the root is classical (Ed25519 or EC-DSA over P-256/P-384/Secp256k1), and the namespace fingerprint is its hash, so rotating it through a normal topology transaction changes the namespace. Operators mitigate this by keeping the root offline, but the public key remains in the topology state and the signature scheme remains classical. The eprint 2025/1368 construction simplifies the mapping in case of rotation and targets the silent-CRQC case: it binds the new PQ key to seed material a Shor-derived private key alone cannot reproduce, so a legitimate ZKP-bound rotation stays distinguishable from a forgery. This works directly for RFC 8032 with retained seed and BIP-32/39 HD; non-seed cases need an additional construction step to support it.

To set scope: the priority is the signing algorithm extension across Canton's signing surfaces. That work is independent of the seed question. Wallet / custodian seed retention would ease later migration but is not a prerequisite for what this proposal delivers.