The "It Works on My Machine" Problem — But for Cryptography

The quantum computing threat isn't theoretical anymore — it's a timeline. Here's why every developer needs to start preparing now.

The "It Works on My Machine" Problem — But for Cryptography

Most developers never think about which cryptographic algorithm their application uses. It's hidden behind libraries, frameworks, and APIs. But here's the uncomfortable truth:

If your application uses RSA, ECC, or Diffie-Hellman, a sufficiently powerful quantum computer can break it.

This isn't a "maybe someday" problem. It's a "when, not if" problem — and the migration will take years. Developers need to start understanding their cryptographic footprint now.

Why This Is a Developer Problem

Post-quantum security isn't just for cryptographers. Developers make the architectural decisions that determine whether an application is quantum-ready:

• Library choices: Which crypto library are you using? Does it support PQC?
• Key management: Where are keys generated, stored, and rotated?
• Protocol selection: Are you using TLS 1.3 with hybrid key exchange?
• Data retention: How long does sensitive data need to remain encrypted?
• Architecture: Is crypto abstracted behind an interface, or hardcoded?

Every one of these decisions affects your application's quantum resilience.

Harvest Now, Decrypt Later

This is the most urgent threat most developers don't know about.

The concept is simple:

1. An adversary captures encrypted data today
2. They store it securely
3. Years from now, when quantum computers arrive, they decrypt it

Think about what data your application handles that needs to stay confidential for years:

The critical insight is that RSA and ECC are broken by Shor's algorithm, while AES-256 is only weakened by Grover's algorithm (reducing effective security from 256-bit to 128-bit, which is still strong). So not all encryption is equally vulnerable.

Crypto Agility: The Architecture Pattern You Need

Crypto agility is the ability to swap cryptographic algorithms without rewriting your application. It's the software engineering equivalent of dependency injection — but for cryptography.

Here's the problem: most applications have crypto hardcoded throughout the codebase:

# BAD: Hardcoded crypto
from cryptography.hazmat.primitives.asymmetric import rsa

def generate_key():
    return rsa.generate_private_key(
        public_exponent=65537,
        key_size=2048  # Quantum-vulnerable!
    )

When you need to migrate to PQC, you'd have to find and change every instance. With crypto agility:

# BETTER: Abstracted crypto
class CryptoProvider:
    def __init__(self, algorithm: str):
        self.algorithm = algorithm
    
    def generate_key(self):
        if self.algorithm == "rsa-2048":
            return self._generate_rsa(2048)
        elif self.algorithm == "ml-kem-512":
            return self._generate_mlkem(512)
        # Easy to add new algorithms!

# Application code never changes
provider = CryptoProvider(settings.CRYPTO_ALGORITHM)
key = provider.generate_key()

With this pattern, migrating from RSA to ML-KEM requires only a configuration change — no application code modifications.

Crypto Inventory: Know What You Use

Before you can migrate, you need to know what you have. A crypto inventory catalogs every cryptographic algorithm, key size, and implementation in your codebase.

Here's what a thorough inventory should find:

Use these commands to scan your Python projects:

# Find RSA/ECC usage
grep -rn "RSA\|ECDH\|ECDSA" --include="*.py" .

# Find deprecated hash usage
grep -rn "md5\|sha1" --include="*.py" .

# Find TLS configuration
grep -rn "SSL\|TLS" --include="*.py" .

# Check OpenSSL version
python -c "import ssl; print(ssl.OPENSSL_VERSION)"

Migration Is Not Just Swapping Algorithms

Migrating to post-quantum cryptography is a multi-year effort. Here's a realistic timeline:

The NIST Standards You Need to Know

NIST finalized the first post-quantum cryptography standards in August 2024:

These aren't proposals — they're finalized standards. Libraries like liboqs, PQCA, and BoringSSL already implement them.

What Developers Should Do Today

Try It Yourself

Start with a crypto inventory of your own project. Use the Quick Audit Commands to scan your codebase, then classify each finding by quantum risk.

Further Reading

• Post-Quantum Cryptography Explained — The technical foundations
• Quantum Computing for Software Developers — Understanding the quantum threat
• How HTTPS and TLS Actually Work — What needs to change
• Secrets Management for Developers — Protecting cryptographic keys
• Docker Security for Developers — Container security foundations

Regulatory information checked: August 2026. NIST FIPS 203, 204, 205 finalized August 13, 2024.