Quantum Readiness: The Credential Paradox (Why PQC Starts at Identity)
We’ve all seen the 'Harvest Now, Decrypt Later' warnings, but the latest piece on The Hacker News really drives home why credentials are the tip of the spear for Post-Quantum Cryptography (PQC). It’s not just about state secrets; it’s about the long tail of identity data.
If adversaries are scraping encrypted password databases or Kerberos tickets today, they don't need a quantum computer now. They just need to store the ciphertext and wait for RSA/ECC to crumble. Since credentials often live for years without rotation, they are the most vulnerable asset in a post-quantum world.
The Technical Shift We need to start auditing our reliance on vulnerable public-key algorithms, specifically RSA-2048 and elliptic curves like P-256. NIST has already standardized algorithms like CRYSTALS-Kyber (ML-KEM) for key encapsulation, but adoption is slow.
Inventory Check The first step is knowing what you have. Here is a quick snippet to scan a directory for legacy RSA keys in your environment:
#!/bin/bash
# Scan for RSA private keys
echo "Scanning for RSA keys..."
find /etc/ssl -name "*.key" -o -name "*.pem" | while read file; do
if openssl pkey -in "$file" -text -noout 2>/dev/null | grep -q "RSA"; then
echo "[!] RSA Key found: $file"
fi
done
Are any of you actively inventorying cryptographic assets for PQC migration yet? Or is this still on the 'next year' backlog for your orgs?
From a SOC perspective, we're already tuning our rules to detect massive 'low and slow' exfiltration. If they're harvesting encrypted blobs to decrypt later, we should see the traffic volume spike even if the payload is opaque.
I'm using this KQL query in Sentinel to flag potential harvesting events involving database dumps:
DeviceNetworkEvents
| where RemotePort == 443
| where InitiatingProcessFileName in ("sqlplus", "mysqldump", "pg_dump")
| where SentBytes > 50000000
| project Timestamp, DeviceName, InitiatingProcessFileName, RemoteIP, SentBytes
It’s noisy, but better than missing the harvest.
The Active Directory angle is what keeps me up. If an attacker grabs the krbtgt account NTLM hash or DPAPI master keys today, a future quantum capability decrypting the Kerberos session tickets would be catastrophic.
We are pushing for aggressive krbtgt password rotation and testing LAPS. However, true PKC resistance in AD likely won't be mainstream until Microsoft fully integrates hybrid signatures in the authentication stack.
Inventory is the hardest part. I tried scanning for keys with a similar script, but we found thousands of hardcoded keys in CI/CD pipelines and ancient Docker layers.
For those starting the migration, look at OpenSSL 3.0. It already has a provider architecture that allows swapping in algorithms like Kyber for testing without ripping out your entire application logic. It’s a good way to future-proof the dev pipeline while you wait for the hardware vendors to catch up.
Great points all around. One thing I'd add: prioritize by credential lifetime, not just volume. Short-lived OAuth tokens rotating hourly? Low priority for PQC migration. Root CAs, long-lived SSH keys, and service accounts with static passwords that haven't rotated in years? Those are your true "harvest now" targets.
For inventory beyond CI/CD, gitleaks paired with trufflehog has been effective for us:
gitleaks detect --source . --report-path leaks.
trufflehog filesystem --directory . -- > secrets.
Also worth checking out the Open Quantum Safe project — their liboqs provider for OpenSSL lets you test PQC algorithms in existing TLS infrastructure without a full rip-and-replace.
Question: is anyone seeing real vendor support for hybrid TLS (classical + PQC) in production yet, or are we all still in "wait and see" mode?
Great insight on lifetime, Steve. Beyond inventorying keys, we must audit the issuance systems creating the debt. If your Active Directory Certificate Services (AD CS) still issue templates with sub-3072-bit RSA keys, you’re extending the vulnerability window. I run this PS snippet to identify weak templates needing immediate deprecation or reconfiguration:
Get-ADObject -LDAPFilter "(objectClass=pKICertificateTemplate)" -Properties msPKI-Minimal-Key-Size | Where-Object {$_.'msPKI-Minimal-Key-Size' -lt 3072} | Select Name, @{N='KeySize';E={$_.'msPKI-Minimal-Key-Size'}}
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access