Implementing Hybrid PQC IPsec with Qrypt BLAST on Jetson Orin (and Coming Soon: Thor)
By Ryan Mandich | January 2026
TL;DR for Robotics Engineers
Your robot’s sensor streams, control commands, and telemetry are likely protected with “best practice” encryption today, but that protection assumes attackers can’t record traffic now and crack it later. In robotics, that’s a risky bet: long-lived IP, safety logs, proprietary perception models, and operational telemetry are all valuable targets for harvest-now, decrypt-later attacks—especially as cryptographically relevant quantum computers get closer.
In this post, we’ll walk through a practical way to harden NVIDIA Jetson Orin networking with post-quantum cryptography (PQC) using a hybrid PQC IPsec setup, so you can add quantum-resilient key exchange without sacrificing real-time performance. The approach is designed for robotics engineers: minimal moving parts, measurable overhead, and a clear path to deployment at the edge (with Jetson Thor support coming soon).
For high-assurance environments and highly sensitive data, we’ll go a step further: integrating Qrypt BLAST for strongSwan as a drop-in plugin. BLAST removes the PKI pain of key distribution by enabling both endpoints independently generate matching keys from quantum-secure randomness, supporting asynchronous key buffering that can reduce handshake sensitivity and help maintain ultra-low-latency behavior under network jitter, reconnects, and intermittent links. If you’re building systems where downtime, latency spikes, or key-management complexity aren’t acceptable, this is the “turn the dial to maximum” option—and a great reason to reach out for an architecture review or deployment support.
What you’ll get:
- 926 Mbps VPN throughput with hybrid PQC key exchange
- <1% overhead compared to classical encryption
- Works on Jetson Orin today, Jetson Thor in February 2026
Time to implement: ~30 mins with our configs and scripts (strongSwan + PQC), plus ~10 minutes to add BLAST plugin
Why Robotics Systems Need PQC Now
If you’re building autonomous systems on NVIDIA Jetson (warehouse AMRs, delivery robots, inspection drones, industrial automation) you’re not shipping a gadget. You’re deploying infrastructure. These devices often stay in the field for 10+ years, traverse untrusted networks, and continuously generate high-value data: sensor feeds, maps, mission logs, safety events, and proprietary behaviors.
That longevity changes the threat model. An adversary doesn’t need to break your encryption today to win—they can capture encrypted traffic now and wait. As quantum-capable attacks mature, yesterday’s “secure” recordings could become tomorrow’s plaintext. This harvest-now, decrypt-later (HNDL) risk is especially acute in robotics, where data has long shelf life and high downstream impact: IP leakage, regulatory exposure, safety investigations, and replay/impersonation pathways that compound over time.
Adopting PQC now, especially via hybrid key exchange, enables future-proof connectivity without redesigning your entire stack, so your Jetson deployments remain defensible across their full operational lifetime.
Adversaries are recording your encrypted traffic today and storing it until quantum computers can break RSA and elliptic curve cryptography (this will be done through cloud-available services). Even without quantum computers, cryptographic vulnerabilities are found and continuously published to exploit recorded data and real-time systems.
For robotics systems handling:
- Fleet management commands — Mission updates, policy changes, e-stop/resume. High-leverage traffic that shouldn’t become readable later.
- Sensor fusion streams — Camera/LiDAR/radar/IMU and perception outputs. Recorded telemetry can expose sites, operations, and people.
- Proprietary navigation stack signals — Costmaps, planner outputs, behavior states. Decrypted traces can leak “how your autonomy works.”
- Customer & facility info — Site IDs, maps, restricted zones, tickets/configs. Long-retained data creates long-lived liability.
- Remote teleoperation & operator video — Low-latency control + video/AR overlays. Protects real-time authority and archived sessions.
- OTA updates & device identity — Firmware packages, signed metadata, provisioning secrets. Prevents future key/identity exposure from captured sessions.
- 6G / private cellular backhaul — As robots move onto 5G-Advanced/6G-style networks, traffic is more likely to be logged across multiple domains; PQC-secured VPNs add an end-to-end layer that outlives radio-era crypto assumptions.
…this isn’t theoretical. It’s why NIST finalized PQC standards in August 2024, and why NVIDIA’s security guidance emphasizes crypto agility.
The defense-in-depth case: ML-KEM is widely trusted, but, like all practical cryptography, it isn’t “proven,” it’s tested by years of scrutiny and the absence of successful attacks. If a weakness is ever found, you’ll want the ability to rotate quickly with minimal engineering. BLAST adds a second layer: even if a PQC scheme degrades someday, BLAST’s symmetric key generation and pre-buffered keys reduce reliance on any single key-exchange primitive.
The Challenge on Embedded Hardware
PQC algorithms are more computationally expensive than classical ones. On a server, this barely matters. On a 15W Jetson running real-world inference workloads, every CPU cycle counts.
The real work: Getting PQC to run on Jetson required significant platform engineering:
- Upgrading the kernel from NVIDIA’s stock 5.15 to mainline 6.6 (required for PQC IPsec Child SA support)
- Building a custom Yocto BSP with NVIDIA driver compatibility fixes
- Cross-compiling strongSwan 6.0 with liboqs for ARM64
- Resolving driver conflicts and kernel API changes
We’ve done that work for you. This post provides pre-built images and reproducible build instructions so you can focus on your robotics application, not kernel debugging.
Adding BLAST is straightforward: Once strongSwan is running, BLAST is just a plugin installation. Copy the .so file, add a config snippet, and restart the service to start using BLAST. No patching required.
Architecture Overview
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ JETSON ORIN / THOR │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ ┌────────────────────────────────────────────────────────────────────────────────┐ │
│ │ ROS 2 / Isaac ROS / Ubuntu Applications │ │
│ │ (Navigation, Perception, Planning, Fleet Management) │ │
│ └────────────────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ Encrypted via IPsec │
│ ▼ │
│ ┌────────────────────────────────────────────────────────────────────────────────┐ │
│ │ strongSwan 6.0 VPN │ │
│ │ ┌──────────────┐ ┌──────────────────────┐ ┌────────────────────────────────┐│ │
│ │ │ liboqs │ │ Qrypt BLAST │ │ IPsec/ESP Encryption ││ │
│ │ │ (ML-KEM) │ │ (Quantum RNG/Keygen) │ │ (AES-256-GCM) ││ |
│ │ └──────────────┘ └──────────────────────┘ └────────────────────────────────┘│ │
│ └────────────────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌────────────────────────────────────────────────────────────────────────────────┐ │
│ │ Linux Kernel 6.6 (XFRM/IPsec Subsystem) │ │
│ │ PQC Child SA Rekeying Support │ │
│ └────────────────────────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────────────────────┘
│
Encrypted IPsec Tunnel
│
▼
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ BACKEND / CLOUD / FLEET MANAGER │
│ (strongSwan + Qrypt BLAST Gateway) │
└─────────────────────────────────────────────────────────────────────────────────────┘
Key Components
| Component | Version | Purpose |
|---|---|---|
| Custom Qrypt Linux Kernel | 6.6 LTS | XFRM support for PQC Child SA rekeying |
| strongSwan | 6.0.0beta4 | IKEv2 with hybrid PQC proposals |
| liboqs | 0.11.0 | ML-KEM (Kyber) implementation |
| Qrypt BLAST plugin | Latest | Quantum-secure entropy and key generation for strongSwan |
| Custom Qrypt Yocto Project | Scarthgap (5.0) | Reproducible BSP builds |
Performance: The Numbers That Matter
Tested on NVIDIA Jetson Orin Nano Developer Kit (8GB), kernel 6.6.96, room temperature.
VPN Throughput
| Configuration | Throughput |
|---|---|
| No VPN (baseline) | 927.09 Mbps |
| AES-256-GCM only | 926.54 Mbps |
| Hybrid PQC (ML-KEM + DH + BLAST) | 926.21 Mbps |
Key insight: PQC adds negligible steady-state overhead. The main cost is during handshake and rekey operations, with no measurable impact on continuous data transfer.
PQC Algorithm Performance
| Algorithm | Operation | Time (ms) | Notes |
|---|---|---|---|
| ML-KEM-768 | Key Generation | .036 | Per handshake |
| ML-KEM-768 | Encapsulation | .043 | Per handshake |
| ML-KEM-768 | Decapsulation | .041 | Per handshake |
| ECDH P-256 | Key Derivation | .092 | For comparison |
Bottom line: ML-KEM adds ~.1ms to handshake. For a tunnel that rekeys hourly, this is negligible.
Rekey Performance
| Rekey Interval | Time |
|---|---|
| AES-256-GCM Only | 480 (ms) |
| Hybrid PQC (ML-KEM + DH) | 483 (ms) |
| Hybrid PQC (ML-KEM + DH + BLAST) | 741 (ms) |
Quick Start:
Prerequisites
- NVIDIA Jetson Orin Nano/NX Developer Kit
- Ubuntu host machine for Yocto builds (or use our pre-built image)
- Qrypt API token (Register free on our Portal)
Option A: Pre-Built Image (Fastest)
# Download pre-built Jetson image with PQC stack
git clone https://github.com/QryptInc/qrypt_jetson_yocto
# Flash to Jetson (while device in recovery mode)
tar -xvf core-image-base-jetson-orin-nano-devkit.rootfs.tegraflash.tar.gz
sudo ./doflash.sh
# After boot, configure your Qrypt token
ssh root@<jetson-ip>
# As part of the Qrypt linux distribution, strongswan, blast and liboqs are already prebuilt.
# To begin using strongswan, plugin your API token with the qrypt-config script included
setup-blast --token YOUR_API_TOKEN
setup-blast --config LOCAL_HOST_IP REMOTE_HOST_IP
# You can verify the changes occurred by checking
setup-blast --show
# Test the connection
systemctl restart strongswan
swanctl --load-all
swanctl --initiate --ike pqc-robotics
swanctl --initiate --child robotics-data
swanctl --list-sas # Should show KE1_KYBER_L3 and KE2_BLAST
EX:
root@jetson-orin-nano-devkit:~/qrypt/strongswan# swanctl --list-sas
pqc-robotics: #1, ESTABLISHED, IKEv2, 58c3a42370165f79_i* aca11e73f706386c_r
local 'jetson-001' @ 192.168.36.86[4500]
remote 'jetson-002' @ 192.168.36.142[4500]
AES_GCM_16-256/PRF_HMAC_SHA2_256/CURVE_25519
established 19s ago, rekeying in 13236s
robotics-data: #1, reqid 1, INSTALLED, TUNNEL, ESP:AES_GCM_16-256/MODP_2048/KE1_KYBER_L3/KE2_BLAST/ESN
installed 8s ago, rekeying in 3542s, expires in 3952s
in cc83ce78, 0 bytes, 0 packets
out cf08f3cd, 0 bytes, 0 packets
local 192.168.36.86/32[udp]
remote 192.168.36.142/32[udp]
Option B: Build From Source (Full Control) Reach out to Qrypt for full configuration instructions
Configuration Reference
example strongSwan swanctl.conf for one side of the tunnel
conn-defaults {
version = 2
proposals = aes128-sha256-x25519
}
child-defaults {
esp_proposals = aes256gcm16-modp2048-ke1_kyber3-ke2_blast-esn
mode = transport
start_action = none
dpd_action = restart
rekey_time = 3600
}
connections {
dark-fiber : conn-defaults {
local_addrs = 192.168.36.142
remote_addrs = 192.168.36.86
local {
auth = psk
id = 192.168.36.142
}
remote {
auth = psk
id = 192.168.36.86
}
children {
robotics: child-defaults {
local_ts = 192.168.36.142/32[udp]
remote_ts = 192.168.36.86/32[udp]
}
}
}
}
secrets {
ike-pqc-1 {
id = 192.168.36.142
secret = INSERT_PSK_HERE
}
}
Kernel Configuration (Key Options, included in qrypt project)
# Required for PQC Child SA
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
CONFIG_XFRM_INTERFACE=y
CONFIG_NET_KEY=y
CONFIG_INET_AH=y
CONFIG_INET_IPCOMP=y
CONFIG_INET_ESP=y
CONFIG_INET6_AH=y
CONFIG_INET6_IPCPOMP=y
CONFIG_INET6_ESP=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IPV6_MULTIPLE_TABLES=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IPV6_ROUTER_PREF=y
CONFIG_NETFILTER_XT_MATCH_POLICY=y
What Qrypt BLAST Adds
While liboqs provides the ML-KEM algorithm, Qrypt BLAST provides the quantum-secure entropy that seeds key generation, as well as key generation immune to HNDL. This matters because:
- Truly random keys — BLAST uses quantum random number generation, not PRNGs
- No shared secrets in transit — Keys generated from independent quantum sources at the endpoint instead of distributed to the endpoint
- Compliance-ready — Uses PQC standards
Get started free: Register for a Qrypt API token
For fleet deployments, enterprise features, or custom integrations, contact our team.
Coming Soon: Jetson Thor Support
We’re actively porting this stack to NVIDIA Jetson Thor AGX, targeting a February 2026 release. Thor’s enhanced security features, including:
- Improved TrustZone implementation
- Hardware security module integration
- Higher throughput for compute-intensive workloads
…make it an ideal platform for production robotics deployments requiring PQC.
Want early access? Contact us
Next Steps
For Individual Developers
- Register for a free Qrypt API token
- Clone our GitHub repository
- Follow the Quick Start above
- Join the discussion in NVIDIA Developer Forums
For Organizations
- Evaluate: Use the free tier to benchmark on your hardware
- Pilot: Contact us for fleet management and enterprise features
- Deploy: We provide integration support for production rollouts
Get Help
-
Direct Support: Contact us
Resources
- GitHub Repository – Kernel image and flashing scripts
- Qrypt Documentation – BLAST integration reference
- NIST PQC Standards – Official specifications
- strongSwan PQC Docs – Algorithm configuration
About Qrypt
Qrypt provides quantum-secure cryptography solutions for enterprises preparing for the PQC era. Our BLAST technology delivers truly random encryption keys using quantum phenomena, eliminating the vulnerabilities inherent in algorithmic random number generation and classical key generation.
