Skip to content

Back to the catalog

Deploying Native-Rust KpqC: Pluggable Post-Quantum KEMs and Signatures across TLS, Space Links, and the OQS Ecosystem
eprint.iacr.orgpaper

Deploying Native-Rust KpqC: Pluggable Post-Quantum KEMs and Signatures across TLS, Space Links, and the OQS Ecosystem

This IACR ePrint paper presents a native-Rust, memory-safe implementation of the Korean KpqC competition's standardized post-quantum schemes — KEMs NTRU+ and SMAUG-T, and signatures HAETAE and AIMer — replacing the reference memory-unsafe C code. The authors expose all seven KEM parameter sets and four signature modes through a single pluggable provider demonstrated across three real deployment front-ends: a rustls TLS 1.3 key-exchange group, an OQS/liboqs-compatible C ABI, and an analytical CCSDS/SDLS satellite constrained-link model, showing SMAUG-T variants are smaller/faster than ML-KEM-768 on constrained space links and a memory-optimized NTRU+ build cuts peak stack by up to 25% at negligible latency cost.

TL;DR A memory-safe native-Rust implementation of Korea's KpqC post-quantum KEMs/signatures, deployed and benchmarked across TLS 1.3, a liboqs-compatible ABI, and satellite link constraints.
Open original ↗
Document

What it is

A native-Rust reimplementation of the four KpqC-standardized schemes — KEMs NTRU+ and SMAUG-T, signatures HAETAE and AIMer — exposed through a single pluggable provider with three concrete integration front-ends: a rustls TLS 1.3 key-exchange group, an OQS/liboqs-compatible C ABI, and an analytical CCSDS/SDLS satellite link model.

How it works

The Rust code is wired behind the OQS-shaped C ABI so it can stand in for the C reference implementation inside liboqs without changing callers. The same provider is plugged into rustls as a TLS 1.3 key-exchange group, producing a complete handshake using only a KpqC KEM for key establishment. For the space-link case, the paper runs a fragmentation/latency analysis over illustrative LEO/GEO link profiles rather than a live deployment — it's an analytical model, not a flown test.

Preconditions / Affected

Applies to anyone currently depending on the KpqC reference C code (memory-unsafe) via liboqs/OQS tooling, or evaluating KpqC schemes for TLS 1.3 or constrained/satellite links. All seven KpqC KEM parameter sets and signature modes AIMer and HAETAE (modes 2/3/5) are covered by the provider, not just the headline SMAUG-T/NTRU+ pairing.

What to do

Concrete figures from the paper for scoping/decision purposes:

  • On the modeled constrained space link, SMAUG-T key exchanges are smaller and faster than ML-KEM-768: SMAUG-TiMER is 1280 B and SMAUG-T1 is 1344 B, versus 2272 B for ML-KEM-768.
  • NTRU+ has a memory-optimized build (all three parameter sets) that is byte-identical and KAT-verified to the standard build, cutting peak stack usage by up to 25% with ≈0.99× handshake latency (i.e., effectively no time cost) — a drop-in choice when stack footprint is the binding constraint (e.g., embedded/satellite targets).
  • The liboqs-ABI compatibility means the Rust implementation can be swapped in for the C reference in existing OQS-based deployments without touching the calling code.

Caveats

The satellite link results come from an analytical fragmentation/latency model over "illustrative" LEO/GEO profiles, not a measured on-orbit or hardware test. The memory-footprint and latency comparisons are relative to ML-KEM-768 specifically; the paper does not state comparable figures against other PQC candidates.

Organisations named here

  • CCSDS
  • KpqC
  • ML-KEM
  • SDLS

Technologies named here

  • Native-Rust KpqC implementation
  • TLS 1.3
  • NTRU+
  • rustls
  • Open Quantum Safe / liboqs
  • SMAUG-T
  • CCSDS/SDLS satellite link protocol
  • HAETAE
  • AIMer
  • ML-KEM-768
  • Rust
  • C
  • Open Quantum Safe

Related in other