OpenSSH पोस्ट-क्वांटम एन्क्रिप्शन

(openssh.com)

4 पॉइंट द्वारा GN⁺ 2025-08-12 | 1 टिप्पणियां | WhatsApp पर शेयर करें

OpenSSH क्वांटम कंप्यूटर के हमलों का सामना करने के लिए पोस्ट-क्वांटम क्रिप्टोग्राफ़िक एल्गोरिदम का समर्थन करता है
9.0 संस्करण के बाद से डिफ़ॉल्ट रूप से sntrup761x25519-sha512 एल्गोरिदम उपलब्ध है, और 10.0 से mlkem768x25519-sha256 को डिफ़ॉल्ट कनेक्शन विधि के रूप में लागू किया गया
10.1 संस्करण के बाद यदि पोस्ट-क्वांटम नहीं होने वाला की-एक्सचेंज उपयोग हो तो चेतावनी संदेश दिखता है
अधिकांश मौजूदा सिग्नेचर एल्गोरिदम (RSA, ECDSA आदि) भी भविष्य में अतिरिक्त समर्थन के लिए जोड़े जाने हैं
मौजूदा ट्रैफिक को सुरक्षित रखने के लिए सर्वर और क्लाइंट दोनों में पोस्ट-क्वांटम एल्गोरिदम लागू होना ज़रूरी है

OpenSSH में पोस्ट-क्वांटम एन्क्रिप्शन का परिचय

OpenSSH कई ऐसे की-एक्सचेंज एल्गोरिदम का समर्थन करता है जो क्वांटम कंप्यूटर के हमलों के खिलाफ भी सुरक्षित हैं
सभी SSH कनेक्शनों में इन एल्गोरिदम के इस्तेमाल की सलाह देता है

OpenSSH 9.0 (2022) से sntrup761x25519-sha512 के जरिए डिफ़ॉल्ट रूप से पोस्ट-क्वांटम की-एक्सचेंज (KexAlgorithms) प्रदान करना शुरू किया गया, और 9.9 से mlkem768x25519-sha256 जोड़ा गया
mlkem768x25519-sha256 को OpenSSH 10.0 से डिफ़ॉल्ट एन्क्रिप्शन मेथड के रूप में सेट कर दिया गया

पोस्ट-क्वांटम एल्गोरिदम अपनाने को बढ़ावा देने के लिए OpenSSH 10.1 से, यदि क्वांटम-प्रतिरोधी की-एक्सचेंज का प्रयोग नहीं हो, तो नीचे जैसा चेतावनी संदेश दिखता है

** WARNING: connection is not using a post-quantum kex exchange algorithm. **
This session may be vulnerable to "store now, decrypt later" attacks.
The server may need to be upgraded. See https://openssh.com/pq.html

यह चेतावनी डिफ़ॉल्ट रूप से दिखाई देती है, लेकिन ssh_config(5) में WarnWeakCrypto विकल्प के साथ इसे अक्षम किया जा सकता है

पृष्ठभूमि

क्वांटम कंप्यूटर वो डिवाइस है जो जानकारी को क्वांटम स्थिति में encode करके गणना करता है
ये ऐसे गणितीय प्रश्न तेज़ी से हल कर सकता है जिन्हें सामान्य कंप्यूटर से हल करना कठिन होता है

कई क्रिप्टोग्राफिक एल्गोरिदम की गणितीय नींव ऐसे प्रश्नों पर आधारित है जो पर्याप्त रूप से सक्षम क्वांटम कंप्यूटर से आसानी से हल हो सकते हैं
यदि पर्याप्त शक्तिशाली क्वांटम कंप्यूटर (क्रिप्टोग्राफी के नज़रिए से व्यावहारिक स्तर पर) सामने आता है, तो इन एन्क्रिप्शन प्रणालियों के टूटने का जोखिम होता है
खास तौर पर की-एक्सचेंज और डिजिटल सिग्नेचर में उपयोग होने वाले एल्गोरिदम सबसे ज्यादा प्रभावित होते हैं

अब तक ऐसे क्वांटम कंप्यूटर उपलब्ध नहीं हुए हैं, लेकिन विशेषज्ञ 5 से 20 साल के भीतर या 2030 के मध्य दशक में इनकी संभावना मानते हैं

