PQSecure™-SW

Cryptographic software stack

PQSecure-SW™ delivers production-grade, side-channel-aware, formally verified post-quantum cryptography software for embedded systems, secure boot, Root-of-Trust, defense platforms, and silicon-integrated deployments.

Start an evaluation

Software stack

Module and verification

Module Implementation Verified with
libpqsecure-C Portable C for firmware, RTOS, secure boot, and silicon integration CBMC
libpqsecure-rs Memory-safe Rust, no_std capable Kani
libpqsecure-asm Architecture-optimized assembly acceleration Constant-time primitives

Algorithm coverage

The finalized NIST standards, the forthcoming ones, stateful hash-based signatures, and the classical hash primitives that hybrid deployments still depend on.

Complete portfolio

Family and standard

NIST post-quantum

  • ML-KEM FIPS 203
  • ML-DSA FIPS 204
  • SLH-DSA (SPHINCS+) FIPS 205
  • FN-DSA (Falcon) FIPS 206, available soon

Stateful signatures

  • XMSS RFC 8391
  • LMS RFC 8554
  • Stateful guidance NIST SP 800-208

Hash and classical

  • SHA-2 FIPS 180
  • SHA-3 (Keccak) FIPS 202
  • SHA-2, HMAC, HKDF RFC 6234

Implementations support the relevant NIST security levels, 1, 3, and 5 where applicable.

Three modules, one stack

Portable C, memory-safe Rust, and an assembly acceleration layer that integrates with both. Use them together or independently.

Modules

Role, evidence, and targets

  • libpqsecure-C

    Portable C for firmware, RTOS, secure boot, and silicon integration

    Verified with

    • Formally verified using CBMC
    • Strict constant-time discipline
    • ACVP-tested infrastructure

    Implementation

    • Pure C implementation
    • Stack-optimized variants
    • Portable across major toolchains

    Runs on

    • Bare-metal, RTOS, and embedded Linux
    • Linux, macOS, and Windows

  • libpqsecure-rs

    Memory-safe Rust, published as PQSecure™-TRUST

    Verified with

    • Formally verified using Kani
    • Strict constant-time discipline
    • ACVP-tested infrastructure

    Implementation

    • Pure Rust implementation
    • Memory-safe by construction
    • no_std support

    Runs on

    • RISC-V and ARM Cortex-M
    • Linux, macOS, and Windows
    Verification detail on TRUST →

  • libpqsecure-asm

    Architecture-optimized assembly acceleration for both libraries

    Accelerates

    • Optimized NTT implementations
    • Modular and polynomial arithmetic acceleration
    • SHA acceleration where supported
    • DSP instruction utilization on M4 and M33
    • Optional AVX2 and NEON vector acceleration

    Targets

    • ARM Cortex-M3, Cortex-M4 and M33, Cortex-A series
    • RISC-V RV32 and RV64
    • x86-64

Formal methods, in production code

Verification is part of the build rather than a report written afterwards, and it runs continuously across desktop, emulated, and real embedded targets.

Assurance

Method and scope

Verification and assurance
  • Rust verified using Kani
  • C verified using CBMC
  • Constant-time coding discipline
  • Side-channel-aware implementation
  • ACVP testing infrastructure
  • Designed for FIPS-oriented validation pathways
Continuous integration
  • Linux, macOS, and Windows testing
  • RISC-V and ARM via QEMU
  • On-board embedded validation
  • Automated regression testing
Embedded validation

Three repositories carry the work: crypto-repo for operating system and QEMU validation, board-repo for embedded evaluation boards, and crypto-board-repo for automated cloning and board regression.

Performance and footprint

libpqsecure 1.0 measured against OpenSSL 3.5.0 on an Apple M1 at 3.2 GHz, results in microseconds, then offered in two deployment profiles so the same library fits a gateway or a secure element.

Bar chart comparing libpqsecure and OpenSSL ML-KEM key generation, encapsulation, and decapsulation latency in microseconds
ML-KEM (FIPS 203). Over 15% lower latency across keygen, encapsulation, and decapsulation, with gains increasing at ML-KEM-768 and 1024.
Bar chart comparing libpqsecure and OpenSSL ML-DSA key generation, signing, and verification latency in microseconds
ML-DSA (FIPS 204). Over 45% faster signing, with verification and key generation also improved.

Lower is better. ML-DSA signing is averaged over 10,000 iterations because rejection sampling makes individual runs variable. Gains come from optimized NTT and polynomial arithmetic, constant-time arithmetic, stack-aware tuning, and reduced memory movement.

  • Deployment profile

    Large

    Tuned for performance

    Throughput
    Maximum
    Stack
    Stack-optimized implementations
    ML-DSA signing
    Three stack and performance tradeoffs
    Deploy on
    Large and medium devices, gateways, and defense systems

  • Deployment profile

    Small

    Tuned for code footprint

    Throughput
    Lower than the large variant
    Stack
    Reduced stack usage
    Deploy on
    Constrained MCUs and secure elements

Where it goes

Engineered for environments where cryptography ships inside the product, and backed by evidence that can be checked rather than described.

Engineered for

  • Embedded environments
  • Secure boot and Root-of-Trust
  • Defense and aerospace systems
  • Silicon integration
  • Hardware and software co-design

We combine

  • NIST compliance
  • Formal verification
  • Constant-time discipline
  • Assembly-level optimization
  • Embedded portability
  • Hardware acceleration readiness

to deliver production-ready, high-assurance quantum-safe cryptography.

Pairs with PQSecure-HW cores →

Certification

National Institute of Standards and Technology A6936 Cryptographic Algorithm Validation Program

libpqsecure-c, validated as a software cryptographic library.

Validated
  • ML-KEM FIPS 203
  • ML-DSA FIPS 204
  • SLH-DSA FIPS 205
Vendor
PQSecure Technologies
View the record on NIST CSRC ↗

The Rust implementation is certified separately under A7616. See PQSecure-TRUST →

NIST Cryptographic Algorithm Validation Program record for libpqsecure-c A6936

Quantum-safe cryptography your firmware can carry.

Talk with our software team about integration, target platforms, code-size budgets, and licensing.

Contact us