वह पल जिसे किसी ने कैलेंडर पर नहीं चिह्नित किया
पिछले तीस दिनों में, इंफ्रास्ट्रक्चर टीमों को TLS एन्क्रिप्शन के बारे में सोचने के तरीक़े में कुछ चुपचाप बदल गया। एक Java रिलीज़ ने हाइब्रिड पोस्ट-क्वांटम क्रिप्टोग्राफ़ी को डिफ़ॉल्ट बना दिया। एक स्टैंडर्ड्स बॉडी ने यह औपचारिक रूप दिया कि यह कैसे काम करता है। एक संघीय अनुपालन समय-सीमा आ पहुँची। और अचानक, एक तकनीक जो रिसर्च-डिपार्टमेंट का काम लगती थी, वह ऐसी चीज़ बन गई जिसे इंफ्रास्ट्रक्चर और सुरक्षा टीमों को वाक़ई संभालना होगा।
किसी ने प्रेस कॉन्फ़्रेंस नहीं की। कोई वेंडर रैली नहीं हुई। लेकिन पोस्ट-क्वांटम क्रिप्टोग्राफ़ी को लेकर बातचीत “आख़िरकार हमें इसके बारे में सोचना होगा” से बढ़कर “आपके संगठन की अनुपालन स्थिति शायद अभी बदल गई है, और हो सकता है आपको इसका पता भी न चला हो” बन गई।
यह लेख इंफ्रास्ट्रक्चर पेशेवरों, सुरक्षा टीमों और उन सभी के लिए है जिनके काम में TLS, सर्टिफ़िकेट प्रबंधन या अनुपालन समय-सीमाएँ पूरी करना शामिल है। इसमें बताया गया है कि अभी क्या हुआ, यह आपके लिए क्यों मायने रखता है, और असल में अगले व्यावहारिक क़दम क्या दिखते हैं।
इस महीने असल में क्या हुआ
अगस्त और सितंबर 2026 में तीन अलग-अलग घटनाएँ एक साथ हुईं, जो अकेले-अकेले देखने पर मामूली लगती हैं। साथ मिलकर, उन्होंने “इससे हम बाद में निपटेंगे” वाला रास्ता बंद कर दिया।
JDK 27 GA ने डिफ़ॉल्ट रूप से हाइब्रिड पोस्ट-क्वांटम TLS चुना। 15 सितंबर को, Java Development Kit वर्ज़न 27 जनरल एवेलेबिलिटी में आया, जिसमें TLS कनेक्शनों के लिए डिफ़ॉल्ट रूप से हाइब्रिड पोस्ट-क्वांटम क्रिप्टोग्राफ़ी सक्षम है। इसका मतलब है कि JDK 27 या उसके बाद के वर्ज़न पर चलने वाला हर Java एप्लिकेशन सर्वरों के साथ बातचीत करते समय एक साथ क्लासिकल RSA/ECDSA और पोस्ट-क्वांटम एल्गोरिदम दोनों का इस्तेमाल करने की कोशिश करेगा। अगर सर्वर अभी पोस्ट-क्वांटम को सपोर्ट नहीं करता तो क्लासिकल एल्गोरिदम फ़ॉलबैक के तौर पर बने रहते हैं। पोस्ट-क्वांटम वाले पहले आज़माए जाते हैं। यह कोई ऑप्ट-इन फ़्लैग नहीं है। यह डिफ़ॉल्ट व्यवहार है।
RFC 10024 ने औपचारिक रूप दिया कि हाइब्रिड पोस्ट-क्वांटम TLS कैसे काम करता है। अगस्त में, Internet Engineering Task Force ने वह स्टैंडर्ड प्रकाशित किया जो ठीक-ठीक बताता है कि क्लाइंट और सर्वर पोस्ट-क्वांटम एल्गोरिदम पर बातचीत कैसे करते हैं। इसने हाइब्रिड PQC को “कुछ वेंडर जिसके साथ प्रयोग कर रहे हैं” से बढ़ाकर “इंटरनेट के पास अब एक स्टैंडर्ड है” बना दिया। ऐसे इंफ्रास्ट्रक्चर चलाने वाले संगठन जिन्हें JDK क्लाइंट्स को संभालना है — चाहे वह आपके अपने एप्लिकेशन हों या ग्राहक-सामने वाली सेवाएँ — उन्हें ये नए एल्गोरिदम इस्तेमाल करने वाले TLS हैंडशेक दिखेंगे, चाहे आपने इसकी योजना बनाई हो या नहीं।
21 सितंबर को FIPS 140-2 Historical स्टेटस में चला गया। अमेरिका के National Institute of Standards and Technology (NIST) ने आधिकारिक रूप से FIPS 140-2 — वह क्रिप्टोग्राफ़ी स्टैंडर्ड जो दो दशकों से अधिकांश एंटरप्राइज़ सुरक्षा इंफ्रास्ट्रक्चर को नियंत्रित करता रहा है — को Historical के रूप में फिर से वर्गीकृत किया। FIPS स्टैंडर्ड के तहत काम करने के लिए बाध्य संगठनों — सरकारी एजेंसियाँ, संघीय ठेकेदार, अनुबंध के तहत संवेदनशील डेटा संभालने वाले संगठन — अब FIPS 140-3 में माइग्रेट करने की समय-सीमाओं का सामना कर रहे हैं। उस माइग्रेशन रास्ते में अब पोस्ट-क्वांटम क्रिप्टोग्राफ़िक एल्गोरिदम भी शामिल हैं।
ये तीनों घटनाएँ अलग-अलग कहानियाँ नहीं हैं। ये एक ही कहानी हैं, तीन अलग-अलग कोणों से: इंफ्रास्ट्रक्चर जगत ने पोस्ट-क्वांटम क्रिप्टोग्राफ़ी को फ़्यूचर-प्रूफ़िंग की तरह देखना बंद कर दिया है और अब इसे समय-सीमाओं वाली अनुपालन आवश्यकता के रूप में देखना शुरू कर दिया है।
पोस्ट-क्वांटम क्रिप्टोग्राफ़ी क्यों मौजूद है और अभी क्यों मायने रखती है
आधुनिक इंटरनेट सुरक्षा ऐसे एल्गोरिदम पर निर्भर करती है जिन्हें आज के कंप्यूटरों से सत्यापित करना आसान है लेकिन तोड़ना कंप्यूटेशनल रूप से असंभव है। आपके TLS सर्टिफ़िकेट में मौजूद पब्लिक की और आपके डेटा की रक्षा करने वाले क्लासिकल एन्क्रिप्शन तरीक़े ऐसी गणितीय समस्याओं पर निर्भर हैं — RSA के लिए बड़ी संख्याओं का गुणनखंडन, ECDSA के लिए इलिप्टिक-कर्व डिस्क्रीट लॉगरिथम — जिन्हें हल करने में हमारे पास मौजूद सबसे तेज़ क्लासिकल कंप्यूटरों को भी हज़ारों साल लगेंगे।
एक पर्याप्त शक्तिशाली क्वांटम कंप्यूटर उन समस्याओं को घंटों में हल कर सकता है। ऐसा कोई कंप्यूटर अभी मौजूद नहीं है। लेकिन क्रिप्टोग्राफ़ी विशेषज्ञों, राष्ट्रीय सुरक्षा एजेंसियों और स्टैंडर्ड्स बॉडीज़ ने एक कार्यशील धारणा के रूप में यह मान लिया है कि ऐसा कंप्यूटर आख़िरकार मौजूद होगा। समयरेखा अनिश्चित है — कुछ अनुमान दस साल कहते हैं, कुछ बीस या तीस। यह अनिश्चितता असल मुद्दा नहीं है। अगर आपके पास ऐसा डेटा है जिसे दशकों तक गोपनीय रहना ज़रूरी है, और अगर उस समयसीमा के भीतर क्वांटम कंप्यूटर व्यावहारिक बन जाता है, तो जो एन्क्रिप्शन आज काम करता है वह कल बेकार हो सकता है।
पोस्ट-क्वांटम क्रिप्टोग्राफ़ी एल्गोरिदम का एक परिवार है जो बड़े क्वांटम कंप्यूटर के मौजूद होने पर भी हल करना मुश्किल बना रहता है। NIST ने 2022 में एक स्टैंडर्डाइज़ेशन प्रक्रिया पूरी की, जिसमें इस आवश्यकता को पूरा करने वाले कई उम्मीदवारों की पहचान की गई। ये एल्गोरिदम अभी इस्तेमाल के लिए तैयार हैं।
यह अचानक मायने रखने की वजह यह नहीं है कि क्वांटम कंप्यूटर आ गए हैं। वजह यह है कि सरकारों और स्टैंडर्ड्स बॉडीज़ ने अब और इंतज़ार न करने का फ़ैसला कर लिया है।
22 जून, 2026 को, अमेरिकी संघीय सरकार ने Executive Order 14412, “Securing the Nation Against Advanced Cryptographic Attacks” जारी किया। यह संघीय एजेंसियों के उच्च-मूल्य और उच्च-प्रभाव वाले सिस्टम के लिए पोस्ट-क्वांटम की-स्थापना को सपोर्ट करने की समय-सीमा 31 दिसंबर, 2030 तय करता है, और पोस्ट-क्वांटम डिजिटल हस्ताक्षरों के लिए 31 दिसंबर, 2031। ये तारीख़ें दूर लगती हैं, लेकिन इस आदेश का अपना कार्यान्वयन मार्गदर्शन — OMB Memorandum M-26-15 — हस्ताक्षर के लगभग 90 दिनों बाद, यानी क़रीब 20 सितंबर, 2026 तक देय है, यही वजह है कि एजेंसियाँ और उनके ठेकेदार इंतज़ार करने के बजाय अभी इस काम की योजना बना रहे हैं। यूरोपीय संघ के दूरसंचार पर्यवेक्षकों ने अलग से संगठनों से 2026 के अंत तक मूल्यांकन करने और परिवर्तन शुरू करने को कहा है। NIST ने संगठनों को FIPS 140-2 पर अनिश्चित काल तक बने रहने का विकल्प नहीं दिया है। और अब, JDK 27 के दुनिया भर के Java एप्लिकेशनों के लिए डिफ़ॉल्ट व्यवहार बन जाने के साथ, उन एप्लिकेशनों की सेवा करने वाला इंफ्रास्ट्रक्चर पोस्ट-क्वांटम एल्गोरिदम को सपोर्ट करने की दिशा में धकेला जा रहा है, चाहे उन इंफ्रास्ट्रक्चर टीमों ने इसकी योजना बनाई हो या नहीं।
एक साथ रखकर देखें तो, अभी जो समय-सीमाएँ मायने रखती हैं वे इस तरह दिखती हैं:
| आवश्यकता | यह किन पर लागू होती है | समय-सीमा |
|---|---|---|
| FIPS 140-2 वैलिडेशन Historical स्टेटस में चले जाते हैं | नए क्रिप्टोग्राफ़िक मॉड्यूल ख़रीदने या वैलिडेट करने वाला कोई भी व्यक्ति | 21 सितंबर, 2026 |
| EO 14412 के लिए OMB M-26-15 कार्यान्वयन मार्गदर्शन | संघीय एजेंसियाँ | ~20 सितंबर, 2026 (हस्ताक्षर के 90 दिन बाद) |
| EU दूरसंचार PQC मूल्यांकन और परिवर्तन की शुरुआत | EU दूरसंचार ऑपरेटर | 2026 का अंत |
| EO 14412 — पोस्ट-क्वांटम की-स्थापना | संघीय उच्च-मूल्य और उच्च-प्रभाव वाले सिस्टम | 31 दिसंबर, 2030 |
| EO 14412 — पोस्ट-क्वांटम डिजिटल हस्ताक्षर | संघीय उच्च-मूल्य और उच्च-प्रभाव वाले सिस्टम | 31 दिसंबर, 2031 |
यह कोई वेंडर-प्रेरित ट्रेंड नहीं है। यह एक स्टैंडर्ड-प्रेरित और अनुपालन-प्रेरित वास्तविकता है।
यह असल में किन्हें प्रभावित करता है
अगर आपका संगठन इनमें से कोई भी चलाता है, तो पोस्ट-क्वांटम क्रिप्टोग्राफ़ी अब एक भविष्य की बात नहीं बल्कि एक व्यावहारिक चिंता है:
आप Java एप्लिकेशन चलाते हैं या ऐसा प्लेटफ़ॉर्म इस्तेमाल करते हैं जो JDK पर चलता है। जब वे एप्लिकेशन वर्ज़न 27 या उसके बाद वाले पर जाएँगे, तो वे पोस्ट-क्वांटम TLS कनेक्शन बनाने की कोशिश करेंगे। आपके इंफ्रास्ट्रक्चर को यह समझना होगा कि इसका क्या मतलब है और क्या आपकी TLS लाइब्रेरी और नेटवर्क एप्लायंस इसे सपोर्ट करते हैं।
आप ऐसा इंफ्रास्ट्रक्चर चलाते हैं जिसे FIPS अनुपालन पूरा करना ज़रूरी है। आपकी मौजूदा FIPS 140-2 अनुपालन स्थिति अब एक तय एंड-ऑफ़-लाइफ़ रास्ते पर है। FIPS 140-3 और पोस्ट-क्वांटम तरीक़ों में परिवर्तन अब वैकल्पिक टाइमिंग नहीं रहा — इसकी एक समय-सीमा है।
आप उन भूमिकाओं में काम करते हैं जहाँ सुरक्षा या इंफ्रास्ट्रक्चर एक अनुपालन चिंता है: सरकारी ठेकेदारी, हेल्थकेयर, वित्तीय सेवाएँ, या कोई भी उद्योग जहाँ नियामक आवश्यकताएँ आपकी तकनीक की पसंद को नियंत्रित करती हैं। आपके रेगुलेटर या ग्राहक को इस बात का पता चलने लगा है कि पोस्ट-क्वांटम माइग्रेशन मौजूद है, और सवाल आने शुरू हो गए हैं।
आप TLS लाइब्रेरी, लोड बैलेंसर, API गेटवे, या सर्टिफ़िकेट प्रबंधन इंफ्रास्ट्रक्चर बनाए रखते हैं जिनसे क्लाइंट एप्लिकेशन कनेक्ट होते हैं। क्लाइंट — ख़ासकर Java क्लाइंट — पोस्ट-क्वांटम एल्गोरिदम माँगना शुरू करेंगे। आपके सिस्टम को उन अनुरोधों को बिना टूटे संभालना होगा, भले ही आपकी अपनी रणनीति अभी तय हो रही हो।
अगर आपका संगठन Java वर्कलोड नहीं चलाता, FIPS अनुपालन आवश्यकताएँ नहीं रखता, और तीसरे-पक्ष के एप्लिकेशनों के लिए इंफ्रास्ट्रक्चर के रूप में काम नहीं करता, तो पोस्ट-क्वांटम क्रिप्टोग्राफ़ी अभी भी आख़िरकार मायने रखेगी, लेकिन आपकी समयसीमा शायद महीनों के बजाय सालों में मापी जाएगी।
आपको वाक़ई क्या समझने की ज़रूरत है: जानना बनाम इस्तेमाल करना बनाम महारत हासिल करना
जानना। आपको यह समझना चाहिए कि पोस्ट-क्वांटम क्रिप्टोग्राफ़ी एल्गोरिदम का एक सेट है जो क्वांटम कंप्यूटरों के सामने भी सुरक्षित रहता है, कि JDK 27 जैसे प्रमुख प्लेटफ़ॉर्म अब डिफ़ॉल्ट रूप से हाइब्रिड पोस्ट-क्वांटम TLS (जो क्लासिकल और पोस्ट-क्वांटम एल्गोरिदम को एक साथ इस्तेमाल करता है) पर जा रहे हैं, और यह कि संघीय और यूरोपीय संगठनों के लिए नियामक समय-सीमाएँ अब असली सीमाएँ हैं, भविष्य की योजना नहीं।
आपको यह समझने की ज़रूरत नहीं है कि पोस्ट-क्वांटम एल्गोरिदम कैसे काम करते हैं, इसका गणित क्या है। आपको ख़ुद क्रिप्टोग्राफ़ी करने की ज़रूरत नहीं है। आपको बस यह जानना होगा कि यह बदलाव हो रहा है, कि आपके इंफ्रास्ट्रक्चर को इन एल्गोरिदम का इस्तेमाल करने वाले TLS हैंडशेक मिल सकते हैं, और कि आपकी अनुपालन स्थिति बदल गई हो सकती है।
इस्तेमाल करना। अगर आप ऐसा इंफ्रास्ट्रक्चर बनाए रखते हैं जो Java एप्लिकेशनों की सेवा करता है, या अगर आपका संगठन FIPS अनुपालन आवश्यकताओं के अधीन है, तो आपको व्यावहारिक कार्यशील ज्ञान चाहिए। इसका मतलब है:
यह समझना कि आपकी TLS लाइब्रेरी हाइब्रिड पोस्ट-क्वांटम एल्गोरिदम को सपोर्ट करती हैं या नहीं। अधिकांश आधुनिक वर्ज़न करते हैं — OpenSSL, BoringSSL, Java की बिल्ट-इन JSSE, और अधिकांश क्लाउड प्लेटफ़ॉर्म TLS स्टैक ने सपोर्ट जोड़ा है — लेकिन “अधिकांश” का मतलब “आपकी वाली” नहीं है। इसके लिए दस्तावेज़ीकरण जाँचना और शायद टेस्ट करना ज़रूरी है।
यह जानना कि यह कैसे सत्यापित करें कि आपके लोड बैलेंसर, API गेटवे, या रिवर्स प्रॉक्सी बिना क्रैश हुए या कनेक्शन गिराए पोस्ट-क्वांटम TLS हैंडशेक संभाल सकते हैं। हाइब्रिड TLS बैकवर्ड कम्पैटिबल है — जो सर्वर पोस्ट-क्वांटम एल्गोरिदम सपोर्ट नहीं करते वे भी काम करते रहते हैं — लेकिन आपको यह भरोसा चाहिए कि आपका ख़ास इंफ्रास्ट्रक्चर हैंडशेक पर अटकता नहीं है।
अपने संगठन की FIPS अनुपालन स्थिति और समयसीमा को समझना। अगर आप FIPS 140-2 पर हैं, तो आपके पास माइग्रेट करने की एक समय-सीमा है। अगर नहीं हैं, तो आपके पास अनुपालन की तात्कालिकता नहीं है, लेकिन फिर भी आपको उन क्लाइंट्स को संभालना होगा जो पोस्ट-क्वांटम एल्गोरिदम माँग रहे हैं।
महारत हासिल करना। अगर आप किसी ऐसे संगठन के लिए TLS इंफ्रास्ट्रक्चर डिज़ाइन कर रहे हैं जो अनुपालन आवश्यकताओं के अधीन है, या अगर आप क्रिप्टोग्राफ़िक रणनीति के लिए ज़िम्मेदार सिक्योरिटी आर्किटेक्ट हैं, तो आपको हाइब्रिड PQC अपनाने की समयसीमाओं, सर्टिफ़िकेट प्रबंधन के असर (पोस्ट-क्वांटम सर्टिफ़िकेट बड़े होते हैं, जो कुछ सिस्टम को प्रभावित करता है), अलग-अलग एल्गोरिदम की परफ़ॉर्मेंस विशेषताओं, और माइग्रेशन के क्रम (कौन-से हिस्से पहले चलते हैं, ट्रांज़िशन के दौरान बैकवर्ड कम्पैटिबिलिटी कैसे बनाए रखें) के बीच के ट्रेड-ऑफ़ को समझना होगा।
पहले आपको क्या जानना चाहिए
पोस्ट-क्वांटम क्रिप्टोग्राफ़ी के बारे में क्या करना है यह तय करने से पहले, समझें कि इस संदर्भ में “हाइब्रिड” का क्या मतलब है। हाइब्रिड पोस्ट-क्वांटम TLS का मतलब है कि क्लाइंट और सर्वर एक ही हैंडशेक में एक साथ क्लासिकल एल्गोरिदम (RSA, ECDSA) और पोस्ट-क्वांटम एल्गोरिदम (जैसे ML-KEM, जो NIST के नए स्टैंडर्डाइज़्ड एल्गोरिदम में से एक है) पर बातचीत करते हैं। कनेक्शन उतना ही मज़बूत है जितना जोड़ी में सबसे कमज़ोर एल्गोरिदम। मक़सद ज़्यादा मज़बूत होना नहीं है — मक़सद है सुरक्षित रहना अगर क्लासिकल एल्गोरिदम अपेक्षा से कमज़ोर निकलें, साथ ही इंफ्रास्ट्रक्चर को उन सिस्टम के साथ कम्पैटिबल बनाए रखना जो अभी पोस्ट-क्वांटम एल्गोरिदम सपोर्ट नहीं करते।
यह “सभी RSA को पोस्ट-क्वांटम एल्गोरिदम से बदल दें” से अलग है, जो मौजूदा रास्ता नहीं है। यह “पोस्ट-क्वांटम क्रिप्टोग्राफ़ी परफ़ेक्ट है” से भी अलग है, जो सच नहीं है — नए एल्गोरिदम में हमेशा अनदेखी कमज़ोरियों का कुछ जोखिम रहता है।
यह भी समझें कि JDK 27 का डिफ़ॉल्ट-ऑन व्यवहार इसका मतलब नहीं है कि सभी Java एप्लिकेशन तुरंत टूट जाएँगे या काम करना बंद कर देंगे। जो सर्वर पोस्ट-क्वांटम एल्गोरिदम सपोर्ट नहीं करते वे JDK 27 पर चल रहे Java क्लाइंट के साथ भी काम करते रहेंगे। क्लासिकल एल्गोरिदम फ़ॉलबैक के रूप में बने रहते हैं। जो बदलता है वह यह है कि Java एप्लिकेशन पहले पोस्ट-क्वांटम आज़माएँगे, और इंफ्रास्ट्रक्चर टीमों को यह जानना होगा कि ये हैंडशेक आ रहे हैं।
अभी आप किसे नज़रअंदाज़ कर सकते हैं
जब तक आप क्रिप्टोग्राफ़ी विशेषज्ञ नहीं हैं या आपकी भूमिका नए एल्गोरिदम का मूल्यांकन करने से जुड़ी नहीं है, आपको ML-KEM, SLH-DSA, या अन्य NIST-स्टैंडर्डाइज़्ड पोस्ट-क्वांटम एल्गोरिदम के विशिष्ट गणित को समझने की ज़रूरत नहीं है। यह समझना काफ़ी है कि वे क्या करते हैं और यह कि वे स्टैंडर्डाइज़्ड हैं।
आपको अपना पूरा सर्टिफ़िकेट इंफ्रास्ट्रक्चर तुरंत बदलने की ज़रूरत नहीं है। अगर आपकी TLS लाइब्रेरी इसे सपोर्ट करती हैं, तो हाइब्रिड TLS आपके मौजूदा सर्टिफ़िकेट और इंफ्रास्ट्रक्चर के साथ काम करता है। यह एक क्रमिक परिवर्तन है, फ़ोर्कलिफ़्ट रिप्लेसमेंट नहीं।
आपको “पूरी तरह पोस्ट-क्वांटम अपनाएँ” या “इसे पूरी तरह नज़रअंदाज़ करें” के बीच चुनने की ज़रूरत नहीं है। अधिकांश संगठन बीच के रास्ते पर हैं: परिदृश्य को समझें, अपने इंफ्रास्ट्रक्चर में सपोर्ट सत्यापित करें, और अपनी अनुपालन आवश्यकताओं तथा अपने एप्लिकेशन रीफ़्रेश साइकल के साथ तालमेल बिठाता हुआ एक माइग्रेशन शेड्यूल बनाएँ।
आगे आपको क्या करना चाहिए
जाँचें कि क्या आपकी मौजूदा TLS लाइब्रेरी हाइब्रिड पोस्ट-क्वांटम TLS सपोर्ट करती हैं। यह एक व्यावहारिक आधे घंटे की जाँच है। OpenSSL, BoringSSL, Java JSSE, और AWS/Azure/Google Cloud TLS स्टैक के दस्तावेज़ आपको सीधे बता देंगे। अगर आप ऐसा इंफ्रास्ट्रक्चर बनाए रखते हैं जो TLS कनेक्शन की सेवा करता है, तो अपनी मौजूदा स्थिति सत्यापित करें।
अगर आप Java एप्लिकेशन चलाते हैं, तो अपनी JDK अपग्रेड समयसीमा समझें। JDK 27 अब GA है। अपग्रेड शेड्यूल अलग-अलग होते हैं — कुछ संगठन हर छह महीने में अपग्रेड करते हैं, कुछ को सालों लगते हैं। यह समझें कि आपके एप्लिकेशन कब डिफ़ॉल्ट रूप से JDK 27 से टकराएँगे, और इसे अपनी योजना के लिए एंकर बनाएँ।
अगर आपका संगठन FIPS अनुपालन के अधीन है, तो अपनी सुरक्षा या अनुपालन टीम से शुरुआत करें। ये समय-सीमाएँ असली सीमाएँ हैं, और इन्हें आपकी इंफ्रास्ट्रक्चर योजना को चलाना चाहिए, उल्टा नहीं। इंफ्रास्ट्रक्चर निर्णय लेने से पहले अपनी वास्तविक अनुपालन स्थिति और समयसीमा को समझें।
अगर आप तीसरे-पक्ष के एप्लिकेशनों के लिए इंफ्रास्ट्रक्चर के रूप में काम करते हैं, तो Java क्लाइंट्स से पोस्ट-क्वांटम TLS हैंडशेक की उम्मीद करना शुरू करें। सभी Java एप्लिकेशन तुरंत JDK 27 पर नहीं जाएँगे, लेकिन एक बार जब उनकी बड़ी संख्या चली जाती है, तो आपके इंफ्रास्ट्रक्चर को हैंडशेक को सुचारू रूप से संभालना होगा। अपने मौजूदा TLS सेटअप के ख़िलाफ़ एक आधुनिक JDK के साथ इसे टेस्ट करें।
पोस्ट-क्वांटम क्रिप्टोग्राफ़ी एक ही महीने में “रिसर्च” से “इंफ्रास्ट्रक्चर चिंता” बन गई है। आपके संगठन में होने वाली बातचीत को “क्या हमें इसके बारे में सोचना चाहिए?” से बदलकर “हमारी असल स्थिति और समयसीमा क्या है?” हो जाना चाहिए। जवाब आपकी अनुपालन आवश्यकताओं और आपके बनाए रखे जाने वाले प्लेटफ़ॉर्म के आधार पर अलग होगा, लेकिन जवाब अभी मायने रखता है।
आगे पढ़ें
- JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3 — OpenJDK. वह प्रस्ताव जिसने JDK 27 में हाइब्रिड पोस्ट-क्वांटम की-एक्सचेंज को डिफ़ॉल्ट बनाया, जिसमें यह भी शामिल है कि कौन-से नेम्ड ग्रुप किस क्रम में बातचीत किए जाते हैं। सितंबर 2026 में समीक्षा की गई।
- RFC 10024: Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3 — Internet Engineering Task Force. X25519MLKEM768, SecP256r1MLKEM768 और SecP384r1MLKEM1024 हाइब्रिड तंत्रों को परिभाषित करने वाला तकनीकी स्टैंडर्ड।
- NIST Post-Quantum Cryptography Standardization Project — NIST. स्टैंडर्डाइज़्ड एल्गोरिदम (जिनमें ML-KEM शामिल है, जो FIPS 203 में निर्दिष्ट है) और माइग्रेशन मार्गदर्शन। सितंबर 2026 में समीक्षा की गई।
- Executive Order 14412: Securing the Nation Against Advanced Cryptographic Attacks — The White House, 22 जून, 2026 को हस्ताक्षरित। 2030/2031 की संघीय परिवर्तन समय-सीमाएँ तय करता है और OMB/राष्ट्रीय साइबर निदेशक समन्वय को निर्देशित करता है।
- Cryptographic Module Validation Program — NIST CMVP. FIPS 140-2 Historical परिवर्तन और FIPS 140-3 वैलिडेशन पर आधिकारिक मार्गदर्शन। सितंबर 2026 में समीक्षा की गई।
स्रोत समीक्षा तिथि: 25 सितंबर 2026.