SSH कनेक्शन की गोपनीयता की गारंटी की-एक्सचेंज एन्क्रिप्शन पर टिकी है
यदि हमलावर की-एक्सचेंज एल्गोरिदम तोड़ दे तो कोई भी सेशन कंटेंट डिक्रिप्ट किया जा सकता है
इसके अलावा, चाहे हमला तुरंत न हो, अगर एन्क्रिप्टेड सत्र को सेव करके भविष्य में जब क्वांटम कंप्यूटर उपलब्ध हों तब डिक्रिप्ट किया जाए तो वह '** store now, decrypt later**' हमला कहलाता है

OpenSSH इस हमले का जवाब देने के लिए पोस्ट-क्वांटम एन्क्रिप्शन समर्थन को और मजबूत बना रहा है

FAQ

Q: SSH में चेतावनी दिख रही है, क्या करना चाहिए?

OpenSSH 10.1 या इससे ऊपर के संस्करण में गैर-क्वांटम-सुरक्षित एन्क्रिप्शन उपयोग होने पर उपयोगकर्ता को चेतावनी दिखती है
इसका अर्थ यह है कि जुड़ा हुआ सर्वर पोस्ट-क्वांटम की-एक्सचेंज एल्गोरिदम (mlkem768x25519-sha256, sntrup761x25519-sha512) उपलब्ध नहीं करा रहा
सबसे अच्छा तरीका यह है कि सर्वर को OpenSSH 9.0 या उससे ऊपर (इसके लिए 9.9 या ऊपर) पर अपडेट करें और KexAlgorithms में संबंधित एल्गोरिदम निष्क्रिय नहीं हैं यह सुनिश्चित करें
यदि सर्वर अपडेट संभव नहीं है या जोखिम लेने का निर्णय हो, तो ssh_config(5) में WarnWeakCrypto विकल्प से सिर्फ़ चेतावनी छिपाई जा सकती है
जरूरत हो तो नीचे की तरह किसी विशेष होस्ट पर ही सेटिंग लागू करने की सलाह दी जाती है
```
Match host unsafe.example.com
    WarnWeakCrypto no
```

Q: अभी क्वांटम कंप्यूटर नहीं हैं, फिर अभी से तैयारी क्यों?

ऊपर बताए गए "store now, decrypt later" हमले के कारण
आज भेजा गया ट्रैफिक भी भविष्य में डिक्रिप्ट होने के जोखिम में रहता है, इसलिए पहले से पोस्ट-क्वांटम सुरक्षित कनेक्शन की सलाह दी जाती है

Q: सिग्नेचर एल्गोरिदम भी जोखिम में हैं, फिर यह तत्काल मुद्दा क्यों नहीं?

अभी अधिकांश सिग्नेचर एल्गोरिदम (RSA, ECDSA आदि) भी क्वांटम कंप्यूटर से कमजोर हो सकते हैं
लेकिन इस स्थिति में वर्तमान ट्रैफिक के स्टोरेज होकर बाद में डिक्रिप्ट होने जैसा मामला नहीं बनता
सिग्नेचर एल्गोरिदम के संदर्भ में प्राथमिकता बस इतनी है कि जब क्वांटम कंप्यूटर के आने की संभावना करीब हो, तब पुराने सिग्नेचर कीज़ को हटाया जाए
OpenSSH भविष्य में पोस्ट-क्वांटम सिग्नेचर एल्गोरिदम भी सपोर्ट करेगा

Q: अगर कोई माने कि क्वांटम कंप्यूटर कभी संभव नहीं होंगे, तो यह इतना महत्वपूर्ण क्यों है?

कुछ लोगों का मानना है कि क्वांटम कंप्यूटर संभव नहीं होंगे, लेकिन आज की तकनीकी बाधा बुनियादी फिजिक्स नहीं, इंजीनियरिंग की है
यदि क्वांटम कंप्यूटर संभव हो जाते हैं तो आज के ये उपाय भारी मात्रा में उपयोगकर्ता डेटा की सुरक्षा में मदद करेंगे
अगर कभी यह तैयारी अनावश्यक लगे भी, तो भी यह सिर्फ गणितीय रूप से अधिक मजबूत एन्क्रिप्शन में बदलाव भर है

Q: क्या पोस्ट-क्वांटम एल्गोरिदम भी कमजोर हो सकते हैं?

