पोस्ट-क्वांटम TLS वह HTTPS है जो किसी बड़े क्वांटम कंप्यूटर वाले attacker के खिलाफ भी सुरक्षित रहता है। यह आज के key exchange के पीछे के math को — जिसे एक क्वांटम कंप्यूटर तोड़ सकता है — ऐसे algorithms से बदल देता है जो क्वांटम attacks का सामना करने के लिए design किए गए हैं।
यह कोई दूर का research project नहीं है। मध्य-2026 तक, Cloudflare के ज़रिए चलने वाले 65% से ज़्यादा मानव वेब ट्रैफ़िक पहले से ही पोस्ट-क्वांटम एन्क्रिप्टेड है, और Chrome, Edge और Firefox जब भी server support करता है तब default रूप से क्वांटम-सेफ key exchange negotiate करते हैं। अगर आपने हाल ही में किसी आधुनिक browser पर Google visit किया है, तो आपने लगभग निश्चित रूप से बिना ध्यान दिए पोस्ट-क्वांटम TLS इस्तेमाल किया है।
classical TLS खतरे में क्यों है
आज का TLS दो तरह के public-key math पर निर्भर करता है:
- Key exchange (ECDHE, X25519 या P-256 का उपयोग करते हुए) — एक खुले channel पर shared secret पर सहमति बनाता है।
- Signatures (RSA, ECDSA) — साबित करता है कि certificate authentic है।
दोनों ऐसी समस्याओं पर निर्भर करते हैं जो classical कंप्यूटरों के लिए कठिन हैं — बड़ी संख्याओं को factor करना (RSA) और elliptic-curve discrete logarithm (ECC)। एक पर्याप्त रूप से बड़े क्वांटम कंप्यूटर पर चलने वाला Shor का algorithm दोनों को कुशलता से हल कर देता है। एक “cryptographically relevant quantum computer” (CRQC) अभी मौजूद नहीं है, लेकिन यह क्षेत्र इतनी तेज़ी से आगे बढ़ रहा है कि योजना “अगर” से बदलकर “कब” पर आ गई है।
पब्लिक-की क्रिप्टोग्राफी → उस underlying math को समझाती है जिसे क्वांटम कंप्यूटर खतरे में डालते हैं।
“अभी इकट्ठा करो, बाद में डिक्रिप्ट करो” — यह आज क्यों ज़रूरी है
आप सोच सकते हैं कि कोई जल्दबाज़ी नहीं है: कोई भी क्वांटम कंप्यूटर आज TLS को नहीं तोड़ सकता, तो अभी switch क्यों करें?
खतरा है अभी इकट्ठा करो, बाद में डिक्रिप्ट करो (harvest now, decrypt later — HNDL)। एक adversary आज आपके एन्क्रिप्टेड ट्रैफ़िक को record करता है और उसे store कर लेता है। जब कोई क्वांटम कंप्यूटर उपलब्ध हो जाता है — संभवतः 2030 के दशक में — तो वे store किए गए ट्रैफ़िक को पूर्वव्यापी रूप से decrypt कर लेते हैं।
इससे key exchange की समय-सीमा क्वांटम कंप्यूटरों के आगमन से काफ़ी पहले आ जाती है। लंबी गोपनीयता-अवधि वाले किसी भी डेटा को — health records, financial data, सरकारी रहस्य, source code, credentials — अभी क्वांटम-सेफ एन्क्रिप्शन की ज़रूरत है, क्योंकि recording पहले से ही हो रही है।
Key exchange ज़रूरी है। Signatures उतनी नहीं। जो ट्रैफ़िक पहले ही हो चुका है उस पर आप पूर्वव्यापी रूप से signature forge नहीं कर सकते — एक signature को बस क्वांटम कंप्यूटरों के मौजूद होने से पहले क्वांटम-सेफ होना चाहिए, उससे पहले नहीं। यही कारण है कि industry ने पहले पोस्ट-क्वांटम key exchange को deploy किया।
standards: ML-KEM और ML-DSA
अगस्त 2024 में, NIST ने पहले अंतिम रूप दिए गए पोस्ट-क्वांटम standards publish किए:
| Standard | नाम | भूमिका | किसे बदलता है |
|---|---|---|---|
| FIPS 203 | ML-KEM (पूर्व में Kyber) | Key encapsulation (key exchange) | ECDHE / RSA key exchange |
| FIPS 204 | ML-DSA (पूर्व में Dilithium) | Digital signatures | RSA / ECDSA signatures |
| FIPS 205 | SLH-DSA (SPHINCS+) | Hash-based signatures | रूढ़िवादी signature backup |
ML-KEM (Module-Lattice Key Encapsulation Mechanism) वही है जो TLS में पहले से deploy किया जा चुका है। यह तीन आकारों में आता है: ML-KEM-512, ML-KEM-768, और ML-KEM-1024। ML-KEM-768 वह sweet spot है जिसका उपयोग वेब पर होता है।
Hybrid key exchange: X25519MLKEM768
Browsers रातोंरात classical crypto छोड़कर pure पोस्ट-क्वांटम पर switch नहीं करते। यह लापरवाही होगी — ML-KEM नया है, और कोई खामी सब कुछ तोड़ सकती है। इसके बजाय, TLS 1.3 एक hybrid key exchange का उपयोग करता है जो एक classical और एक पोस्ट-क्वांटम algorithm को जोड़ता है।
2026 में आप जो named group देखेंगे वह है X25519MLKEM768:
X25519MLKEM768 = X25519 (classical ECDHE) + ML-KEM-768 (post-quantum)दोनों shared secrets को concatenate किया जाता है (X25519 से 32 bytes + ML-KEM से 32 bytes = एक 64-byte संयुक्त secret) और TLS key schedule में feed किया जाता है।
सुरक्षा की गारंटी है “सुरक्षित अगर दोनों में से कोई एक टिकता है।” session key को recover करने के लिए एक attacker को X25519 और ML-KEM-768 दोनों को तोड़ना होगा। तो:
- अगर ML-KEM-768 में कोई खामी निकलती है → X25519 फिर भी आपकी रक्षा करता है (classical attackers के खिलाफ)।
- अगर कोई क्वांटम कंप्यूटर X25519 को तोड़ देता है → ML-KEM-768 फिर भी आपकी रक्षा करता है।
यह दोहरी-सुरक्षा वाला design ही कारण है कि हर जगह hybrid default है, pure पोस्ट-क्वांटम नहीं।
यह handshake में कहाँ फ़िट होता है
Hybrid key exchange वही TLS 1.3 handshake उपयोग करता है जिसका वर्णन TLS 1.3 क्या है → में किया गया है। एकमात्र अंतर key_share का है: ClientHello एक plain X25519 के बजाय एक X25519MLKEM768 key share ले जाता है। ML-KEM keys बड़ी होती हैं (~1.2 KB बनाम 32 bytes), इसलिए ClientHello लगभग एक kilobyte बढ़ जाता है — आमतौर पर नगण्य, हालाँकि सीमित networks पर यह कभी-कभी packet boundaries के पार फैल सकता है।
यह आपको forward secrecy → भी देता है: हर connection के लिए एक नया key pair, पोस्ट-क्वांटम संस्करण।
2026 में क्या पहले से deploy हो चुका है
| Component | पोस्ट-क्वांटम स्थिति (मध्य-2026) |
|---|---|
| Chrome / Edge | X25519MLKEM768 default रूप से negotiate किया जाता है |
| Firefox | X25519MLKEM768 supported और enabled |
| Cloudflare | 65%+ मानव ट्रैफ़िक PQ-एन्क्रिप्टेड; key exchange पूरा |
| पोस्ट-क्वांटम key exchange serve करता है | |
| AWS | KMS, ACM, Secrets Manager में ML-KEM; 2026 में legacy Kyber हटा रहा है |
| OpenSSL 3.5+ | Native ML-KEM और X25519MLKEM768 support |
| Java (SunJSSE) | X25519MLKEM768 default रूप से enabled |
जो हिस्सा अभी बड़े पैमाने पर पूरा नहीं हुआ है वह है पोस्ट-क्वांटम certificates — certificates को RSA/ECDSA के बजाय ML-DSA से sign करना। ML-DSA signatures और public keys कहीं ज़्यादा बड़ी होती हैं (kilobytes बनाम ~64 bytes), जो handshake को फुला देती हैं और certificate-chain के आकार की सीमाओं पर दबाव डालती हैं। Cloudflare मध्य-2026 तक origin connections पर ML-DSA लाने की योजना बना रहा है और आकार को नियंत्रण में रखने के लिए Merkle Tree Certificates की खोज कर रहा है, जिसका लक्ष्य 2029 तक पूर्ण पोस्ट-क्वांटम (authentication सहित) हासिल करना है।
कैसे जाँचें कि आप पोस्ट-क्वांटम TLS इस्तेमाल कर रहे हैं
browser में
Chrome में कोई भी प्रमुख साइट खोलें → DevTools → Security tab → connection विवरण देखें। एक पोस्ट-क्वांटम connection X25519MLKEM768 जैसा key exchange दिखाता है (या पुराने builds पर X25519Kyber768)।
OpenSSL 3.5+ के साथ
openssl s_client -connect cloudflare.com:443 -groups X25519MLKEM768 2>/dev/null | grep -i "Negotiated TLS1.3 group"
# अपेक्षित: Negotiated TLS1.3 group: X25519MLKEM768अगर आपको कोई error या कोई अलग group मिलता है, तो या तो आपका OpenSSL 3.5 से पुराना है या server अभी तक पोस्ट-क्वांटम key exchange offer नहीं करता।
अपना OpenSSL संस्करण जाँचें
openssl version
# ज़रूरी: native X25519MLKEM768 के लिए OpenSSL 3.5+अपने server पर इसे कैसे enable करें
अधिकांश साइटों के लिए जवाब है upgrade करें और इसे disable न करें — एक बार आपका stack support कर ले, तो पोस्ट-क्वांटम hybrid key exchange स्वतः enable हो जाता है।
Nginx / Apache
पोस्ट-क्वांटम key exchange आपकी TLS library में रहता है, web server config में नहीं। OpenSSL 3.5+ (या ML-KEM के साथ BoringSSL) के विरुद्ध build या run करें। एक बार link होने पर, X25519MLKEM768 स्वतः X25519 के साथ offer हो जाता है — किसी नए directive की ज़रूरत नहीं। ssl_ecdh_curve को किसी एक classical curve पर pin न करें, वरना आप hybrid group को बाहर कर देंगे।
किसी CDN के पीछे
सबसे आसान रास्ता: अपनी साइट को Cloudflare (या किसी अन्य PQC-सक्षम CDN) के पीछे रखें। browser-से-edge connection तुरंत पोस्ट-क्वांटम बन जाता है, आपके origin में कोई बदलाव किए बिना। इसी तरह उस 65% ट्रैफ़िक का ज़्यादातर हिस्सा क्वांटम-सेफ बना — operators ने अपने origin servers को छुआ तक नहीं।
आपका certificate अभी नहीं बदलता
पोस्ट-क्वांटम key exchange के लिए आपको एक नए certificate की ज़रूरत नहीं है। आपका मौजूदा RSA या ECC certificate बढ़िया काम करता है — hybrid key exchange session की रक्षा करता है, जबकि certificate फ़िलहाल classical signatures का ही उपयोग करता है। पोस्ट-क्वांटम certificates (ML-DSA) एक अलग, बाद में होने वाला migration है।
अक्सर पूछे जाने वाले प्रश्न
क्या मुझे कोई विशेष “क्वांटम-सेफ certificate” खरीदना ज़रूरी है?
नहीं। पोस्ट-क्वांटम key exchange (ज़रूरी हिस्सा) आपके certificate को बिल्कुल नहीं छूता — आपका मौजूदा RSA/ECC cert काम करता रहता है। आज जो कोई भी “क्वांटम-सेफ SSL certificate” बेच रहा है वह ज़्यादातर marketing है; production पोस्ट-क्वांटम signatures (ML-DSA) अभी public CAs द्वारा व्यापक रूप से जारी नहीं किए जाते।
क्या पोस्ट-क्वांटम TLS धीमा है?
मुश्किल से। ML-KEM-768 computationally तेज़ है — अक्सर ECDHE से भी तेज़। मुख्य लागत आकार की है: बड़े key shares handshake में ~1 KB जोड़ते हैं, जिसकी कीमत केवल बहुत छोटी packet सीमाओं वाले networks पर ही एक अतिरिक्त round trip हो सकती है। लगभग सभी users के लिए यह अंतर अमापनीय है।
क्वांटम कंप्यूटर वास्तव में RSA को कब तोड़ेंगे?
कोई नहीं जानता। विश्वसनीय अनुमान 2030 के दशक की शुरुआत से लेकर “शायद बड़े पैमाने पर कभी नहीं” तक के हैं। लेकिन harvest-now-decrypt-later के कारण, key exchange के लिए deployment की समय-सीमा पहले ही आ चुकी है — और ठीक इसीलिए browsers और CDNs ने इंतज़ार करने के बजाय 2024–2026 में कदम उठाया।
TLS 1.2 का क्या?
पोस्ट-क्वांटम hybrid key exchange केवल TLS 1.3 के लिए परिभाषित है। यह TLS 1.3 → को enable करने का एक और कारण है — यही क्वांटम-सेफ HTTPS का एकमात्र रास्ता है। TLS 1.2 को पोस्ट-क्वांटम key exchange नहीं मिलेगा।
क्या ML-KEM, Kyber जैसा ही है?
हाँ — ML-KEM उस algorithm का NIST-standardized संस्करण है जिसे पहले CRYSTALS-Kyber कहा जाता था। पुराने browser builds और tools Kyber768 दिखाते हैं; standardized deployments ML-KEM-768 का उपयोग करते हैं। वे निकटता से संबंधित हैं लेकिन bit-दर-bit समान नहीं हैं, इसलिए एक final-standard client और एक pre-standard server negotiate करने में विफल हो सकते हैं। 2026 तक ecosystem काफ़ी हद तक final ML-KEM की ओर बढ़ चुका है।
क्या मुझे अभी कुछ करना चाहिए?
एक सामान्य website के लिए: सुनिश्चित करें कि आप TLS 1.3 पर हैं, अपनी TLS library को current रखें (OpenSSL 3.5+), और अगर आप लंबे समय तक चलने वाला संवेदनशील डेटा संभालते हैं तो एक PQC-सक्षम CDN पर विचार करें। आज क्वांटम-सेफ key exchange पाने के लिए इतना काफ़ी है। पोस्ट-क्वांटम certificates standards और CA tooling के परिपक्व होने का इंतज़ार कर सकते हैं।