ओपनएसएसएल बनाम जीपीजी?

Question

एक ऑफ साइट बैकअप स्थान के लिए अभिलेखागार धकेलने से पहले स्थानीय एन्क्रिप्शन के लिए GPG और OpenSSL का उपयोग कर के बीच का विकल्प, क्या लाभ और प्रत्येक समाधान की कमियां हैं को देखते हुए?

पृष्ठभूमि: मैं वर्तमान में उबंटू 14.04.1 के आधार पर एक सर्वर आधारभूत संरचना का प्रबंधन करता हूं, क्योंकि वे उपलब्ध होने पर लागू सभी मौजूदा पैच के साथ।

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

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

सभी सॉफ्टवेयर और विन्यास कठपुतली के माध्यम से किया जाता है, इसलिए कोई भी निर्णय "उपयोगकर्ता अनुभव" या सुविधा पर कोई प्रभाव नहीं पड़ेगा। या तो विकल्प किसी भी बैकअप से प्रबंधित, सत्यापित या पुनर्स्थापित करने के लिए प्रासंगिक स्क्रिप्ट बनाएगा।

यह देखते हुए कि, या तो एन्क्रिप्शन विकल्प जब इस उद्देश्य के लिए इस्तेमाल दूसरे के खिलाफ किसी भी लाभ की पेशकश करता है?

Answer 1

मैं फ़ाइल एन्क्रिप्शन के लिए जीपीजी चुनूंगा, इसे दशकों का सुरक्षित परीक्षण एन्क्रिप्शन मिल गया है, और कई "प्राप्तकर्ता" (बैकअप कुंजी?) या इसके सार्वजनिक कुंजी के साथ हस्ताक्षर & सर्वर भी हैं (यदि वे उपयोगी होंगे)।

जीपीजी के साथ, सभी सरल गलतियों को टाला/तय किया गया है, यह वास्तविक एन्क्रिप्शन के लिए एक लंबी "यादृच्छिक" कुंजी चुनता है और इसे बहुत सुरक्षित बनाने के लिए "राउंड" की अच्छी संख्या करता है।

OpenSSL सभी एक ही काम करने के लिए सक्षम होना चाहिए, (इसके चारों ओर 1998 के बाद से किया गया है, लेकिन अगर संस्करण संख्याओं मतलब है कि यह 2010 में संस्करण 1 पर पहुंच गया कुछ भी), लेकिन यह एक गलती है कि काफी कम कर सकता बनाने के लिए बहुत आसान है सुरक्षा। और this post on security.stackexchange.com से and another (जनवरी 2013 से) एक 159K प्रतिष्ठा उपयोगकर्ता द्वारा, openssl enc आदेश कुछ छोड़ सकता है वांछित करने के लिए किया जा:

एन्क्रिप्शन OpenSSL द्वारा इस्तेमाल किया प्रारूप अमानक है: यह है "क्या OpenSSL करता है", और यदि ओपनएसएसएल के सभी संस्करण एक-दूसरे से सहमत हैं, तो अभी भी कोई संदर्भ दस्तावेज़ नहीं है जो ओपनएसएसएल स्रोत कोड को छोड़कर इस प्रारूप का वर्णन करता है।

जादू मूल्य (8 बाइट्स): बाइट्स 53 61 6C 74 65 64 5F 5F नमक मूल्य (8 बाइट्स)

इसलिए एक निश्चित 16-बाइट हैडर, के साथ शुरुआत हैडर प्रारूप बल्कि सरल है "नमकीन__" स्ट्रिंग के ASCII एन्कोडिंग, इसके बाद नमक स्वयं। बस इतना ही ! एन्क्रिप्शन एल्गोरिदम का कोई संकेत नहीं; आपको अपने आप को ट्रैक रखना चाहिए।

प्रक्रिया है जिसके द्वारा पासवर्ड और नमक कुंजी में बदल जाता है और चतुर्थ दर्ज नहीं किया है, लेकिन स्रोत कोड पर एक नज़र से पता चलता है कि यह कॉल OpenSSL विशेष EVP_BytesToKey() समारोह है, जो कुछ दोहराया हैशिंग के साथ एक कस्टम key derivation function का उपयोग करता है । यह एक गैर मानक और अच्छी तरह से vetted निर्माण (!) है जो संदिग्ध प्रतिष्ठा (!!) के एमडी 5 हैश समारोह पर निर्भर करता है; कि समारोह अप्रलेखित-md ध्वज के साथ कमांड लाइन पर बदला जा सकता है (!!!); "पुनरावृत्ति गणना" enc कमांड पर सेट की गई है और इसे बदला नहीं जा सकता (!!!!)। इसका मतलब है कि कुंजी के पहले 16 बाइट एमडी 5 (पासवर्ड || नमक) के बराबर होंगे, और यही वह है।

यह काफी कमजोर है! कोई भी जो पीसी पर कोड लिखना जानता है, इस तरह की एक योजना को तोड़ने का प्रयास कर सकता है और प्रति सेकंड कई लाखों संभावित पासवर्ड "कोशिश" करने में सक्षम होगा (सैकड़ों लाखों जीपीयू के साथ प्राप्त किए जा सकेंगे)। यदि आप "openssl enc" का उपयोग करते हैं, तो सुनिश्चित करें कि आपके पासवर्ड में बहुत अधिक एन्ट्रॉपी है! (यानी आमतौर पर अनुशंसित से अधिक; कम से कम 80 बिट्स के लिए लक्ष्य)। या, अधिमानतः, इसका बिल्कुल उपयोग न करें; इसके बजाए, कुछ और मजबूत (GnuPG) के लिए जाएं, पासवर्ड के लिए सममित एन्क्रिप्शन करते समय, अंतर्निहित हैश फ़ंक्शन के कई पुनरावृत्तियों के साथ एक मजबूत केडीएफ का उपयोग करता है)।

एक पुनरावृत्ति संख्या शामिल करने के लिए अनुमति देने वाला विकल्प होनी चाहिए:

man enc भी इस के तहत है "बग"।