OpenSSH भी बहुत सावधानी से आगे बढ़ रहा है
पिछले कुछ वर्षों में गहराई से समीक्षा किए गए एल्गोरिदम ही चुने गए हैं, लेकिन नए attack तरीके मिलने की संभावना बनी रहती है
इसी को ध्यान में रखकर केवल वही एल्गोरिदम चुने हैं जिनमें पर्याप्त सुरक्षा मार्जिन है, जिससे यदि वे अपेक्षा से कमजोर भी हों तो भी वास्तविक दुनिया के उपयोग में सुरक्षा मिलने की संभावना अधिक है
साथ ही, OpenSSH के सभी पोस्ट-क्वांटम एल्गोरिदम "हाइब्रिड" तरीके पर आधारित हैं
- उदाहरण: mlkem768x25519-sha256 में ML-KEM (पोस्ट-क्वांटम) और क्लासिकल ECDH/x25519 एल्गोरिदम का संयोजन है
- इससे यदि भविष्य में पोस्ट-क्वांटम एल्गोरिदम निष्क्रिय हो भी जाए तो कम से कम पारंपरिक स्तर की सुरक्षा तो बनी रहती है

1 टिप्पणियां

GN⁺ 2025-08-12

Hacker News टिप्पणियाँ

पेज के नीचे कुछ महत्वपूर्ण बातें छिपी हैं। OpenSSH में लागू सभी पोस्ट-क्वांटम एल्गोरिद्म "हाइब्रिड" तरीके से हैं, यानी पोस्ट-क्वांटम key exchange (जैसे ML-KEM) और परंपरागत तरीका (x25519) दोनों साथ में काम करते हैं। दोनों एल्गोरिद्म एक साथ होने का मतलब यह है कि अगर भविष्य में पोस्ट-क्वांटम एल्गोरिद्म पूरी तरह टूट भी जाए, तो भी कम से कम पहले जैसा security स्तर बना रहता है। हाइब्रिड होने की वजह से existing security से कोई नुकसान नहीं होता—यही मुख्य बिंदु है।
- हाइब्रिड तरीका इसीलिए मजबूत है कि अगर एक एल्गोरिद्म compromise हो जाए, तो दूसरा resilience देता है। लेकिन उल्टा, implementation bugs और side-channel vulnerabilities का खुलना भी लगभग दो गुना हो सकता है। वास्तविक दुनिया में अभी quantum computer threat पूरी तरह real नहीं है, लेकिन ऐसे bugs और weaknesses अभी के वास्तविक मुद्दे हैं। फिर भी, पिछले 10 सालों में भारी security शोध और verification होने के कारण ऐसा trade-off संभाला जा सकता है।
- पूरी industry लगभग PQC-क्लासिक हाइब्रिड आर्किटेक्चर की ओर जा रही है। जब तक सच में ऐसा quantum computer नहीं आता जो RSA, ECC, DH को वास्तविक स्तर पर तोड़ दे, दो locks को parallel में लगाना अभी सबसे safe conservative तरीका लगता है। दूसरी तरफ़, NSA की CNSA 2.0 एल्गोरिद्म सूची (लिंक) केवल पोस्ट-क्वांटम family लेती है और अपनी official FAQ में कहती है कि हाइब्रिड जरूरी नहीं है।
हाल ही में आया एक थोड़ा व्यंग्यात्मक और मज़ेदार पेपर (लिंक) देखकर लगता है कि अभी की speed से पोस्ट-क्वांटम crypto adoption वास्तव में ज़रूरी है या नहीं। मेरी समझ में पोस्ट-क्वांटम key material पहले की तुलना में बहुत बड़ा होता है, इसलिए network traffic और CPU खर्च दोनों बढ़ जाते हैं।
- यह पोस्ट सिर्फ SSH connection में key exchange पर PQC लागू करने की बात करती है, इसलिए ओवरहेड काफ़ी सीमित है। और FAQ में भी जैसा बताया है, "जब quantum computer अभी नहीं हैं तो पहले से तैयारी क्यों करें?" सवाल का जवाब यह है कि आज transmit किया गया traffic बाद में decrypt हो सकता है ("store now, decrypt later" attack)। कुछ लोग यह भी कहते हैं कि quantum computer संभव ही नहीं, लेकिन मुख्य बाधा physics नहीं बल्कि engineering है। अगर quantum सच में बन गया, तो बड़ी मात्रा में user data बचाया जा सकता है। पेपर को एक बार मज़े के लिए पढ़ना ठीक है, लेकिन उसे बहुत cynically नहीं लेना चाहिए।
- वह पेपर मज़ाक जैसा लगता है, पर केवल उसका मज़ाक उड़ाने लायक नहीं। वास्तव में meaningful progress भी हो रही है। PQCrypto 2025 में Sam Jacques की presentation (लिंक) recommend करता हूँ। पिछले 10 साल में quantum-computer आधारित factoring cost करीब 1000x कम हुआ और hardware side की error rate भी काफी घटी है (लिंक1, लिंक2, लिंक3, लिंक4)। यदि quantum progress देखना है, तो gradual resilience improvements ट्रैक करते रहिए। अभी noise बड़ा obstacle है, और जैसे ही दोनों तरफ़ quality issues सुलझते हैं, बड़ा jump आने की संभावना है।
- वह पेपर गंभीर आलोचना के बजाय मज़ाक जैसा लगता है। अगर इसे seriously लें तो 1951 में यह कहना कि transistor π नहीं निकाल सकता था, वैसा ही लगता है। PQC अपनाने की जरूरत दो सवालों पर तय होती है: 1) क्या आप मानते हैं कि अपने पूरे जीवन में quantum कंप्यूटर नहीं आएंगे? 2) आपने जो data trust किया है, उसकी sensitivity/value कितनी है। अगर इन दोनों में आपके लिए कोई मतलब नहीं, तो PQC शायद time-waste होगा। लेकिन अगर मैं crypto system maintain करने की स्थिति में हूँ, तो मुझे user data की value को ignore करने का हक नहीं लगता।
- आज की अधिकांश चर्चा key exchange के आसपास ही है। key exchange कम होता है, इसलिए ओवरहेड आमतौर पर बोझ नहीं बनता। मुख्य points: 1) PQ एल्गोरिद्म (signature, key exchange) की key size बड़ी होती है, लेकिन compute speed अक्सर बेहतर या समान होती है। 2) TLS, SSH जैसे ज़्यादातर protocols में key exchange सिर्फ initial connection पर होता है, इसलिए बड़ी key size बड़ी समस्या नहीं बनती। हाँ, TCP MTU exceed जैसे compatibility issues हो सकते हैं। Signal, MLS की तरह बहुत frequent key exchange करने वाले protocols में कभी-कभी सिर्फ PQ के साथ rekey करना बेहतर रहता है (संदर्भ). 3) TLS में वास्तविक मुद्दा signature message size का होता है क्योंकि certificate chain में signatures अधिक होती हैं। इसलिए PQ signatures के साथ TLS adopt करने की viability पर ज़्यादा चिंता करनी पड़ती है (संदर्भ)
- सार्वजनिक जानकारी के अलावा, हमारे intelligence agencies का 20 साल से अधिक confidentiality वाले systems के लिए PQ recommend करना भी भरोसे का कारण है। संदर्भ के लिए साझा कर रहा हूँ: 2014 में Dutch agency ने 2030-2040 का अनुमान दिया, 2021 में 2030 तक संभावना कम होने के बावजूद उसे ignore नहीं किया जा सकता। 2025 में 18 देशों ने joint statement में 2030 तक 'store now, decrypt later' attack के लिए preparedness पर बयान दिया (दस्तावेज़ 1, दस्तावेज़ 2, संयुक्त वक्तव्य)
macOS ऐप Secretive में SSH key Secure Enclave में store होता है। supported algorithms की वजह से यह अभी ecdsa-sha2-nistp256 यूज़ कर रहा है, और शायद Secure Enclave में PQ algorithms support नहीं हैं। क्या mlkem768×ecdsa-sha2-nistp256 की तरह हाइब्रिड बनाकर सिर्फ ECDSA हिस्सा SE पर process करना संभव होगा? (Secretive GitHub)
- यहाँ की चर्चा key exchange (aka KEX यानी Key Exchange) के बारे में है, SSH के खुद के key की नहीं। SSH options में ecdsa-sha2-nistp256, KexAlgorithms में allowed नहीं होता, ecdh-sha2-nistp256 उसका विकल्प है। संदर्भ 1, संदर्भ 2
मैं सोचता हूँ कि ssh-audit (लिंक) को theoretical (PQC हाइब्रिड) algorithms को verify करने वाली entry जोड़नी चाहिए। ऐसा लगता है कि कुछ algorithms fixed करके भी शायद