08 अग॰ 2025·8 मिनट
लियोनार्ड ऐडलमैन और RSA — कैसे इंटरनेट ने भरोसा सीखा
लियोनार्ड ऐडलमैन ने RSA बनाने में मदद की — एक पब्लिक‑की प्रणाली जिसने HTTPS, ऑनलाइन बैंकिंग और साइन किए गए अपडेट संभव किए। जानें यह कैसे काम करता है और क्यों महत्वपूर्ण है।
लियोनार्ड ऐडलमैन ने RSA बनाने में मदद की — एक पब्लिक‑की प्रणाली जिसने HTTPS, ऑनलाइन बैंकिंग और साइन किए गए अपडेट संभव किए। जानें यह कैसे काम करता है और क्यों महत्वपूर्ण है।
जब लोग कहते हैं कि वे किसी वेबसाइट या ऑनलाइन सेवा पर “भरोसा” करते हैं, तो आम तौर पर वे तीन व्यावहारिक बातों का मतलब लेते हैं:
RSA प्रसिद्ध हुआ क्योंकि उसने उन वादों को इंटरनेट‑स्तर पर संभव बनाया।
यदि आपने नाम कभी नहीं सुना, तब भी आप RSA का प्रभाव महसूस कर चुके हैं। यह निम्न तरीकों से जुड़ा है:
साझा धागा यह है कि बिना व्यक्तिगत रूप से हर सर्वर और सॉफ़्टवेयर विक्रेता को जानें—विश्वास संभव हुआ।
यह लेख सरल समझावों पर ध्यान रखता है: भारी गणित नहीं, और कंप्यूटर‑विज्ञान पृष्ठभूमि की ज़रूरत नहीं। हम रोज़मर्रा के "यह क्यों काम करता है" दृश्य पर फोकस करेंगे।
RSA ने एक शक्तिशाली तरीका लोकप्रिय किया: एक पब्लिक की जिसे आप खुलेआम साझा कर सकते हैं और एक प्राइवेट की जिसे आप गुप्त रखते हैं। यह विभाजन उन परिस्थितियों में गोपनीयता और पहचान दोनों संभव बनाता है जहाँ लोग या सिस्टम पहले कभी नहीं मिले।
लियोनार्ड ऐडलमैन RSA में "A" हैं, साथ में Ron Rivest और Adi Shamir। जबकि Rivest और Shamir को अक्सर मूल निर्माण के लिए श्रेय जाता है, ऐडलमैन का योगदान अनिवार्य था: उन्होंने सिस्टम को केवल चतुर नहीं, बल्कि विश्वास करने योग्य—ऐसा कुछ बनाने में मदद की जिसे लोग विश्लेषित, परीक्षण और भरोसा कर सकें।
ऐडलमैन की भूमिका का बड़ा हिस्सा विचार पर दबाव डालना था। क्रिप्टोग्राफी में किसी योजना का मूल्य यह नहीं है कि वह संभावना के रूप में कैसी लगती है; मूल्य यह है कि वह सावधानीपूर्वक हमलों और परीक्षणों से बचकर निकले। ऐडलमैन ने मान्यकरण पर काम किया, धारणाओं को परिष्कृत किया, और प्रारंभिक रूपरेखा में योगदान दिया कि RSA को तोड़ना क्यों कठिन होना चाहिए।
उतना ही महत्वपूर्ण, उन्होंने "यह काम कर सकता है" से "यह एक ऐसा क्रिप्टोसिस्टम है जिसे अन्य लोग मूल्यांकन कर सकें" में अनुवाद करने में मदद की। उस स्पष्टता—डिज़ाइन को व्यापक शोध समुदाय के लिए समझने‑योग्य बनाना—अपनाने के लिए निर्णायक थी।
RSA से पहले, सुरक्षित बातचीत आमतौर पर इस पर निर्भर करती थी कि दोनों पक्ष पहले से एक ही गुप्त कुंजी साझा कर चुके हों। वह तरीका बंद समूहों में काम करता है, परंतु जब अजनबी सुरक्षित रूप से संवाद करना चाहते हैं (जैसे एक खरीदार और वेबसाइट पहली बार मिलते हैं), तो यह स्केल नहीं करता।
RSA ने उस कहानी को बदल दिया, एक व्यावहारिक पब्लिक‑की क्रिप्टोसिस्टम को लोकप्रिय बनाकर: आप दूसरों को उपयोग करने के लिए एक की प्रकाशित कर सकते हैं, जबकि अलग‑थलग प्राइवेट की गुप्त रखी जाती है।
RSA का प्रभाव एक एल्गोरिद्म से बड़ा है। इसने दो इंटरनेट की अनिवार्य चीजों को बड़े पैमाने पर व्यवहार्य महसूस करवा दिया:
ये विचार HTTPS, ऑनलाइन बैंकिंग और साइन किए गए सॉफ़्टवेयर अपडेट के सामान्य अपेक्षाओं के रूप में उभरने के आधार रहे।
RSA से पहले, सुरक्षित संचार ज्यादातर साझा‑रहस्य एन्क्रिप्शन पर निर्भर था: दोनों पक्षों के पास पहले से वही गुप्त कुंजी होनी चाहिए। यह छोटे समूहों के लिए काम करता है, पर सार्वजनिक सेवा जिसे लाखों लोग उपयोग करते हैं उसके लिए यह जल्दी टूट जाता है।
यदि हर ग्राहक को बैंक से बात करने के लिए एक अनूठी गुप्त कुंजी चाहिए, तो बैंक को विशाल संख्या में रहस्यों का निर्माण, वितरण, भंडारण, रोटेशन और सुरक्षा करनी होगी। सबसे कठिन हिस्सा गणित नहीं—समन्वय है।
पहले व्यक्ति तक सुरक्षित रूप से रहस्य कैसे पहुँचाएँ? मेलिंग धीमा और जोखिमभरा है। फोन पर बताना इंटरसेप्ट या सोशल इंजीनियरिंग का शिकार हो सकता है। इंटरनेट पर भेजना तो उद्देश्य ही विफल कर देता है, क्योंकि चैनल वही है जिसे आप सुरक्षित करना चाहते हैं।
कल्पना कीजिए दो अजनबियों की—आप और एक ऑनलाइन स्टोर—जो कभी नहीं मिले। आप सुरक्षित भुगतान भेजना चाहते हैं। साझा‑रहस्य एन्क्रिप्शन के साथ, आपको एक निजी कुंजी चाहिए जो दोनों पहले से जानते हों। पर आप नहीं जानते।
RSA का ब्रेकथ्रू यह था कि यह पहले से कोई रहस्य साझा किए बिना सुरक्षित संवाद सक्षम करता है। इसके बजाय, आप एक कुंजी (पब्लिक की) प्रकाशित कर सकते हैं जिसे कोई भी आपके लिए संदेश सुरक्षित करने के लिए उपयोग कर सकता है, जबकि दूसरी कुंजी (प्राइवेट की) केवल आप ही रखते हैं।
भले ही आप संदेश एन्क्रिप्ट कर सकें, आपको फिर भी पता होना चाहिए कि आप किसे एन्क्रिप्ट कर रहे हैं। अन्यथा, हमलावर बैंक या स्टोर की नकल कर सकता है, आपको उनकी कुंजी इस्तेमाल करने पर मजबूर कर सकता है, और चुपके से सब कुछ पढ़ या बदल सकता है।
इसलिए सुरक्षित इंटरनेट‑संचार को दो गुणों की ज़रूरत है:
RSA ने दोनों को संभव बनाया, और बड़े पैमाने पर ऑनलाइन भरोसे का आधार तैयार किया।
पब्लिक‑की क्रिप्टोग्राफी एक सरल विचार है जिसके बड़े परिणाम हैं: आप किसी के लिए किसी चीज़ को लॉक कर सकते हैं बिना पहले कोई साझा रहस्य तय किए। यही मूल बदलाव है जिसे RSA ने व्यवहारिक बनाया।
पब्लिक की को एक ऐसी लॉक समझें जिसे आप किसी के भी हाथ में देने के लिए तैयार हों। लोग इसका उपयोग आपके लिए संदेश सुरक्षित करने के लिए कर सकते हैं—या (सिग्नेचर सिस्टम में) यह जाँच कर सकते हैं कि कुछ वाकई आपसे आया है।
प्राइवेट की वह चाबी है जिसे आपको खुद ही रखना है। यही वह चाबी है जो आपके पब्लिक की से लॉक की गई चीज़ को खोलती है, और यही वह चीज़ है जो सिग्नेचर बनाते समय प्रयोग होती है।
साथ में, पब्लिक और प्राइवेट की एक की पेयर बनाते हैं। वे गणितीय रूप से जुड़े हैं, पर विनिमेय नहीं। सार्वजनिक की साझा करना सुरक्षित माना जाता है क्योंकि इसे देखकर प्राइवेट की व्यावहारिक रूप से निकालना संभव नहीं होता।
एन्क्रिप्शन गोपनीयता के बारे में है। अगर कोई आपके पब्लिक की से संदेश एन्क्रिप्ट करता है, तो केवल आपकी प्राइवेट की ही उसे डिक्रिप्ट कर सकती है।
डिजिटल सिग्नेचर विश्वास और अखंडता के बारे में हैं। यदि आप किसी चीज़ पर अपनी प्राइवेट की से सिग्नेचर करते हैं, तो आपकी पब्लिक की रखने वाला कोई भी यह जाँच सकता है कि:\n\n- यह सिग्नेचर प्राइवेट की के धारक ने बनाया है\n- साइन करने के बाद फ़ाइल या संदेश में कोई बदलाव नहीं हुआ
सुरक्षा जादू नहीं है—यह उन कठिन गणितीय समस्याओं पर निर्भर है जो एक दिशा में आसानी से की जा सकती हैं और दूसरी दिशा में वर्तमान कंप्यूटर्स के लिए बेहद कठिन। वही "एक‑तरफा" गुण सार्वजनिक की साझा करना सुरक्षित बनाता है जबकि प्राइवेट की शक्तिशाली रहती है।
RSA एक सरल विषमता पर बनाया गया है: "अग्रिम" गणित करना आसान है, पर उसी गणित को पीछे की ओर करना (बशर्ते आपके पास गुप्त न हो) बेहद कठिन है—जब तक आपके पास एक विशेष रहस्य (ट्रैपडोर) न हो।
RSA को एक प्रकार के गणितीय ताला के रूप में सोचें। कोई भी पब्लिक की का उपयोग करके संदेश लॉक कर सकता है। पर केवल वही व्यक्ति जिसके पास प्राइवेट की है, उसे खोल सकता है।
इसकी संभाव्यता उस सावधानीपूर्वक चयनित संबंध में है जो दोनों कुंजियों के बीच मौजूद होता है। उन्हें साथ में जनरेट किया जाता है, और यद्यपि वे संबंधित हैं, सार्वजनिक की देखकर व्यावहारिक रूप से प्राइवेट की निकालना संभव नहीं होता।
ऊपर‑नीचे स्तर पर, RSA इस बात पर निर्भर करता है कि बड़े अभाज्य संख्याओं को गुणा करना आसान है, पर वापस यह पता करना—किसने गुणा किया—बहुत कठिन है जब संख्याएँ विशाल हों।
छोटी संख्याओं के लिए फैक्टरिंग त्वरित है। पर वास्तविक RSA कुंजियों के आकार (हज़ारों बिट्स) पर सर्वोत्तम ज्ञात तरीके भी व्यवहार में अव्यावहारिक समय और कम्प्यूटिंग शक्ति की माँग करते हैं। यही "पीछे की ओर मुश्किल" गुण हमलावरों को प्राइवेट की पुनर्निर्मित करने से रोकता है।
RSA आमतौर पर बड़े फ़ाइलों या लंबे संदेशों को सीधे एन्क्रिप्ट करने के लिए उपयोग नहीं किया जाता। इसके बजाय, यह अक्सर छोटी रहस्यों—खासकर एक यादृच्छिक रूप से जनरेट किया गया सेशन की—को सुरक्षा देने के लिए इस्तेमाल होता है। वही सेशन की फिर तेज़ सममित एन्क्रिप्शन के साथ असली डेटा को सुरक्षित करती है, जो बड़े‑ट्रैफ़िक के लिए बेहतर अनुकूल है।
RSA प्रसिद्ध है क्योंकि यह दो संबंधित परन्तु अलग काम कर सकता है: एन्क्रिप्शन और डिजिटल सिग्नेचर। इन्हें मिलाना अक्सर भ्रम का कारण बनता है।
एन्क्रिप्शन मुख्यतः गोपनीयता का लक्ष्य रखता है। डिजिटल सिग्नेचर मुख्यतः अखंडता + प्रामाणिकता का।
RSA एन्क्रिप्शन में, कोई व्यक्ति आपकी पब्लिक की का उपयोग करके कुछ लॉक करता है ताकि केवल आपकी प्राइवेट की ही उसे खोल सके।
व्यवहार में, RSA अक्सर एक छोटे रहस्य—जैसे सेशन की—को सुरक्षित करने के लिए उपयोग होती है। वही सेशन की तब असली डेटा को कुशलता से एन्क्रिप्ट करती है।
RSA सिग्नेचरों में, दिशा उलट जाती है: भेजने वाला अपनी प्राइवेट की का उपयोग करके सिग्नेचर बनाता है, और कोई भी जिसकी पहुँच पब्लिक की है, वह जाँच कर सकता है:\n\n- क्या यह वाकई प्राइवेट की के धारक ने बनाया? (प्रामाणिकता)\n- क्या साइन करने के बाद कुछ बदला गया है? (अखंडता)
डिजिटल सिग्नेचर रोज़मर्रा के "अनुमोदन" क्षणों में दिखते हैं:\n\n- लेनदेन की मंजूरी: बैंक संदेशों पर साइन कर सकता है ताकि आपका ऐप मिले हुए निर्देशों पर भरोसा करे।\n- डाउनलोड: साइन किया गया इंस्टॉलर आपके कंप्यूटर को यह सत्यापित करने में मदद करता है कि यह असली प्रकाशक का है।\n- अपडेट: साइन किए गए अपडेट हमलावरों को वितरण चैनल में छेड़छाड़ करके दूषित संस्करण डालने से रोकते हैं।
एन्क्रिप्शन रहस्य बचाए रखता है; सिग्नेचर भरोसा बनाए रखता है।
आपके ब्राउज़र का पैडलॉक एक विचार का शॉर्टकट है: आपकी उस वेबसाइट के साथ कनेक्शन एन्क्रिप्टेड और (अक्सर) प्रमाणीकरण‑युक्त है। इसका मतलब है कि नेटवर्क पर अन्य लोग—जैसे सार्वजनिक Wi‑Fi पर कोई—आपके ब्राउज़र और साइट के बीच भेजे‑पहुंचे संदेश पढ़ या चुपके से बदल नहीं सकते।
यह नहीं बताता कि वेबसाइट हर मायने में "सुरक्षित" है। पैडलॉक यह नहीं बता सकता कि कोई दुकान ईमानदार है, डाउनलोड मालवेयर है या नहीं, या आपने सही डोमेन टाइप किया है। यह यह भी गारंटी नहीं देता कि साइट आपके डेटा को उनके सर्वरों पर पहुँचने के बाद सुरक्षित रखेगी।
जब आप HTTPS साइट पर जाते हैं, आपका ब्राउज़र और सर्वर एक सेटअप बातचीत करते हैं जिसे TLS हैंडशेक कहा जाता है:
ऐतिहासिक रूप से, RSA अक्सर सेशन की का आदान‑प्रदान करने के लिए प्रयोग किया गया था (ब्राउज़र सर्वर की RSA पब्लिक की से एक रहस्य एन्क्रिप्ट कर देता)। आधुनिक TLS कॉन्फ़िग्रेशनों में, RSA मुख्यतः प्रमाणीकरण via सिग्नेचर के लिए प्रयुक्त होता है, जबकि की समझौता अन्य तरीकों से होता है।
RSA छोटे टुकड़ों की सुरक्षा के लिए अच्छा है पर धीमा है—इसीलिए HTTPS हैंडशेक के बाद असली पृष्ठ लोड्स, लॉगिन और बैंकिंग ट्रांज़ैक्शन तेज़ सममित एल्गोरिद्म पर स्विच कर लेते हैं।
ऑनलाइन बैंकिंग का सरल वादा यह है: आपको लॉग इन, बैलेंस देखना और पैसे भेजना इस तरह होना चाहिए कि कोई और आपके क्रेडेंशियल्स को न पढ़ सके—या चुपके से जो आप भेजते हैं उसे बदल न सके।
एक बैंकिंग सेशन को एक साथ तीन चीज़ें सुरक्षित रखनी होती हैं:
बिना HTTPS के, उसी Wi‑Fi पर कोई, समझौता राउटर, या दुष्ट नेटवर्क ऑपरेटर यातायात को इव्सड्रॉप या टैम्पर कर सकता था।
HTTPS (TLS के माध्यम से) कनेक्शन को यह सुनिश्चित करके सुरक्षित करता है कि ब्राउज़र और बैंक के बीच जा रहा डेटा एन्क्रिप्टेड और अखंडता‑जाँचित है। व्यवहारिक रूप से इसका मतलब:
RSA की ऐतिहासिक भूमिका यहाँ महत्वपूर्ण थी क्योंकि उसने "पहली मुलाकात" की समस्या का समाधान किया: असुरक्षित नेटवर्क पर एक सुरक्षित सेशन कैसे स्थापित करें।
यदि आप गलत पक्ष को एन्क्रिप्ट कर रहे हैं तो सिर्फ एन्क्रिप्शन पर्याप्त नहीं है। ऑनलाइन बैंकिंग तभी काम करती है जब ब्राउज़र बता सके कि वह वाकई वास्तविक बैंक से जुड़ रहा है, न कि किसी नकली साइट या मैन‑इन‑द‑मिडल से।
बैंक अब भी MFA, डिवाइस चेक, और फ्रॉड मॉनिटरिंग जोड़ते हैं। ये तब हुए नुकसान को कम करते हैं जब क्रेडेंशियल्स चोरी हो जाएँ—पर वे HTTPS की जगह नहीं लेते। वे पहले से मौजूद निजी और टैम्पर‑रहित कनेक्शन के ऊपर सबसे अच्छे रूप में काम करते हैं।
सॉफ़्टवेयर अपडेट एक भरोसे का मुद्दा जितना तकनीकी है। भले ही कोई ऐप सावधानीपूर्वक लिखा गया हो, हमलावर डिलिवरी चरण को निशाना बना सकता है—वास्तविक इंस्टॉलर को बदल कर एक संशोधित वर्ज़न परोस सकता है, या प्रकाशक और उपयोगकर्ता के बीच के पथ में छेड़छाड़ कर सकता है। बिना विश्वसनीय तरीके के प्रमाणित किए कि आपने जो डाउनलोड किया वह असली है, "अपडेट उपलब्ध" एक आसान प्रवेश‑बिंदु बन सकता है।
यदि अपडेट केवल एक डाउनलोड लिंक से सुरक्षित हैं, तो कोई हमलावर जोmirror को समझौता कर सके, नेटवर्क को हाईजैक कर सके, या उपयोगकर्ता को दिखावटी पेज पर ले जा सके, तो वैसा ही नाम रखकर अलग फ़ाइल परोस सकता है। उपयोगकर्ता सामान्य रूप से उसे इंस्टॉल कर लेगा, और नुकसान "चुपचाप" हो सकता है: अपडेट में मैलवेयर, प्रोग्राम में बैकडोर, या सुरक्षा सेटिंग्स में ढील।
कोड साइनिंग पब्लिक‑की क्रिप्टोग्राफी (कई सिस्टम में RSA सहित) का उपयोग करके एक इंस्टॉलर या अपडेट पैकेज पर डिजिटल सिग्नेचर लगाती है।
प्रकाशक अपनी प्राइवेट की से सॉफ़्टवेयर को साइन करता है। आपका डिवाइस (या ऑपरेटिंग सिस्टम) उस सिग्नेचर को प्रकाशक की पब्लिक की से सत्यापित करता है—अक्सर एक प्रमाणपत्र चेन के ज़रिए। यदि एक बाइट भी बदली हो, तो सत्यापन फेल हो जाता है। यह भरोसा इस बात को स्थानांतरित कर देता है कि "मैंने कहाँ से डाउनलोड किया" से "क्या मैं सत्यापित कर सकता हूँ कि किसने बनाया और क्या यह अखंड है"।
आधुनिक ऐप डिलीवरी पाइपलाइनों में ये विचार इंस्टॉलर से परे फैलते हैं—API कॉल, बिल्ड आर्टिफैक्ट्स, और डिप्लॉयमेंट रोलआउट्स तक। उदाहरण के लिए, प्लेटफ़ॉर्म जैसे Koder.ai (एक चैट इंटरफ़ेस से वेब, बैकएंड और मोबाइल ऐप भेजने के लिए vibe‑coding प्लेटफ़ॉर्म) अभी भी उन्हीं नींवों पर निर्भर करते हैं: ट्रांज़िट में डेटा के लिए HTTPS/TLS, कस्टम डोमेनों के लिए सावधान प्रमाणपत्र हैंडलिंग, और परिवर्तनों को पुश करने पर जोखिम घटाने के लिए प्रैक्टिकल रोलबैक‑शैली वर्कफ़्लो (स्नैपशॉट और रिस्टोर पॉइंट)।
साइन किए गए अपडेट अनदेखी छेड़छाड़ के मौके घटाते हैं। उपयोगकर्ताओं को असामान्य स्थिति पर स्पष्ट चेतावनियाँ मिलती हैं, और स्वचालित अपडेट सिस्टम बदली हुई फ़ाइलों को चलने से पहले अस्वीकार कर सकते हैं। यह सॉफ़्टवेयर के बग‑फ्री होने की गारंटी नहीं है, पर यह नकल और सप्लाई‑चेन छेड़छाड़ के खिलाफ एक शक्तिशाली रक्षा है।
गहराई से देखने के लिए कि सिग्नेचर, प्रमाणपत्र और सत्यापन कैसे जुड़ते हैं, देखें /blog/code-signing-basics।
यदि RSA आपको एक पब्लिक की देता है, तो स्वाभाविक प्रश्न उठता है: यह किसकी पब्लिक की है?
एक प्रमाणपत्र इंटरनेट का उत्तर है। यह एक छोटा, साइन किया गया डेटा फ़ाइल होती है जो एक पब्लिक की को एक पहचान—जैसे वेबसाइट नाम (example.com), एक संगठन, या सॉफ़्टवेयर प्रकाशक—से जोड़ती है। इसे की के लिए एक आई‑कार्ड समझें: यह कहता है “यह कुंजी इस नाम की है,” और इसमें प्रमाणपत्र के मालिक, स्वयं पब्लिक की, और वैधता तिथियाँ जैसी जानकारी होती हैं।
प्रमाणपत्र महत्वपूर्ण इसलिए हैं क्योंकि वे किसी और द्वारा साइन किए जाते हैं। वह "कोई और" आमतौर पर एक Certificate Authority (CA) होता है।
CA एक तीसरी पार्टी है जो कुछ सबूतों की जाँच करती है (जो बुनियादी डोमेन नियंत्रित करने से लेकर गहराई में व्यापारिक सत्यापन तक हो सकते हैं) और फिर प्रमाणपत्र पर साइन करती है। आपका ब्राउज़र या ऑपरेटिंग सिस्टम एक बिल्ट‑इन भरोसेमंद CA सूची के साथ आता है। जब आप HTTPS पर साइट पर जाते हैं, तो आपका डिवाइस उस सूची का उपयोग यह निर्णय लेने के लिए करता है कि प्रमाणपत्र के दावे को स्वीकार करना है या नहीं।
यह प्रणाली परिपूर्ण नहीं है: CAs गलतियाँ कर सकते हैं, और हमलावर उन्हें चकमा देने या समझौता करने की कोशिश कर सकते हैं। पर यह वैश्विक पैमाने पर कार्य करने वाला एक व्यावहारिक ट्रस्ट चेन बनाती है।
प्रमाणपत्र जानबूझकर समाप्त हो जाते हैं। छोटी अवधि यह सीमित करती है कि यदि कोई कुंजी चोरी हो जाए तो नुकसान कितना बड़ा होगा, और नियमित रखरखाव को प्रोत्साहित करती है।
प्रमाणपत्र को उसकी समाप्ति से पहले भी रद्द किया जा सकता है। रद्दीकरण यह कहने का तरीका है: "इस प्रमाणपत्र पर भरोसा करना बंद करो," उदाहरण के लिए यदि प्राइवेट की लीक हुई हो या प्रमाणपत्र गलत तरीके से जारी किया गया हो। उपकरण रद्दीकरण स्थिति की जांच कर सकते हैं (जिसकी विश्वसनीयता अलग‑अलग हो सकती है), इसलिए की‑हाइजीन अभी भी मायने रखती है।
अपनी प्राइवेट की को निजी रखें: इसे सुरक्षित कीस्टोरेज में रखें, पहुँच सीमित करें, और जब तक जरूरी न हो इसे सिस्टमों के बीच कॉपी करने से बचें।
घटनाओं के बाद, नियोजित उन्नयन के दौरान, या नीति आवश्यकताओं पर कुंजियाँ रोटेट करें। और नवीनीकरणों को अंतिम‑क्षण की आपात स्थिति न बनने दें—समाप्ति तिथियों को ट्रैक रखें।
RSA एक बुनियादी विचार है, पर यह जादुई सुरक्षा कवच नहीं है। ज्यादातर वास्तविक दुनिया में होने वाले ब्रेक इसलिए होते हैं क्योंकि RSA के आस‑पास के सिस्टम फेल हो जाते हैं।
कुछ पैटर्न बार‑बार दिखते हैं:
RSA की सुरक्षा इस बात पर निर्भर करती है कि कुंजियाँ पर्याप्त बड़ी और वास्तव में अनियमित हों। अच्छी यादृच्छिकता अनिवार्य है: यदि कुंजी जनरेशन में दुर्बल रैंडम स्रोत उपयोग हुआ है, तो हमलावर कभी‑कभार संभव कुंजियों को पुनरुत्पादित या सीमित कर सकते हैं। इसी तरह, की‑लंबाई मायने रखती है क्योंकि कम्प्यूटिंग शक्ति और गणितीय तकनीकों में सुधार छोटे कीज़ के लिए सुरक्षा मार्जिन घटाता है।
RSA ऑपरेशन आधुनिक विकल्पों की तुलना में भारी होते हैं, इसलिए कई प्रोटोकॉल RSA को संयम से इस्तेमाल करते हैं—अकसर प्रमाणीकरण या अस्थायी रहस्य के आदान‑प्रदान के लिए, फिर बड़े डेटा के लिए तेज सममित एन्क्रिप्शन पर स्विच करते हैं।
सुरक्षा सबसे अच्छी तरह से डिफेंस‑इन‑डेप्थ के रूप में काम करती है: प्राइवेट‑कियों की रक्षा (आदतन हार्डवेयर में), प्रमाणपत्र जारी होने की निगरानी, सिस्टम पैचिंग, फिशिंग‑प्रतिरोधी प्रमाणीकरण का उपयोग, और सुरक्षित की रोटेशन डिज़ाइन। RSA एक उपकरण है—पूरा चेन नहीं।
RSA इंटरनेट पर सबसे व्यापक रूप से समर्थित क्रिप्टोग्राफिक टूल में से है। भले ही कोई सेवा अब "RSA पसंद न करे" तब भी यह अक्सर संगतता के कारण रखा जाता है—पुराने डिवाइस, लंबे समय से चल रहे एंटरप्राइज़ सिस्टम, और वर्षों में बनाए गए प्रमाणपत्र‑बुनियादी ढांचे।
क्रिप्टोग्राफी उसी कारण से विकसित होती है जैसे अन्य सुरक्षा‑प्रौद्योगिकियाँ:
TLS और आधुनिक अनुप्रयोगों में आप आमतौर पर विकल्प देखेंगे:\n\n- ECDSA और Ed25519 डिजिटल सिग्नेचर के लिए (सर्वर/ऐप की प्रामाणिकता साबित करने के लिए)। ये सामान्यतः तेज़ हैं और छोटी कुंजी उपयोग करते हैं।\n- ECDH की समझौते के लिए (एक साझा रहस्य पर सहमति करने के लिए)। यही एक बड़ा कारण है कि कई HTTPS कनेक्शन अब मुख्य "रहस्य लॉक करने" चरण के लिए RSA पर निर्भर नहीं करते।
साफ़‑साफ़: RSA दोनों—एन्क्रिप्शन और सिग्नेचर—कर सकता है, पर नए सिस्टम अक्सर काम को विभाजित करते हैं—सिग्नेचर के लिए एक अनुकूलित तरीका और सेशन कीज़ स्थापित करने के लिए दूसरे तरीके का उपयोग।
कहीं नहीं। RSA अभी भी व्यापक रूप से समर्थित है और कई संदर्भों में मान्य विकल्प बना हुआ है, विशेषकर जहाँ संगतता महत्वपूर्ण है या अस्तित्व में रहे प्रमाणपत्र और की‑प्रबंधन अभ्यास RSA के इर्द‑गिर्द बने हुए हैं। "सबसे अच्छा" विकल्प डिवाइस समर्थन, प्रदर्शन आवश्यकताएँ, अनुपालन आवश्यकताएँ, और कुंजियाँ कैसे स्टोर/रोटेट की जा रही हैं जैसे कारकों पर निर्भर करता है।
यदि आप देखना चाहते हैं कि ये विकल्प असली HTTPS कनेक्शनों में कैसे दिखाई देते हैं, अगला कदम है: /blog/ssl-tls-explained.
RSA ने पब्लिक‑की क्रिप्टोग्राफी को व्यवहारिक बनाकर इंटरनेट‑स्तर का भरोसा संभव किया, जिससे:
ये बिल्डिंग‑ब्लॉक्स HTTPS, ऑनलाइन बैंकिंग और साइन किए गए सॉफ़्टवेयर अपडेट के लिए केंद्रीय हैं।
लियोनार्ड ऐडलमैन ने RSA को एक केवल 'कमाल का विचार' से उस क्रिप्टोसिस्टम में बदलने में मदद की जिसे दूसरे विश्लेषित कर सकें और जिस पर भरोसा किया जा सके। व्यावहारिक रूप से इसका मतलब था—अनुमानों को कसना, प्रस्तुति सुधारना, और यह स्पष्ट करना कि क्यों वास्तविक हमलों के मॉडल में RSA तोड़ा जाना कठिन होना चाहिए।
एक पब्लिक की साझा करने के लिए होती है; लोग इसका उपयोग आप तक संदेश एन्क्रिप्ट करने या आपके द्वारा किए गए सिग्नेचर की जांच करने के लिए कर सकते हैं.
एक प्राइवेट की गुप्त रखनी चाहिए; यह वही है जो पब्लिक‑की से एन्क्रिप्ट की गई चीज़ों को डिक्रिप्ट करती है और वही निजी हस्ताक्षर बनाने के लिए उपयोग होती है।
यदि प्राइवेट की लीक हो जाती है, तो हमलावर आपकी नकल कर सकते हैं और/या सुरक्षित रहस्यों को डिक्रिप्ट कर सकते हैं—यह निर्भर करता है कि कुंजी कैसे उपयोग की जा रही थी।
RSA की सुरक्षा एक उच्च‑स्तर के एक‑तरफा गणितीय समस्या पर निर्भर करती है: बड़े अभाज्य संख्याओं का गुणा करना आसान है, पर उस बड़े नंबर को वापस उससके अभाज्य गुणकों में तोड़ना (factoring) वास्तविक RSA कुंजी‑आकारों पर बहुत कठिन है।
पब्लिक और प्राइवेट की आपस में गणितीय रूप से जुड़ी होती हैं, पर सार्वजनिक की देखकर व्यावहारिक रूप से प्राइवेट की निकालना सम्भव नहीं होना चाहिए।
वे अलग‑अलग भरोसे के लक्ष्य हल करते हैं:
सरल नियम: एन्क्रिप्शन रहस्य सुरक्षित रखता है; सिग्नेचर बताता है किसने भेजा और क्या वह बदला गया है।
सरल TLS प्रवाह में:
RSA का उपयोग अक्सर प्रमाणीकरण (सिग्नेचर) के लिए होता है, और ऐतिहासिक रूप से कुछ कॉन्फ़िगरेशन में सेशन सीक्रेट की रक्षा के लिए भी किया गया।
नहीं। लॉक मुख्यतः यह बताता है कि कनेक्शन एन्क्रिप्टेड और आम तौर पर प्रमाणीकृत है।
यह नहीं दर्शाता कि:
HTTPS को ट्रांसपोर्ट‑स्तर की सुरक्षा के रूप में देखें—पूरा भरोसा‑निर्णय नहीं।
प्रमाणपत्र एक पब्लिक की को किसी पहचान (जैसे डोमेन नाम) से जोड़ता है। ब्राउज़र उस बाइंडिंग पर इसलिए भरोसा करता है क्योंकि एक Certificate Authority (CA) ने प्रमाणपत्र पर साइन किया होता है, और ब्राउज़र/OS ट्रस्टेड CA‑सूची के साथ आता है।
सर्विस तैनात करते समय ध्यान रखें:
साइन किए गए अपडेट आपकी डिवाइस को दो बातें जांचने देते हैं:
यह ‘पैकेज बदल दें’ हमलों (कम्प्रोमाइज़्ड मिरर, हाईजैक्ड नेटवर्क, दिखावटी डाउनलोड पेज) के खिलाफ सुरक्षा देता है। विस्तृत मार्गदर्शिका के लिए देखें /blog/code-signing-basics।
असल दुनिया में होने वाली विफलताएँ ज़्यादातर संचालन‑सम्बन्धी होती हैं, न कि “RSA का गणित टूट गया” जैसी। सामान्य गलतियाँ:
व्यावहारिक कदम: प्राइवेट‑की को सुरक्षित रखें (हार्डवेयर‑आधारित भंडारण वरीय), समाप्ति‑तिथियों का ट्रैक रखें, की रोटेशन योजनाबद्ध तरीके से करें, और जहाँ संभव हो प्रमाणपत्र जारी होने की निगरानी रखें।