Yes, I know this came from AI, but I find it useful.
************************************
1) In general terms, how does it work?
-
R82 implements ML-KEM (Kyber-768) inside the IKEv2 key exchange using the IETF extensions that allow either an “intermediate exchange” for large KEM payloads (RFC-9242) and/or multiple key exchanges in a single SA (RFC-9370). That lets the IKEv2 SA derive shared secrets from both a classical DH and one or more PQC KEMs (hybrid). Checkpoint+2RFC Editor+2
-
Practically: during IKEv2 negotiation the gateways perform additional KEM rounds (Kyber) and combine those secrets with the classical secret to form the SA keys; this can be done so that traffic remains protected even if future quantum computers break classical DH. Checkpoint+1
2) What advantage do I have enabling PQC for my VPN communities?
-
Future-proofing / harvest-now-decrypt-later protection — packets captured today cannot necessarily be decrypted in the future once large quantum computers exist, because the key exchange includes a quantum-resistant component.
-
Defense-in-depth — hybrid exchanges (classical + PQC) keep compatibility while adding extra security.
-
Standards-based interoperability — using the IETF RFCs means other vendors adopting the same RFCs can interoperate. Checkpoint+1
3) Advantages of PQC vs traditional IPsec crypto
-
Stronger long-term secrecy for data with long confidentiality requirements.
-
No immediate change to symmetric ciphers (you keep AES/etc.), only the key-agreement part changes — so performance hit is mostly in the handshake, not per-packet crypto (except for slightly larger keys/IVs if you choose certain modes).
-
Hybrid mode lets you keep the classical protections you trust while adding PQC safety. Checkpoint+1
4) Do both Security Gateways need to be on R82?
-
To actually use Kyber for the key exchange both peers need to support the same PQC exchange (i.e., an implementation of ML-KEM / the IKEv2 extensions). If the peer does not support PQC, the IKE negotiation will fall back to classical algorithms (unless you force PQC-only and it fails). So: yes — to actively negotiate PQC you need the peer to understand the PQC extension. Checkpoint+1
5) Inter-vendor compatibility (Fortinet / Palo Alto / Cisco / others)
-
Many major vendors are already adding PQC support or hybrid modes (Fortinet, Palo Alto, Cisco have public material and features for PQC/hybrid IKEv2). That means cross-vendor PQC VPNs are possible if both sides implement the same RFCs / algorithm sets (common examples: Kyber ML-KEM, RFC-9370 / RFC-9242 / RFC-8784 for related mixing). Check each vendor’s PQC docs for the exact RFCs and parameter sets they support (Kyber-768 is the common NIST-selected KEM level being used). Fortinet Documentation+2Live Community+2
6) Is there support or a roadmap for PQC in Quantum Spark (SMB appliances)?
-
As of Check Point’s published R82 feature set, R82 Quantum/Quantum Firewall Software supports Kyber (ML-KEM-768) for VPNs. For the Quantum Spark (SMB) line: the public roadmap pages and Spark FAQ show many R82 features coming to Spark, but I can’t find a specific, public statement that Quantum Spark already supports PQC right now — the Spark roadmap mentions many items but not explicit Kyber/PQC support. Because Spark has a separate feature cadence and hardware constraints, you should check the Spark release notes / SK articles or open a ticket with Check Point to confirm whether your exact Spark model/firmware build includes ML-KEM support. (Spark roadmap page does not list PQC explicitly as shipped at the time of the R82 announcement.) Check Point Software+2Checkpoint+2
7) If my VPN peer is another vendor, does the peer need to support PQC?
-
Yes — the peer must support the PQC KEM and the IKEv2 extensions (or an interoperable RFC like RFC-9370 / RFC-9242 / RFC-8784) to complete the PQC key exchange. If the other side does not support PQC, you will either (a) fall back to classical key exchange, or (b) fail negotiation if you require PQC-only. Many vendors already provide hybrid options (classical+PQC) to allow a gradual migration. IETF Datatracker+1
8) Does enabling PQC increase firewall resource usage (CPU, memory)? Recommended models?
Short answer: Yes — expect more CPU work (mainly at IKE handshakes/rekeys) and larger handshake packets; but the persistent per-packet symmetric crypto cost stays about the same. Test and size accordingly.
Details and guidance:
-
Handshake cost: Kyber operations add CPU cycles to IKE handshakes and rekeys. Studies and benchmarks show Kyber is much faster than RSA and is reasonably efficient on modern CPUs, but it still requires more CPU than Elliptic Curve DH because of larger poly arithmetic. In practice the cost is concentrated on the initial/rekey exchanges, not steady-state per-packet AES encryption. arXiv+1
-
Memory / packet size: Kyber keys and ciphertexts are larger (Kyber-768 public key/ciphertext sizes are on the order of ≈1 KB). That can push IKE messages past typical MTU and require fragmentation or the intermediate exchange (RFC-9242). Expect a small increase in memory for the crypto operation state. asecuritysite.com+1
-
Throughput impact: For long-lived tunnels that rekey infrequently, steady-state throughput is usually not heavily affected because symmetric crypto still does the per-packet work. The main effects are (a) slightly longer IKE/REKEY times and (b) slightly larger control plane traffic. Studies caution that in high-rate rekey scenarios or very short-lived SAs there can be measurable throughput/latency differences. repositorio.ipv.pt+1
Recommended approach / models
-
Use production Quantum/Quantum-class appliances running R82 or later for the Check Point side — those are the platforms the PQC feature was released for. If you have high throughput (multi-Gbps) VPN aggregation, choose Check Point models sized for high VPN crypto workloads (modern multi-core CPUs). Check Point’s R82 release notes and product pages advertise the feature for Quantum firewall software; for exact appliance-level recommendations check the appliance datasheets or TAC. Checkpoint+1
-
If you have hardware crypto offload (IPsec accelerators), confirm whether vendors will offload Kyber — many current HW accelerators were built for classical DH/RSA/ECDH and may not accelerate lattice ops, so software CPU will be used for the PQC KEM unless an accelerator supports it. That argues for picking gateways with strong general-purpose CPU performance. Reddit+1
-
Lab test: before enabling PQC in production, test with real traffic patterns (rekey frequency, tunnel counts) to measure the IKE-CPU load and check if IKE messages fragment on your links (MTU). This is the most important practical step.
Best,
Andy
