Listen to this Post
Introduction:
Shor’s algorithm has long been heralded as the quantum hammer that will shatter modern encryption, with many claiming that AES-128 will fall as soon as fault-tolerant quantum computers emerge. However, recent practical analysis by Filippo Valsorda reveals that breaking AES‑128 with Shor’s algorithm would require an astronomically parallel quantum system – 140 trillion circuits of 724 logical qubits running for a decade – pushing real-world feasibility decades into the future. This article separates quantum hype from reality and provides actionable guidance for security teams to harden cryptographic implementations today.
Learning Objectives:
- Assess the practical versus theoretical risks of Shor’s algorithm against symmetric encryption (AES‑128).
- Implement cryptographic agility and post‑quantum readiness using open‑source tools and configuration hardening.
- Apply monitoring, logging, and key management practices to protect against classical and near‑term quantum threats.
You Should Know:
1. Practical Quantum Threat Modeling for AES‑128
The post’s core insight: Shor’s algorithm halves the effective key strength of symmetric ciphers in theory, but that translation to “AES‑128 is unsafe” ignores astronomical resource requirements. To break a single AES‑128 key, an attacker would need 140 trillion quantum circuits, each with 724 logical qubits, running error‑free for 10 years. Even optimistic projections place such capability beyond 2050. For comparison, breaking AES‑256 would require exponentially more resources, making it effectively quantum‑safe for the foreseeable future.
Step‑by‑step guide to update your encryption risk assessment:
- Inventory symmetric key usage: Find all systems using AES‑128 (TLS ciphers, disk encryption, database encryption).
Linux: `openssl ciphers -v | grep -i aes-128`
Windows (PowerShell): `Get-TlsCipherSuite | Where-Object Name -like “AES128″`
- Prioritize migration to AES‑256 for long‑lived data (storage duration >10 years).
Example: Convert LUKS AES‑128 to AES‑256 (requires re-encryption):
`cryptsetup luksConvertKey –key-slot 0 –new-key-slot 1 /dev/sdX` (then change cipher)
– Document “quantum safety margin” in your risk register: treat AES‑128 as safe for data with shelf life <2035, AES‑256 for all other use cases.
2. Implementing Cryptographic Agility with Hybrid Schemes
Since quantum computers may eventually arrive, prepare your systems to switch algorithms without full redeployment. Cryptographic agility allows replacing AES‑128 with AES‑256 or adding post‑quantum key exchange (e.g., CRYSTALS‑Kyber). Use tools that support multiple backends.
Step‑by‑step guide for TLS hybrid configuration (OpenSSL 3.0+):
- Install OpenSSL 3.x with post‑quantum providers (e.g., liboqs):
git clone https://github.com/open-quantum-safe/liboqs && cd liboqs mkdir build && cd build && cmake -DOPENSSL_ROOT_DIR=/usr/include/openssl .. && make -j$(nproc) && sudo make install
- Generate a hybrid certificate (RSA + Kyber) for testing:
`openssl req -x509 -newkey rsa:2048 -keyout hybrid.key -out hybrid.crt -days 365 -nodes`
– Configure a test TLS server with hybrid KEX:
`openssl s_server -cert hybrid.crt -key hybrid.key -groups kyber512:x25519 -cipher AES256-GCM-SHA384`
– Verify client support using `openssl s_client -connect localhost:4433 -groups kyber512`For Windows (IIS/Schannel), monitor Microsoft’s post‑quantum updates; currently rely on AES‑256 and ECDHE‑P521.
- Hardening Key Management Against Classical and Quantum Harvesting
Attackers may “harvest now, decrypt later” – collect encrypted traffic today and break it when quantum computers mature. To mitigate, enforce Perfect Forward Secrecy (PFS) and rotate keys frequently.
Step‑by‑step guide to configure PFS and key rotation:
- Linux (OpenSSH): Edit `/etc/ssh/sshd_config` to enforce PFS ciphers:
`KexAlgorithms curve25519-sha256,diffie-hellman-group-exchange-sha256`
`Ciphers [email protected],[email protected]`
Restart: `systemctl restart sshd`
- Windows (PowerShell) – configure Schannel PFS:
`New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms” -Name “DiffieHellman” -Value “0xffffffff” -PropertyType DWord`
– Automate symmetric key rotation for stored data (e.g., LUKS):
`cryptsetup luksAddKey /dev/sdX –key-slot 2 –new-key-file new.key`
then `cryptsetup luksRemoveKey /dev/sdX –key-slot 0` (old key)
- Monitor harvested‑data risk using Zeek logs for TLS handshakes lacking PFS:
`zeek -C -r capture.pcap | grep -v “curve25519” > non_pfs_sessions.log`
4. Benchmarking AES‑128 vs AES‑256 Performance Impact
Many teams resist AES‑256 due to perceived performance penalties. In practice, software AES‑256 is 10–20% slower than AES‑128; hardware‑accelerated (AES‑NI) reduces this to under 5%. Quantum safety far outweighs the negligible overhead.
Step‑by‑step benchmark on Linux:
- Install `openssl speed` benchmark:
`openssl speed -bytes 1024 -evp aes-128-gcm aes-256-gcm`
- On Windows with Cygwin/WSL or use PowerShell `Measure-Command` with .NET’s
AesCryptoServiceProvider.
Example PowerShell:
Add-Type -AssemblyName System.Security
$aes128 = [System.Security.Cryptography.AesCryptoServiceProvider]::new()
$aes128.KeySize = 128; $aes256 = [System.Security.Cryptography.AesCryptoServiceProvider]::new()
$aes256.KeySize = 256
Measure-Command { for($i=0;$i -lt 10000;$i++) { $aes128.CreateEncryptor().TransformFinalBlock(@(0)1024,0,1024) } }
Measure-Command { for($i=0;$i -lt 10000;$i++) { $aes256.CreateEncryptor().TransformFinalBlock(@(0)1024,0,1024) } }
– If overhead exceeds 15% on legacy hardware, prioritize AES‑256 for high‑value assets and keep AES‑128 for low‑risk, ephemeral traffic.
5. Monitoring for Emerging Quantum‑Related Vulnerabilities
While Shor’s algorithm isn’t practical yet, research on Grover’s algorithm (quadratic speedup for brute‑force) and side‑channel attacks on post‑quantum implementations is active. Set up detection for anomalous cryptanalytic attempts.
Step‑by‑step monitoring with Zeek and Suricata:
- Deploy Suricata rules to detect unusual TLS extensions (e.g., post‑quantum key exchange attempts):
`alert tls any any -> any any (msg:”PQC KEX detected”; tls.sni; content:”|00 2f|”; depth:2; sid:1000001;)`
– Use Zeek’s `ssl.log` to track cipher suites and flag weak ones:
`cat ssl.log | zeek-cut cipher | sort | uniq -c | sort -nr`
– For Linux kernel crypto usage, audit withauditd:
`auditctl -a always,exit -F arch=b64 -S bind -k crypto_usage`
`ausearch -k crypto_usage | grep -E “aes128|aes256” > crypto.log`
– Implement log aggregation and alert when AES‑128 appears in long‑lived sessions:
`jq ‘select(.cipher | contains(“AES128”))’ /var/log/zeek/ssl.log | jq ‘.uid,.duration’`
What Undercode Say:
- Key Takeaway 1: Theoretical quantum threats often ignore engineering reality – AES‑128 remains safe for the next two decades based on current physics and cost estimates. Organisations should not panic‑migrate from AES‑128, but they must plan gradual transitions to AES‑256 and hybrid schemes.
- Key Takeaway 2: Cryptographic agility and perfect forward secrecy are non‑negotiable defences against both classical and future quantum “harvest now, decrypt later” attacks. Automated key rotation, logging, and cipher suite monitoring provide immediate value regardless of quantum progress.
Analysis: The LinkedIn post by Rob Hulsebos highlights a critical gap between academic quantum computing claims and practical cryptanalysis. Filippo Valsorda’s 140‑trillion‑circuit estimate for breaking AES‑128 demonstrates that even with modest improvements in qubit quality, the cost and parallelism required remain astronomical. For security professionals, this means prioritising classical threats (side‑channel, implementation flaws, broken random number generators) over near‑term quantum fears. However, organisations with data that must remain confidential for 30+ years (government, healthcare, financial archives) should adopt AES‑256 and begin testing post‑quantum KEX libraries like liboqs. The real risk is not Shor’s algorithm today, but inertia – failing to implement basic crypto hygiene and agility.
Prediction:
By 2035, quantum computers with up to 10,000 logical qubits will exist, but breaking a single AES‑128 key will still require energy equivalent to a small country. Instead, quantum advantages will first appear in optimisation and simulation, not cryptanalysis. Consequently, regulatory frameworks (e.g., NIST’s post‑quantum cryptography timeline) will push mandatory AES‑256 for all federal systems by 2030, while the private sector follows more slowly – except for platforms handling mass surveillance data, which will deploy hybrid schemes by 2028. The biggest disruptor will be a side‑channel attack on a post‑quantum algorithm’s implementation, not Shor’s algorithm itself. Security teams should treat quantum readiness as a gradual, low‑urgency project, not an immediate fire drill.
▶️ Related Video (82% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Rob Hulsebos – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
