पोस्ट-क्वांटम क्रिप्टोग्राफी: डेवलपर्स को अभी क्या करना चाहिए

क्वांटम कंप्यूटर अभी आपके एन्क्रिप्शन के लिए खतरा नहीं हैं। RSA-2048 को तोड़ने में सक्षम एक क्वांटम कंप्यूटर को लाखों त्रुटि-सुधारित लॉजिकल क्यूबिट की आवश्यकता होगी — हमारे पास सैकड़ों शोरगुल वाले भौतिक क्यूबिट हैं। लेकिन समस्या यहाँ है: विरोधी अभी एन्क्रिप्टेड डेटा एकत्र कर रहे होंगे, इस इरादे से कि क्वांटम हार्डवेयर के परिपक्व होने पर बाद में उसे डिक्रिप्ट कर लेंगे। और क्रिप्टोग्राफिक इन्फ्रास्ट्रक्चर को माइग्रेट करने में वर्षों लगते हैं।

यही कारण है कि 2024 के NIST पोस्ट-क्वांटम क्रिप्टोग्राफी मानक डेवलपर्स के लिए आज मायने रखते हैं, 2035 में नहीं।

असली खतरा: Shor का एल्गोरिदम

1994 में, Peter Shor ने साबित किया कि एक क्वांटम कंप्यूटर बड़े पूर्णांकों को बहुपद समय O((log N)³) में गुणनखंडित कर सकता है। यह RSA को तोड़ता है, जिसकी सुरक्षा गुणनखंडन के कठिन होने पर निर्भर करती है। वही एल्गोरिदम — मामूली संशोधनों के साथ — एलिप्टिक कर्व क्रिप्टोग्राफी (ECC) को तोड़ता है, जो ECDSA और ECDH का आधार है।

क्या टूटता है:

• RSA (एन्क्रिप्शन, सिग्नेचर)
• ECDSA (साइनिंग — TLS, SSH, कोड साइनिंग, Bitcoin में उपयोग होता है)
• ECDH (कुंजी विनिमय — TLS, Signal, WhatsApp, iMessage में उपयोग होता है)
• Diffie-Hellman (कुंजी विनिमय)

क्या नहीं टूटता:

• AES-256 (सममित एन्क्रिप्शन) — Grover का एल्गोरिदम केवल द्विघाती गति प्रदान करता है, जो प्रभावी कुंजी शक्ति को 256 से घटाकर 128 बिट कर देता है। यह संभालने योग्य है।
• SHA-256, SHA-3 (हैश फ़ंक्शन) — वही: Grover मामूली गति प्रदान करता है, सुरक्षा आधी हो जाती है, फिर भी वर्तमान कुंजी आकारों के साथ पर्याप्त रूप से मज़बूत है
• HMAC — सुरक्षित
• Argon2, bcrypt (पासवर्ड हैशिंग) — सुरक्षित

निष्कर्ष यह है: असममित क्रिप्टोग्राफी को बदलने की आवश्यकता है; सममित क्रिप्टोग्राफी को कुंजी आकार में वृद्धि की आवश्यकता है (AES-128 → AES-256)।

अभी काटो, बाद में डिक्रिप्ट करो

खतरा यह नहीं है कि "क्वांटम कंप्यूटर अगले साल एन्क्रिप्शन तोड़ देंगे।" खतरा यह है:

1. एक विरोधी आज आपके एन्क्रिप्टेड TLS ट्रैफ़िक को कैप्चर करके संग्रहीत करता है
2. 2032–2040 में, वे उस पर Shor का एल्गोरिदम चलाते हैं
3. वे सब कुछ पूर्वव्यापी रूप से डिक्रिप्ट कर देते हैं

यह हमला — जिसे "harvest now, decrypt later" या HNDL कहा जाता है — पहले से ही हो रहा है। NSA और अन्य खुफिया एजेंसियाँ लगभग निश्चित रूप से बड़ी मात्रा में एन्क्रिप्टेड ट्रैफ़िक संग्रहीत कर रही हैं। 2022 की NSA सलाह ने इस बारे में स्पष्ट रूप से चेतावनी दी थी।

वह डेटा जिसे आज HNDL के विरुद्ध सुरक्षा की आवश्यकता है:

• राज्य के रहस्य, वर्गीकृत सरकारी डेटा
• लंबे समय तक चलने वाला व्यक्तिगत डेटा (चिकित्सा रिकॉर्ड, पहचान दस्तावेज़)
• लंबी नियामक प्रतिधारण आवश्यकताओं वाला वित्तीय डेटा
• व्यापार रहस्य और IP
• पासवर्ड डेटाबेस (हालाँकि bcrypt/Argon2 सुरक्षित हैं)

