2012-04-09 32 views
5

हाल ही में, मुझे एक दोस्त द्वारा 2011 से post पर इशारा किया गया था, जिसमें Google की आगे की गोपनीयता की ओर बढ़ने का वर्णन किया गया था। जो मैं समझता हूं, उससे आगे की गोपनीयता का सार इस तथ्य में झूठ बोलता है कि निजी कुंजी लगातार भंडारण में नहीं रखी जाती है।आगे की गोपनीयता को समझना

मुझे इस बारे में कई संदेह हैं कि इस तरह कुछ कैसे लागू किया जा सकता है।

  1. क्या होगा यदि सर्वर चेतावनी के बिना नीचे चला जाता है - क्या कुंजी जोड़े को पुन: उत्पन्न किया जाना चाहिए? क्या एक और प्रमाण पत्र बनाने के लिए सार्वजनिक कुंजी पर फिर से हस्ताक्षर किए जाने हैं?
  2. क्या कोई मुझे पोस्ट/पीडीएफ पर इंगित कर सकता है जहां इस तरह के कुछ कार्यान्वयन का वर्णन किया गया है। सुझाए गए संसाधन संसाधन?
  3. क्या आप किसी और के बारे में जानते हैं जिसने आगे की गोपनीयता लागू की है? क्या आपने अपनी कार्यस्थल पर कुछ ऐसा करने की कोशिश की है?

धन्यवाद!

+0

यह भी देखें [परफेक्ट फॉरवर्ड गोपनीयता को कॉन्फ़िगर करने से पहले मुझे क्या पता होना चाहिए] (http://security.stackexchange.com/q/7690/396) – LamonteCristo

+0

बिल्कुल सही आगे की गोपनीयता का मतलब यह नहीं है कि कुंजी कभी भी जारी नहीं है, यह तब होता है जब आप डेटा को एन्क्रिप्ट करने वाली सभी कुंजियों को नष्ट करते हैं। –

उत्तर

4

अग्रेषित गोपनीयता, अभी भी लंबी अवधि की कुंजी हैं। एकमात्र निहितार्थ यह है कि लंबी अवधि की कुंजी के समझौते से हमलावर अस्थायी सत्र कुंजी समझौता करने की अनुमति नहीं देगा, जब दीर्घकालिक कुंजी बदल गई है। इसका मतलब है कि एक लंबी अवधि की कुंजी किसी अन्य (पुरानी) कुंजी से प्राप्त नहीं होनी चाहिए।

Here इस विषय पर एक अच्छा सर्वेक्षण है।

Wikipedia के अनुसार:

  • PFS IPsec (आरएफसी 2412) में एक वैकल्पिक सुविधा है।
  • एसएसएच।
  • ऑफ-द-रिकॉर्ड मैसेजिंग, क्रिप्टोग्राफी प्रोटोकॉल और कई इंस्टेंट मैसेजिंग क्लाइंट्स के लिए लाइब्रेरी, पूर्ण आगे की गोपनीयता और साथ ही अस्वीकार्य एन्क्रिप्शन प्रदान करती है।
  • सिद्धांत रूप में, ट्रांसपोर्ट लेयर सुरक्षा एसएसएलवी 3 के बाद उपयुक्त सिफर चुन सकती है, लेकिन रोजमर्रा के अभ्यास में कई कार्यान्वयन पीएफएस की पेशकश करने से इनकार करते हैं या केवल इसे बहुत कम एन्क्रिप्शन ग्रेड प्रदान करते हैं।
1

टीएलएस में और Diffie-Hellman (डीएच) एल्गोरिदम के माध्यम से आगे की कई अन्य प्रोटोकॉल प्रदान की जाती है। वेनिला डीएच अपेक्षाकृत सरल है और एक्सपोनेंट हर बार यादृच्छिक रूप से जेनरेट किए जाने पर सही आगे की गोपनीयता प्रदान करता है, लेकिन कोई प्रमाणीकरण प्रदान नहीं करता है। इसलिए टीएलएस में यह हस्ताक्षर एल्गोरिदम के साथ संयोजन में उपयोग कर रहा है, आमतौर पर आरएसए।

टीएलएस कई सिफरसूट प्रदान करता है जो पीएफएस और कई जो समर्थन नहीं करते हैं। अधिकांश टीएलएस क्लाइंट पीएफएस का समर्थन करते हैं लेकिन कई सर्वर नहीं करते हैं, क्योंकि ऐसा माना जाता है कि पीएफएस बहुत अधिक CPU लेता है।

+0

मैंने सोचा कि आपको "क्षणिक डीएच" (एडीएच) की आवश्यकता है, और न केवल आगे की गोपनीयता के लिए डीएच। Http://crypto.stackexchange.com/questions/8933/how-can-i-use-ssl-tls-with-perfect-forward-secrecy देखें –