Post-Quantum Signature Verification Host Functions in Soroban

[jayz22]

The signature verification algorithms currently available in Soroban — ECDSA and EdDSA — rest on the (elliptic-curve) discrete logarithm problem, whose hardness assumption no longer holds in the post-quantum setting.

As a first step toward post-quantum readiness, we want to expose host functions for native PQ signature verification. This lets Soroban custom accounts (smart wallets) enforce PQ-secure auth on the user side without waiting for protocol-level key-type changes.

This thread tracks the discussion and effort.

Scope of candidates. NIST has standardized three PQ signature schemes: ML-DSA (FIPS 204, lattice), SLH-DSA (FIPS 205, hash-based), and FN-DSA / Falcon (FIPS 206, lattice) — see NIST PQC. Open Quantum Safe (liboqs) tracks available implementations.

Open questions for discussion:

• Scheme selection. Maturity, adoption, implementation readiness, and security margins of each candidate. Lattice vs hash-based.
• Abstraction level. Concrete instantiation (e.g. ML-DSA-65), family (ML-DSA), lower-level primitives (e.g. NTT, sampling) to enable broader schemes in contract code, or lattice operations directly?
• Libraries. What production-grade implementations exist (and audit status)?
• Cost profile. Signature size, public key size, verifier CPU, memory cost.
• Other properties. Signature aggregation; hybrid composition with classical schemes (e.g. Ed25519+ML-DSA).

[jayz22]

Cross-posting, there is another thread discussing support for Falcon (FN-DSA, one of the NIST standardized schemes mentioned above)
https://github.com/orgs/stellar/discussions/1830

[iftachh]

Thanks Jay. I would try to go as broad as possible, support all 3 signature scheme and expose also the low level primitive.
We should support the three of them since we do not know what the industry will choose. Also, since these are rather new schemes, some of them might be found to be insecure, or at least not as secure as we would like to them to be.
Also, since we have to implement the lower level primitives any how, it skills cost us rather little to expose them, isn't it?

Btw, what about signature batching? The ability to sign many different messages with a single short signature? Is it part of what we plan to support soon?

[Eshan276]

dont know if its relevant here, wanted to share- https://github.com/Eshan276/nebulav2