वह डेटा जिसके लिए तत्काल चिंता की आवश्यकता नहीं है:

• सेशन टोकन (अल्पकालिक, 10 वर्षों में बेकार)
• क्षणिक चैट संदेश (जब तक कि आप एक उच्च-मूल्य लक्ष्य न हों)
• सार्वजनिक जानकारी

NIST के पोस्ट-क्वांटम मानक (2024)

8 साल की प्रतियोगिता के बाद, NIST ने अगस्त 2024 में तीन पोस्ट-क्वांटम क्रिप्टोग्राफी एल्गोरिदम को अंतिम रूप दिया:

ML-KEM (CRYSTALS-Kyber) — कुंजी एनकैप्सुलेशन

• प्रतिस्थापित करता है: RSA कुंजी विनिमय, ECDH
• सुरक्षा आधार: Module Learning With Errors (MLWE) समस्या — शास्त्रीय और क्वांटम दोनों कंप्यूटरों के लिए कठिन मानी जाती है
• प्रदर्शन: तेज़, छोटी कुंजियाँ (KEM-768 के लिए ~800 बाइट), तेज़ ऑपरेशन
• इसके लिए उपयोग करें: TLS कुंजी विनिमय, एन्क्रिप्टेड कुंजी रैपिंग, हाइब्रिड एन्क्रिप्शन योजनाएँ

# Python example using pqcrypto library
from pqcrypto.kem.kyber768 import generate_keypair, encapsulate, decapsulate

public_key, secret_key = generate_keypair()

# Sender encapsulates a shared secret
ciphertext, shared_secret_sender = encapsulate(public_key)

# Receiver decapsulates
shared_secret_receiver = decapsulate(secret_key, ciphertext)

assert shared_secret_sender == shared_secret_receiver
# Now use shared_secret as AES key

ML-DSA (CRYSTALS-Dilithium) — डिजिटल सिग्नेचर

• प्रतिस्थापित करता है: साइनिंग के लिए ECDSA, RSA-PSS
• सुरक्षा आधार: MLWE + MSIS समस्याएँ
• प्रदर्शन: मध्यम कुंजी आकार (~1,312 बाइट सार्वजनिक कुंजी), तेज़ साइनिंग
• इसके लिए उपयोग करें: कोड साइनिंग, TLS सर्टिफिकेट, दस्तावेज़ साइनिंग, JWT सिग्नेचर

from pqcrypto.sign.dilithium3 import generate_keypair, sign, verify

public_key, secret_key = generate_keypair()

message = b"Deploy to production"
signature = sign(message, secret_key)

# Verify
assert verify(message, signature, public_key)

SLH-DSA (SPHINCS+) — हैश-आधारित सिग्नेचर

• प्रतिस्थापित करता है: एक रूढ़िवादी बैकअप के रूप में ECDSA
• सुरक्षा आधार: केवल हैश फ़ंक्शन — सबसे रूढ़िवादी विकल्प
• प्रदर्शन: बड़े सिग्नेचर (~8–50 KB), धीमी साइनिंग
• इसके लिए उपयोग करें: उच्च-आश्वासन वाली साइनिंग जहाँ कुंजी पुनः उपयोग एक चिंता है, दीर्घकालिक दस्तावेज़ साइनिंग

NIST ने FALCON (FN-DSA) को भी मानकीकृत किया — एक जालक (lattice) सिग्नेचर योजना जिसमें कॉम्पैक्ट सिग्नेचर होते हैं, जो IoT जैसे सीमित वातावरणों के लिए उपयुक्त है।

अभी क्या करें: एक स्तरित कार्य योजना

स्तर 1 — यह आज करें (कम प्रयास, उच्च प्रभाव)

अपनी क्रिप्टोग्राफिक इन्वेंट्री का ऑडिट करें। आप उसे माइग्रेट नहीं कर सकते जिसे आपने सूचीबद्ध नहीं किया है। दस्तावेज़ीकृत करें:

• आपका एप्लिकेशन TLS का उपयोग कहाँ करता है? (अधिकांश फ्रेमवर्क इसे संभालते हैं)
• आप सिग्नेचर कहाँ उत्पन्न या सत्यापित करते हैं? (JWTs, कोड साइनिंग, PDF साइनिंग)
• आप असममित कुंजी विनिमय का उपयोग कहाँ करते हैं? (RSA-रैप्ड AES कुंजियाँ, SSH)
• आप कौन-सी लाइब्रेरी का उपयोग कर रहे हैं? (OpenSSL, BouncyCastle, AWS KMS, आदि)

