उपयोगकर्ता द्वारा चुने गए पासवर्ड के साथ सार्वजनिक कुंजी क्रिप्टोग्राफ़ी?

Question

संपूर्ण बिंदु एक साधारण प्रणाली को डिजाइन कर रहा है जहां उपयोगकर्ता उनके बीच एन्क्रिप्टेड संदेश भेजने में सक्षम हैं (सर्वर से समर्थन के साथ)।

इस परिदृश्य में, ग्राहकों के पास कोई स्थानीय संग्रहण नहीं है, इसलिए मुझे पासवर्ड का उपयोग करने के लिए मजबूर होना पड़ता है कि उपयोगकर्ता आवश्यकतानुसार चुनने, याद रखने और टाइप करने में सक्षम होंगे। (मैं इस पूरी व्यवस्था को कमजोर जानते हैं, लेकिन यह एक कठिन आवश्यकता है)

एक अन्य आवश्यकता है कि सर्वर क्लियर निजी कुंजी या किसी अन्य डेटा जो संदेशों डिक्रिप्ट करने के लिए (उदाहरण के लिए इस्तेमाल किया जा सकता संग्रहीत नहीं कर सकता है: केवल उपयोगकर्ता एन्क्रिप्टेड संदेशों को पढ़ सकता है, सर्वर व्यवस्थापक सक्षम नहीं होना चाहिए)।

मेरा दृष्टिकोण क्लाइंट पर असममित कीपैयर उत्पन्न करना होगा, निजी कुंजी की एन्क्रिप्टेड प्रति (उपयोगकर्ता पासवर्ड से एन्क्रिप्टेड) ​​के साथ सर्वर पर सार्वजनिक कुंजी प्रकाशित करना होगा। उपयोगकर्ता प्राप्तकर्ता सार्वजनिक कुंजी प्राप्तकर्ता का उपयोग करके अन्य उपयोगकर्ताओं को एन्क्रिप्टेड संदेश भेज सकते हैं; जब किसी उपयोगकर्ता को किसी संदेश को डिक्रिप्ट करने की आवश्यकता होती है, तो उसकी (एन्क्रिप्टेड) ​​निजी कुंजी क्लाइंट पर सर्वर से लाई जाती है, उपयोगकर्ता द्वारा प्रदान किए गए पासवर्ड से डिक्रिप्ट की जाती है और फिर संदेशों को डिक्रिप्ट करने के लिए उपयोग की जाती है।

क्या इसका कोई अर्थ है? क्या इस सिस्टम डिज़ाइन में कोई दोष है? (छोटे या बुरे पासवर्ड चुनने वाले उपयोगकर्ताओं से प्राप्त कमजोरी के अलावा) क्या यह दृष्टिकोण पहले से ही इसी तरह के परिदृश्यों में उपयोग किया जाता है?

धन्यवाद :)

Answer 1

यदि मैं सही ढंग से समझता हूं, तो आप एक ऐसी प्रणाली बनाना चाहते हैं जहां दो उपयोगकर्ता एक सर्वर के माध्यम से निजी संचार शुरू कर सकें, जिसे वे भरोसा नहीं करते हैं।

यह काम नहीं करेगा।

परिदृश्य में आप बाहर निकलते हैं, सर्वर अपनी कुंजी जोड़ी उत्पन्न कर सकता है, और उपयोगकर्ताओं की जगह अपनी सार्वजनिक कुंजी प्रकाशित कर सकता है। जब कोई उपयोगकर्ता किसी संदेश को एन्क्रिप्ट करता है, तो उसे अपने साथी के लिए लक्षित करता है, तो वे यह नहीं पता लगा सकते कि सर्वर ने अपनी सार्वजनिक कुंजी को प्रतिस्थापित कर दिया है।सर्वर संदेश को डिक्रिप्ट करता है, इसे सर्वर प्रशासकों को प्रस्तुत करता है, और वास्तविक साझेदार सार्वजनिक कुंजी के साथ इसे फिर से एन्क्रिप्ट करता है (या कुछ नया संदेश जिसे उन्होंने बनाया), और इसे गंतव्य के लिए आगे बढ़ाया।

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

उपयोगकर्ताओं को सीए पर भरोसा करना है, जो सर्वर प्रशासकों पर भरोसा करने से अधिक आकर्षक हो सकता है। लेकिन, सीए प्रमाण पत्र को स्टोर करने के लिए एक छेड़छाड़ का तरीका भी होना चाहिए। अभ्यास में, यह अक्सर पासवर्ड-आधारित मैक (संदेश प्रमाणीकरण कोड) का उपयोग करके किया जाता है। या, सीए को उपयोगकर्ता की निजी कुंजी के साथ डिजिटल हस्ताक्षरित किया जा सकता है (इसे कभी नहीं देखा, लेकिन यह काम करेगा)। लेकिन मुश्किल हिस्सा अविश्वसनीय सर्वर को छोड़कर, एक विश्वसनीय स्रोत से सीए प्रमाण पत्र प्राप्त करेगा।

