Introduce Post Quantum Cryptography

[synopse]

This issue is about adding post-quantum cryptography (PQC) to the framework, using external libraries.
ML-KEM, ML-DSA and SLH-DSA key encapsulation and digital signatures should be made available to our crypto factory.

Native pascal + asm is out of scope of this feature request yet.
Proper algorithm implementation would be done via external Windows CNG (for ML-DSA since Windows 11 24H2+), OpenSSL 3.5+ and liboqs API.

There is a working API translation at https://github.com/quantumshieldbox/quantumshield4d
No new unit may be needed for Windows or OpenSSL: we could just enhance mormot.core.os.security and mormot.lib.openssl11 units. A new mormot.lib.oqs unit could be done for liboqs.

[synopse]

A native pure pascal port is currently out of scope of this feature request. The NTT / Butterfly part is quite complex to implement and properly use.

We could try to statically link liboqs, and it supports minimal builds with only the algorithms needed (e.g., ML-KEM + ML-DSA).** This is often the cleanest approach for distribution.

Package Availability on POSIX Systems (as of 2026) is not perfect. Availability is improving but not universal. On many production servers (especially LTS distros), you cannot rely on a recent enough system package. Building yourself (or shipping a static binary) is common.

Static Linking

• Yes, fully supported and is the default when you build liboqs with CMake (BUILD_SHARED_LIBS=OFF).
• You get a single liboqs.a static library that you can link into your mORMot-based application or a small wrapper.
• This eliminates runtime dependencies — great for cross-distribution binaries or embedded use.

Minimal Build (Only What You Need)

This is one of liboqs’s strongest features. Use the OQS_MINIMAL_BUILD CMake option:

Example:

cmake -DOQS_MINIMAL_BUILD="KEM_ml_kem_512;KEM_ml_kem_768;KEM_ml_kem_1024;SIG_ml_dsa_44;SIG_ml_dsa_65;SIG_ml_dsa_87" ..

This produces a much smaller library containing only the ML-KEM and ML-DSA variants you specify (plus necessary shared code like SHA-3).

• You can also use OQS_ALGS_ENABLED=STD for NIST-standard algorithms only.
• Resulting static library size is significantly reduced compared to the full build (which includes dozens of experimental algorithms).

Library Size

A minimal static build (ML-KEM + ML-DSA only) is quite reasonable:

• Typically a few hundred KB to ~1–2 MB (stripped), depending on optimizations and enabled parameter sets.
• Much smaller than full liboqs.
• For comparison, even full liboqs is manageable for most desktop/server deployments.

SHA-3

liboqs has its own SHA-3 implementation, which is well optimized with proper asm. We could also publish this engine, in addition to our pure pascal SHA-3 implementation.

[synopse]

Take a look at https://github.com/Xor-el/CryptoLib4Pascal

Implementation seems complete.