AES-128 को AES-256 में अपग्रेड करें। यह कम-जोखिम वाला और तत्काल है। AES-256, Grover के विरुद्ध 128-बिट सुरक्षा तक आधा हो जाता है — फिर भी पर्याप्त रूप से सुरक्षित।

हर जगह TLS 1.3 सक्षम करें। TLS 1.3 डिफ़ॉल्ट रूप से फॉरवर्ड सीक्रेसी (ECDHE) का उपयोग करता है, जिसका अर्थ है कि दीर्घकालिक कुंजी से समझौता होने पर भी पिछले सेशन डिक्रिप्ट नहीं किए जा सकते। यह TLS ट्रैफ़िक के लिए HNDL को आंशिक रूप से कम करता है।

स्तर 2 — अगले 6–18 महीनों के लिए योजना बनाएँ

TLS में हाइब्रिड कुंजी विनिमय अपनाएँ। TLS वर्किंग ग्रुप ने X25519Kyber768 को मानकीकृत किया है — एक हाइब्रिड योजना जो शास्त्रीय ECDH और ML-KEM दोनों का उपयोग करती है। Google Chrome, Cloudflare, और AWS पहले से ही इसका समर्थन करते हैं। यह शास्त्रीय सुरक्षा बनाए रखते हुए HNDL से बचाता है:

# Nginx with OpenSSL 3.x + oqs-provider (Open Quantum Safe)
ssl_ecdh_curve X25519Kyber768;  # hybrid classical + PQC

नई प्रणालियों में RSA/ECDSA को ML-DSA से बदलें। किसी भी नए सिरे से बनाई गई चीज़ के लिए — नए माइक्रोसर्विसेज़, नए JWT कार्यान्वयन, नई SSH तैनाती — ECDSA-256 के बजाय ML-DSA (Dilithium3 या Dilithium5) का उपयोग करें।

अपनी TLS सर्टिफिकेट पाइपलाइन को अपडेट करें। अधिकांश सार्वजनिक CA अभी तक PQC सर्टिफिकेट जारी नहीं करते, लेकिन आप आज आंतरिक रूप से हस्ताक्षरित सर्टिफिकेट और सर्विस मेश सर्टिफिकेट के लिए ML-DSA का उपयोग कर सकते हैं।

स्तर 3 — दीर्घकालिक माइग्रेशन (1–5 वर्ष)

पूर्ण PKI माइग्रेशन। अपने RSA/ECC सर्टिफिकेट पदानुक्रम को PQC-आधारित CA इन्फ्रास्ट्रक्चर से बदलें। यह सबसे कठिन हिस्सा है — हार्डवेयर सुरक्षा मॉड्यूल (HSMs), स्वचालित सर्टिफिकेट रोटेशन, और सर्टिफिकेट चेन सभी को अपडेट करने की आवश्यकता है।

हार्डवेयर और एम्बेडेड डिवाइस। IoT और एम्बेडेड डिवाइस अक्सर दूरस्थ रूप से पैच नहीं किए जा सकते और उनका जीवनकाल 10+ वर्ष होता है। ऐसे किसी भी डिवाइस का ऑडिट करें जो प्रमाणीकरण के लिए RSA या ECDSA पर निर्भर करता है।

कुंजी प्रबंधन प्रणालियाँ। AWS KMS, Azure Key Vault, HashiCorp Vault — उनके PQC रोडमैप और माइग्रेशन समयसीमा को सत्यापित करें।

लाइब्रेरी और फ्रेमवर्क समर्थन

एक-पृष्ठ सारांश

What breaks:    RSA, ECDSA, ECDH, classical DH
What's safe:    AES-256, SHA-256, SHA-3, bcrypt, Argon2
New standards:  ML-KEM (Kyber) for key exchange
                ML-DSA (Dilithium) for signatures
                SLH-DSA (SPHINCS+) for conservative signing

Do today:       Upgrade AES-128 → AES-256
                Enable TLS 1.3 (forward secrecy)
                Audit crypto inventory

Do soon:        Hybrid TLS key exchange (X25519Kyber768)
                ML-DSA for new signature systems

Do in 1-5 yrs:  Full PKI migration to PQC
                Firmware updates for IoT devices

क्रिप्टोग्राफी के लिए क्वांटम खतरा वास्तविक है और समयसीमा अनिश्चित है — यही ठीक वह कारण है कि अभी कार्रवाई करना, क्वांटम कंप्यूटरों के सक्षम होने से पहले, सही निर्णय है।

आगे पढ़ें: क्वांटम कंप्यूटिंग शब्दावली — Shor का एल्गोरिदम · क्वांटम कंप्यूटर आज क्या कर सकते हैं