जहां तक ​​पासवर्ड के साथ निजी कुंजी एन्क्रिप्ट करना है, यह अक्सर किया जाता है, और आपके द्वारा चुने गए पासवर्ड के रूप में सुरक्षित है।

वैकल्पिक रूप से, यदि उपयोगकर्ता एक-दूसरे के साथ एक रहस्य साझा कर सकते हैं, तो आपको सार्वजनिक कुंजी एन्क्रिप्शन की आवश्यकता नहीं है। ग्राहक साझा किए गए रहस्य को उपयोगकर्ता द्वारा चुने गए पासवर्ड से एन्क्रिप्ट कर सकता है, और सर्वर पर सिफर टेक्स्ट स्टोर कर सकता है।

Answer 2

के रूप में वर्णित है, इस योजना के उचित लगता है कि यह किसी अन्य व्यक्ति के संदेश है कि केवल प्राप्तकर्ता पढ़ सकते हैं भेजने के लिए अनुमति चाहिए।

• जब निजी कुंजी को एनक्रिप्ट, नमक और कुछ काफ़ी बड़ी संख्या में यह पुनरावृत्तियों साथ PBKDF2 की तरह कुछ का उपयोग करें: वहाँ कुछ आइटम है कि मन में है कि आप पहले से ही के बारे में सोचा हो सकता है लेकिन संक्षिप्तता के लिए बाहर छोड़ दिया आते हैं।
• यह शायद इंगित किया गया है, लेकिन सार्वजनिक कुंजी के साथ एन्क्रिप्ट करने के बजाय, शायद यह एक यादृच्छिक कुंजी उत्पन्न करने के लिए समझ में आता है (उदाहरण के लिए, उपयोग करने पर यादृच्छिक डेटा के 32-बाइट्स, उदाहरण के लिए, एईएस -256)। उस कुंजी के साथ संदेश एन्क्रिप्ट करें, कुंजी को सार्वजनिक कुंजी से एन्क्रिप्ट करें, और दोनों टुकड़े भेजें।
• जैसा कि वर्णन किया गया है, प्रेषक की कोई पहचान नहीं है। यह पूरी तरह से अज्ञात संदेशों को भेजने की अनुमति देता है। इसका इरादा हो सकता है, लेकिन यदि नहीं, तो किसी प्रकार की पहचान/प्रमाणीकरण आवश्यक होगा।
• कुछ हद तक पिछली प्रविष्टि के समान, कोई संदेश प्रमाणीकरण का वर्णन नहीं किया गया है। हमलावर एन्क्रिप्टेड संदेश बदल सकता है और प्राप्तकर्ता यह बताने में सक्षम नहीं होगा कि यह बदल गया था। हालांकि, यदि यह एक टेक्स्ट संदेश है, तो यह स्पष्ट होगा कि इसे संशोधित किया गया था, क्योंकि यह सिर्फ खराब टेक्स्ट होगा। कुछ प्रकार के डेटा हैं, हालांकि, यह बताने में इतना आसान नहीं हो सकता है कि इसे संशोधित किया गया है या नहीं।

Answer 3

ऐसा कुछ ऐसा लगता है जो हुशमेल ने किया था। हालांकि, इसमें एक बड़ी समस्या थी, क्योंकि उनके पास उपयोगकर्ताओं की निजी कुंजी थी (एन्क्रिप्टेड), उन्हें सिर्फ एक हैक किए गए जावा एप्लेट को धक्का देना पड़ा जो उपयोगकर्ता के पासवर्ड को सर्वर (जिसे उन्होंने किया) भेज दिया था।

सर्वर पर उस निजी कुंजी को रोकने से बचने के लिए एक बेहतर समाधान है। कोई स्थानीय भंडारण की आवश्यकता के साथ, यह बाहर है।

प्री-साझा पासवर्ड के माध्यम से सममित एन्क्रिप्शन का उपयोग क्यों नहीं करें? यह ग्राहक पक्ष पर भंडारण के बिना किया जा सकता है। मेरा मानना ​​है कि यही वह है जो @ सिकसन अपने अंतिम अनुच्छेद में कह रहा था।

Answer 4

बड़ी समस्या यह है कि यदि सर्वर से डिक्रिप्शन कोड डाउनलोड किया जाता है, तो एक (या तो सर्वर व्यवस्थापक या सर्वर पर हैकर जो है) इस कोड को प्रतिस्थापित कर सकता है। क्लाइंट साइड पर उपयोगकर्ता को सर्वर पर भरोसा करना चाहिए, लेकिन उसके पास विश्वास करने के लिए सर्वर को सत्यापित करने का कोई तरीका नहीं है।