I Built a Quantum-Proof Password Generator — Here’s Why You Should Care

Post-Quantum Cryptography isn’t science fiction anymore. NIST has standardized it, Go 1.24 has implemented it, and I deployed it to AWS Lambda. Here’s the full breakdown.

The Quantum Threat Is Already Here (Sort Of)

Here’s a scary thought: everything you encrypt today could be broken tomorrow.

Not because your encryption is weak — but because adversaries are playing the long game. It’s called “Harvest Now, Decrypt Later” (HNDL). State actors and sophisticated hackers are recording encrypted internet traffic right now, storing petabytes of data, waiting for quantum computers powerful enough to crack RSA and ECC in seconds.

When cryptographically relevant quantum computers (CRQCs) arrive — and experts predict within 10–15 years — all that stored traffic becomes an open book.

This is not hypothetical. This is why NIST spent 8 years selecting quantum-resistant algorithms.

What I Built

I created a Quantum-Safe Password Generator — a tool that:

1. Generates passwords with 260 bits of entropy (enough to resist quantum brute-force attacks via Grover’s Algorithm)
2. Protects transport using NIST FIPS 203 (ML-KEM-768) — the newly standardized post-quantum key encapsulation mechanism
3. Hashes credentials with Argon2id — memory-hard to defeat GPU/ASIC attacks
4. Runs entirely stateless — no database, no logs, credentials exist only in RAM and are immediately discarded

Live Demo: https://d27dga8b89srej.cloudfront.net

The Tech Stack

├── Go 1.25         → Backend with crypto/mlkem (FIPS 203)
├── AWS Lambda      → ARM64 Graviton2 (sub-100μs encryption)
├── CloudFront      → Edge CDN + SSL
├── WebAssembly     → Client-side ML-KEM decapsulation
└── Zero Database   → Pure stateless architecture

Why Go?

Go 1.24 introduced native support for FIPS 203 via the crypto/mlkem package. No CGO bindings, no external dependencies — just pure Go with constant-time implementations to resist side-channel attacks.

// ML-KEM-768 Key Encapsulation in Go 1.24
dk, _ := mlkem.GenerateKey768()
ek := dk.EncapsulationKey()
sharedSecret, ciphertext := ek.Encapsulate()

That’s it. Three lines to generate quantum-resistant encrypted transport.

The Math: Why 260 Bits?

Quantum computers don’t “break” symmetric encryption — they weaken it. Grover’s Algorithm provides a quadratic speedup for brute-force attacks, effectively halving your key’s bit strength.

ModeCharactersEntropy (Classical)Entropy (Quantum)Standard32 chars~206 bits~103 bitsExtreme40 chars~260 bits~130 bits

A 256-bit classical key becomes 128-bit against a quantum adversary. That’s still AES-128 level security — classified TOP SECRET by the NSA.

Get Puvaan Raaj’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

My generator’s “Extreme Mode” exceeds this threshold, providing 130 bits of quantum security.

The Architecture: “Null Database” Pattern

The most secure data is data that doesn’t exist.

┌─────────────────────────────────────────────────────────────┐
│                    USER REQUEST                             │
│  Browser → CloudFront → Lambda Function URL                 │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌──────────────────────────────────────────────────────────────┐
│                  AWS LAMBDA (RAM ONLY)                       │
│                                                              │
│  1. crypto/rand.Read() → 32 bytes of CSPRNG entropy          │
│  2. Generate password from 87-character alphabet             │
│  3. Compute Argon2id hash (memory-hard)                      │
│  4. ML-KEM-768 Encapsulate for transport proof               │
│  5. Return JSON → Context destroyed → Memory wiped           │
│                                                              │
│  ❌ No database                                              │
│  ❌ No logs                                                  │
│  ❌ No persistence                                           │
└─────────────────────────────────────────────────────────────┘

Why Lambda?

• Ephemeral execution contexts are destroyed after each request
• No disk access means no data remnants
• ARM64 (Graviton2) gives 30% better crypto performance vs x86

Client-Side Verification (WebAssembly)

Here’s the coolest part: I compiled the Go ML-KEM logic to WebAssembly.

The browser:

1. Generates its own ML-KEM-768 keypair locally
2. Sends the public key to the server
3. Receives the ciphertext
4. Decapsulates locally to verify the shared secret

This proves true end-to-end post-quantum transport — the private key never leaves the browser.

Performance (It’s Fast)

OperationTime (ARM64)ML-KEM Key Generation82 μsEncapsulation95 μsDecapsulation104 μsTotal crypto overhead<0.3 ms

The ciphertext adds 1,088 bytes to the payload. For comparison, older PQC candidates like McEliece had 200KB+ public keys. ML-KEM is production-ready.

What This Means For You

If you’re a developer:

• Start experimenting with crypto/mlkem (Go 1.24+)
• Hybrid approaches (X25519 + ML-KEM) are already in Chrome and Cloudflare
• Don’t wait for quantum computers to arrive

If you’re security-conscious:

• Use password managers with >128-bit entropy
• Prefer services that are migrating to PQC
• The HNDL threat is real — long-term secrets need protection today

Try It Yourself

🔗 Live Demo: passwords.zerostate.my

Final Thoughts

Post-Quantum Cryptography isn’t a future problem. It’s a present solution.

NIST has standardized FIPS 203. Go has implemented it. Cloud providers support it. The only thing missing is adoption.

This project is my small contribution to that adoption. A working, deployed, open-source example that proves PQC is not only possible — it’s practical, performant, and ready for production.

The quantum era is coming. Let’s be ready.

Tags: #PostQuantumCryptography #Security #Golang #AWS #Serverless #Cryptography #NIST