Best Practices for Resisting Post-Quantum Attacks
Focus
Focus
Network Security

Best Practices for Resisting Post-Quantum Attacks

Table of Contents

Best Practices for Resisting Post-Quantum Attacks

Cryptography, VPN, and transition planning best practices to resist post-quantum attacks and safeguard key exchange material.
Where Can I Use This?What Do I Need?
  • PAN-OS
  • PAN-OS 11.1 or later.
There are many best practices you can implement now to defend against post-quantum attacks carried out by quantum computers, including defending against Harvest Now, Decrypt Later attacks. Harvest Now, Decrypt Later attacks capture encrypted data and key exchange material with the intent to use cryptographically relevant quantum computers (CRQCs) to decrypt the material later by accelerating Shor's algorithm, which factors key material to find the large prime numbers on which the encryption key is based.
These best practices cover:
  • Post-Quantum Transition Planning Best Practices
  • Cryptography Best Practices
  • VPN Configuration Best Practices

Post-Quantum Transition Planning Best Practices

The transition from classical cryptography to post-quantum cryptography can take five years or even longer. Planning alone can take several years. Give yourself the best advantage by:
  • Starting Early—If your company has long-lived data and is a potential target of harvesting attacks, each day you delay taking action risks allowing attackers to harvest more information to decrypt later. The earlier you take action, the sooner you stop attackers from harvesting data to decrypt in the future.
  • Leveraging Existing Resources—When you take your crypto inventory, leverage work you have already done for audits, Zero Trust, network enhancements, and other activities.
  • Educating Yourself—Learn about the quantum computing threat, post-quantum cryptography (PQC), technologies and methods to harden your network against quantum attacks, and the new and emerging PQCs that you can use to protect your network. Learn from government mandates, plans, and laws, RFCs, and other information sources.

Cryptography Best Practices

Increase the strength of your classical cryptographic suites to make it more difficult for an attacker to brute force decrypt keys as quantum computers become faster and faster as they evolve into CRQCs. Quantum computers that are not CRQCs might still be fast enough to break weaker encryption.
  • Follow RFC 6379 for Suite B Cryptographic Suites for IPsec to upgrade your VPN connections to tough cipher suites. Use Suite-B-GCM-256 and avoid weaker 128-bit AES algorithms, which are vulnerable to Grover's algorithm.
  • Upgrade your CA to 4K RSA key sizes to mitigate brute force attacks that can break smaller key sizes.
  • Migrate your VPN certificate authentication to new certificates with larger key sizes.
  • Upgrade to higher-bit SHA hash sizes such as SHA-384 and SHA-512. Stop using weak hashes such as MD5 and SHA-1.
  • Upgrade SSL/TLS connections to tough cipher suites; use TLSv1.3 with Perfect Forward Secrecy (PFS) ciphers.
  • Tunnel SSL/TLS sessions in hardened, client-to-server VPN sessions.
  • Configure your Vulnerability Protection profiles to block unsanctioned PQCs for traffic that you don't decrypt. For traffic that you decrypt, use a Decryption profile to block unsanctioned PQCs (the Decryption profile only allows the ciphers that you enable and the firewall blocks all other ciphers). Unsanctioned PQCs might indicate a breach or an internal bad actor attempting to use PQCs to compromise your network. Make exceptions as needed for your internal PEN testing teams.

VPN Configuration Best Practices

When you configure post-quantum IKEv2 VPNs, make them as resistant to quantum attacks as possible:
RFC 8784 Best Practices:
    Expand all
    Collapse all
  • Don't use IKEv1. IKEv1 is considered to be a weak protocol and does not support post-quantum VPNs. If both IKE peers can support it, upgrade your VPN connections to IKEv2 and select IKEv2 only mode when you configure the IKE gateways (NetworkNetwork ProfilesIKE GatewaysGeneral).
  • Set the Negotiation Mode to Mandatory whenever you know both peers support RFC 8784. Using Mandatory mode ensures that the VPN resists post-quantum attacks and attackers can't harvest the data now and decrypt it later using a CRQC running Shor's algorithm.
  • Manually specify or automatically generate a PPK Secret that is at least 64 characters (32 bytes, or 256 bits of entropy) in length to create a strong key. You can manually specify or automatically generate a PPK Secret that is up to 128 characters (64 bytes, 512 bits of entropy) long. The longer the PPK Secret, the greater the number of entropy bits, which makes the PPK Secret harder to crack.
RFC 9242 and RFC 9370 Best Practices:
    Expand all
    Collapse all
  • Don't use IKEv1. IKEv1 is considered to be a weak protocol and does not support post-quantum VPNs. If both IKE peers can support it, upgrade your VPN connections to IKEv2 and select IKEv2 only mode when you configure the IKE gateways (NetworkNetwork ProfilesIKE GatewaysGeneral).
  • Create the hybrid key using a strong classic KEM, such as Diffie-Hellman Group 20 and above, and at least one PQC in the additional KEM rounds, such as Kyber-768 (ML-KEM), when you configure the IKE crypto profiles (NetworkNetwork ProfilesIKE CryptoGeneral and Advanced Options).
  • Use only PQCs that are rated at a security strength level of L3 or higher for sensitive information. Each additional PQC added to the key creation process increases the key’s ability to resist a quantum attack, but it also adds latency and overhead to the IKEv2 peering process. In general, adding a security level L3 PQC adds approximately 20 to 30 ms to the IKEv2 key exchange, and adding a security level L5 PQC adds 40 to 60 ms. Stronger PQCs that use larger keys, such as Classic McEliese, can potentially add more than 800 ms to the key exchange and introduce high levels of fragmentation. Familiarize yourself with the PQC key sizes and security strengths to select the best PQC for your VPN communications.
  • Coordinate the PQCs used in each key negotiation round with the administrator who manages the peer VPN device. When both VPN devices on each side of the tunnel are configured with the same PQCs in each optional key negotiation round, interoperability issues are minimized. Try to agree on the PQC and its security strength to ensure both sides are configured with the same parameters. For firewalls managed under the same organization, central management tools can be used to ensure consistent configuration and PQC selection in each key negotiation round.
  • Enable cryptographic agility to safeguard your data during the transition to a pure PQC environment. The transition can take as much as 5 to 10 years before the industry fully trusts the new PQCs.
  • Reduce the key lifetime value from its default value to a lower value to facilitate faster rekeying.
  • Enable IPSec to use hybrid keys when you configure the IPSec crypto profiles (NetworkNetwork ProfilesIPSec CryptoGeneral and Advanced Options). Both sides of the IPSec tunnel must be configured to use the same PQC and security strength in each additional key exchange round.