[FEATURE] Vendor PQCP and Ed448-Goldilocks for Post-Quantum WAMP

### Description Following the discussion in [[wamp-proto/wamp-proto#564](https://github.com/wamp-proto/wamp-proto/issues/564)](https://github.com/wamp-proto/wamp-proto/issues/564), this issue proposes the vendoring of the **PQ Code Package (PQCP)** and Mike Hamburg’s **libdecaf (Ed448-Goldilocks)** into `autobahn-python`. The goal is to provide a "Defense-Grade," zero-dependency, and high-performance implementation of Post-Quantum Cryptography (PQC) and High-Strength Classical ECC for the WAMP ecosystem, specifically targeting **ML-KEM** (FIPS 203) and **ML-DSA** (FIPS 204). ### Motivation As we move toward a Quantum-Resistant WAMP (WAMP-PQC), the protocol requires hybrid cryptographic schemes that combine classical security (Ed25519/Ed448) with lattice-based security (ML-KEM/ML-DSA). While libraries like `libsodium` provide excellent support for Ed25519, they lack Ed448 and NIST-finalized PQC algorithms. To maintain Autobahn's standard of "Zero-Config" installation and high portability, we must internalize these primitives. ### Proposed Implementation Strategy #### 1. Direct Upstream Vendoring We will vendor the following sources directly into `src/autobahn/vendor/`: * **PQCP (PQ Code Package):** Utilizing `mlkem-native` and `mldsa-native`. This is the Linux Foundation-backed successor to PQClean, providing C90-compliant, formally verified, and SIMD-optimized PQC. * **libdecaf (Ed448-Goldilocks):** Sourced from Mike Hamburg’s upstream (SourceForge) and verified against Debian's security patches. This fills the gap for 256-bit security level signatures that `libsodium` does not address. #### 2. CFFI Wrapping Consistent with our performance goals: * We will wrap these C libraries using **CFFI** rather than CPyExt. * This ensures optimal performance on **PyPy** via JIT-inlining while remaining highly efficient on CPython. * It avoids the maintenance burden of the CPython C API and the performance penalties of `ctypes`. #### 3. High-Performance Multi-Arch Wheels We will update our `cibuildwheel` pipelines to publish **manylinux** and **musllinux** wheels for: * **x86-64:** Leveraging AVX2 optimizations for NTT (Number Theoretic Transform). * **ARM64 (aarch64):** Leveraging Neon instructions for high-speed PQC on ARM-based servers and high-end IoT (like Cortex-A). ### Proposed Security Tiers | Tier | Hybrid Combination | Use Case | | --- | --- | --- | | **Standard** | Ed25519 + ML-DSA-65 | General Purpose WAMP-Cryptosign | | **High-Strength** | Ed448 + ML-DSA-87 | Defense / U.S. DoD CUI / Critical Infrastructure | | **Key Exchange** | X25519 + ML-KEM-768 | Encrypted Payloads / Session Keys | ### Benefits * **Zero Dependencies:** No requirement for users to install `liboqs`, `openssl-dev`, or `cmake`. * **Defense-Grade:** Aligns with NIST FIPS 203/204 and NSA CNSA 2.0 requirements. * **Embedded-Ready:** By vendoring the native C source, we pave the way for cross-compilation to restricted environments (e.g., Cortex-M33). ### Reference * [[wamp-proto/wamp-proto#564](https://github.com/wamp-proto/wamp-proto/issues/564)](https://github.com/wamp-proto/wamp-proto/issues/564) * [[NIST FIPS 203 (ML-KEM)](https://csrc.nist.gov/pubs/fips/203/final)](https://csrc.nist.gov/pubs/fips/203/final) * [[NIST FIPS 204 (ML-DSA)](https://csrc.nist.gov/pubs/fips/204/final)](https://csrc.nist.gov/pubs/fips/204/final) ## Checklist - [x] I have searched existing issues to avoid duplicates - [x] I have described the problem clearly - [x] I have provided use cases - [x] I have considered alternatives - [x] I have assessed impact and breaking changes