AES एन्क्रिप्शन मोड (CBC ECB CTR OCB CFB) कैसे चुनें?


478

उनमें से किन परिस्थितियों में पसंद किया जाता है?

मैं विभिन्न मोड के लिए मूल्यांकन क्रेटेरिया की सूची देखना चाहता हूं, और शायद प्रत्येक मानदंड की प्रयोज्यता की चर्चा।

उदाहरण के लिए, मुझे लगता है कि एन्क्रिप्शन और डिक्रिप्शन के लिए एक मानदंड "कोड का आकार" है, जो 802.11 नेटवर्क एडेप्टर जैसे माइक्रो-कोड एम्बेडेड सिस्टम के लिए महत्वपूर्ण है। यदि CBC को लागू करने के लिए आवश्यक कोड CTR के लिए आवश्यक से बहुत छोटा है (मुझे नहीं पता कि यह सच है, यह सिर्फ एक उदाहरण है), तो मैं समझ सकता था कि छोटे कोड के साथ मोड को क्यों पसंद किया जाएगा। लेकिन अगर मैं एक सर्वर पर चलने वाला ऐप लिख रहा हूं, और एईएस लाइब्रेरी मैं वैसे भी सीबीसी और सीटीआर दोनों का उपयोग कर रहा हूं, तो यह मानदंड अप्रासंगिक है।

देखें कि "मूल्यांकन मानदंडों और प्रत्येक कसौटी की प्रयोज्यता की सूची" से मेरा क्या मतलब है ??

यह वास्तव में संबंधित प्रोग्रामिंग नहीं है, लेकिन यह एल्गोरिथ्म संबंधित है।


22
"यह वास्तव में संबंधित प्रोग्रामिंग नहीं है, लेकिन यह एल्गोरिथ्म संबंधित है।" ∵ एल्गोरिदम को गणित द्वारा दर्शाया जा सकता है। ∵ कंप्यूटर प्रोग्रामिंग को गणित द्वारा प्रस्तुत किया जा सकता है। About आपका सवाल कंप्यूटर प्रोग्रामिंग के बारे में है।
टायलर गिलीज़

40
"यह वास्तव में संबंधित प्रोग्रामिंग नहीं है, लेकिन यह एल्गोरिथ्म संबंधित है।" , एल्गोरिदम को गणित द्वारा दर्शाया जा सकता है, और शेयर बाजारों को गणित द्वारा दर्शाया जा सकता है, आपका प्रश्न शेयर बाजारों के बारे में है। / व्यंग्य के लिए खेद है, लेकिन जब निष्कर्ष बहुत स्पष्ट रूप से सही था, तो तर्क बहुत स्पष्ट रूप से गलत था
Shien

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

जवाबों:


324
  • ईसीबी का उपयोग नहीं किया जाना चाहिए यदि एक ही कुंजी के साथ डेटा के एक से अधिक ब्लॉक को एन्क्रिप्ट किया जाए।

  • सीबीसी, ओएफबी और सीएफबी समान हैं, हालांकि ओएफबी / सीएफबी बेहतर है क्योंकि आपको केवल एन्क्रिप्शन की आवश्यकता है और डिक्रिप्शन की नहीं, जो कोड स्थान को बचा सकता है।

  • यदि आप CBC / OFB / CFB के बजाय अच्छा समानांतरकरण (यानी गति) चाहते हैं तो CTR का उपयोग किया जाता है।

  • XTS मोड सबसे आम है यदि आप एक यादृच्छिक सुलभ डेटा (जैसे हार्ड डिस्क या रैम) को एन्कोडिंग कर रहे हैं।

  • OCB अब तक का सबसे अच्छा मोड है, क्योंकि यह एक पास में एन्क्रिप्शन और ऑथेंटिकेशन की अनुमति देता है। हालाँकि अमरीका में इस पर पेटेंट हैं।

केवल एक चीज जिसे आपको वास्तव में जानना है, वह यह है कि ईसीबी का उपयोग नहीं किया जाना है जब तक कि आप केवल 1 ब्लॉक एन्क्रिप्ट नहीं कर रहे हैं। यदि आप बेतरतीब ढंग से एक्सेस किए गए डेटा को एनक्रिप्ट कर रहे हैं तो एक्सटीएस का उपयोग किया जाना चाहिए, न कि स्ट्रीम।

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

65
CBC, OFB और CFB एक समान हैं।
जोनाथन लेफलर

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

9
यहां तक ​​कि अगर आप केवल एक ब्लॉक को एन्क्रिप्ट कर रहे हैं, तो ईसीबी का उपयोग नहीं किया जाना चाहिए यदि आप एक ही कुंजी के साथ एक से अधिक बार (यहां तक ​​कि संभवतः एक से अधिक बार) एक ही एन्क्रिप्ट कर रहे हैं।
13

23
... एक उत्तर कैसे कहता है कि "सीबीसी, ओएफबी और सीएफबी समान हैं" एक भी डाउनवोट नहीं है?
माइकल Mrozek

30
GCM OCB (प्रदर्शन और अन्य गुणों) से बहुत मिलता-जुलता है, लेकिन यह किसी भी पेटेंट से मुग्ध नहीं है, इसलिए यह सबसे अच्छा विकल्प है। केवल नकारात्मक तथ्य यह है कि कार्यान्वयन अत्यधिक जटिल है - लेकिन आपको इस बारे में चिंता करने की ज़रूरत नहीं है कि यदि आप एक पुस्तकालय का उपयोग करते हैं।
ntoskrnl

407

यदि आप अपनी स्वयं की क्रिप्टोग्राफी लागू करने के आसपास नहीं पहुंच सकते हैं, तो कृपया लंबे और कठिन विचार करें

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

मुझे अपनी बात स्पष्ट करने दें: कल्पना कीजिए कि आप एक वेब एप्लिकेशन बना रहे हैं और आपको कुछ सत्र डेटा संग्रहीत करने की आवश्यकता है। आप प्रत्येक उपयोगकर्ता को एक सत्र ID दे सकते हैं और सत्र डेटा के लिए हैश मैप मैपिंग सत्र ID में सत्र डेटा संग्रहीत कर सकते हैं। लेकिन फिर आपको सर्वर पर इस pesky स्थिति से निपटना होगा और यदि कुछ बिंदु पर आपको एक से अधिक सर्वर चीजों की आवश्यकता होगी तो गड़बड़ हो जाएगी। तो इसके बजाय आपके पास क्लाइंट में सत्र डेटा को कुकी में संग्रहीत करने का विचार है। आप इसे निश्चित रूप से एन्क्रिप्ट करेंगे ताकि उपयोगकर्ता डेटा को पढ़ और हेरफेर न कर सके। तो आपको किस मोड का उपयोग करना चाहिए? यहाँ आकर आप शीर्ष उत्तर पढ़ते हैं (सॉरी के लिए खेद है कि आप myforwik बाहर हैं)। पहले एक कवर - ईसीबी - आपके लिए नहीं है, आप एक से अधिक ब्लॉक एन्क्रिप्ट करना चाहते हैं, अगले एक - सीबीसी - अच्छा लगता है और आपको सीटीआर के समानता की आवश्यकता नहीं है, आपको यादृच्छिक एक्सेस की आवश्यकता नहीं है, तो कोई XTS और पेटेंट कोई PITA है, तो कोई OCB। अपनी क्रिप्टो लाइब्रेरी का उपयोग करके आप महसूस करते हैं कि आपको कुछ पैडिंग की आवश्यकता है क्योंकि आप केवल ब्लॉक आकार के गुणकों को एन्क्रिप्ट कर सकते हैं। आप चुनते हैंPKCS7 क्योंकि यह कुछ गंभीर क्रिप्टोग्राफी मानकों में परिभाषित किया गया था। कहीं पढ़ने के बाद कि सीबीसी एक यादृच्छिक आईवी और एक सुरक्षित ब्लॉक सिफर के साथ उपयोग किए जाने पर सुरक्षित रूप से सुरक्षित है, तो आप आराम से आराम करते हैं, भले ही आप क्लाइंट पक्ष पर अपने संवेदनशील डेटा को संग्रहीत कर रहे हों।

आपकी सेवा के वास्तव में महत्वपूर्ण आकार तक बढ़ने के बाद, एक आईटी सुरक्षा विशेषज्ञ आपको एक जिम्मेदार प्रकटीकरण में संपर्क करता है। वह कह रही है कि वह आपके सभी कुकीज़ को पेडिंग ऑरेकल हमले का उपयोग करके डिक्रिप्ट कर सकती है , क्योंकि आपका कोड एक एरर पेज बनाता है यदि पैडिंग किसी तरह टूटी हुई है।

यह कोई काल्पनिक परिदृश्य नहीं है: Microsoft के पास कुछ वर्षों पहले तक ASP.NET में यह सटीक दोष था।

समस्या यह है कि क्रिप्टोग्राफी के बारे में बहुत सारे नुकसान हैं और एक प्रणाली का निर्माण करना बहुत आसान है जो आम आदमी के लिए सुरक्षित है लेकिन एक जानकार हमलावर के लिए तोड़ने के लिए तुच्छ है।

यदि आपको डेटा एन्क्रिप्ट करने की आवश्यकता है तो क्या करें

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

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

यदि किसी कारण से आप उच्च स्तरीय क्रिप्टो लाइब्रेरी का उपयोग नहीं कर सकते हैं, उदाहरण के लिए क्योंकि आपको मौजूदा सिस्टम के साथ एक विशिष्ट तरीके से बातचीत करने की आवश्यकता है, तो अपने आप को पूरी तरह से शिक्षित करने का कोई तरीका नहीं है। मैं Ferguson, Kohno और Schneier द्वारा क्रिप्टोग्राफी इंजीनियरिंग पढ़ने की सलाह देता हूं । कृपया विश्वास न करें कि आप आवश्यक पृष्ठभूमि के बिना एक सुरक्षित प्रणाली का निर्माण कर सकते हैं। क्रिप्टोग्राफी अत्यंत सूक्ष्म है और यह एक प्रणाली की सुरक्षा का परीक्षण करने के लिए असंभव है।

साधनों की तुलना

केवल एन्क्रिप्शन:

  • पैड्स जिन्हें पेडिंग की आवश्यकता होती है : उदाहरण की तरह, पैडिंग आम तौर पर खतरनाक हो सकती है क्योंकि इससे पैडल ऑरेकल हमलों की संभावना खुल जाती है। सबसे आसान बचाव डिक्रिप्शन से पहले हर संदेश को प्रमाणित करना है। निचे देखो।
    • ईसीबी स्वतंत्र रूप से डेटा के प्रत्येक ब्लॉक को एन्क्रिप्ट करता है और समान प्लेनटेक्स्ट ब्लॉक का परिणाम उसी सिफरटेक्स्ट ब्लॉक में होगा। ईसीबी विकिपीडिया पृष्ठ पर ईसीबी एन्क्रिप्टेड टक्स छवि पर एक नज़र डालें कि यह क्यों एक गंभीर समस्या है। मुझे ऐसे किसी उपयोग के मामले की जानकारी नहीं है जहां ईसीबी स्वीकार्य होगा।
    • CBC में एक IV है और इस प्रकार संदेश को एन्क्रिप्ट किए जाने पर हर बार यादृच्छिकता की आवश्यकता होती है, संदेश के एक हिस्से को बदलने के लिए परिवर्तन के बाद सब कुछ फिर से एन्क्रिप्ट करने की आवश्यकता होती है, एक सिफरटेक्स्ट ब्लॉक में ट्रांसमिशन त्रुटियां पूरी तरह से प्लेनेट को नष्ट कर देती हैं और अगले ब्लॉक की डिक्रिप्शन को बदल देती हैं, डिक्रिप्शन समानांतर किया जा सकता है / एन्क्रिप्शन नहीं कर सकता, प्लेनटेक्स्ट एक निश्चित डिग्री तक निंदनीय है - यह एक समस्या हो सकती है
  • स्ट्रीम सिफर मोड : ये मोड डेटा की एक छद्म यादृच्छिक धारा उत्पन्न करते हैं जो प्लेनटेक्स्ट पर निर्भर हो सकती है या नहीं भी। इसी तरह आमतौर पर सिफर्स को स्ट्रीम करने के लिए, उत्पन्न छद्म यादृच्छिक धारा सिफरटेक्स्ट उत्पन्न करने के लिए प्लेनटेक्स्ट के साथ XORed है। जैसा कि आप यादृच्छिक धारा के कई बिट्स का उपयोग कर सकते हैं जैसे कि आप की तरह आपको पैडिंग की आवश्यकता नहीं है। इस सरलता का नुकसान यह है कि एन्क्रिप्शन पूरी तरह से है निंदनीय है, जिसका अर्थ है कि डिक्रिप्शन को एक हमलावर द्वारा किसी भी तरह से बदला जा सकता है, जैसे कि वह एक प्लेटेक्स्ट पी 1, एक सिफरटेक्स्ट सी 1 और एक छद्म यादृच्छिक स्ट्रीम आर और हमलावर के लिए पसंद करता है, एक डिफरेंशियल चुन सकता है जैसे कि एक सिफरटेक्स सी 2 = सी 1 डी का डिक्रिप्शन P2 = p1 p2d है, P2 = c2 (r = (c1 ⊕ d) = r = d ⊕ (c1) r) के रूप में। इसके अलावा एक ही छद्म यादृच्छिक धारा को दो सिफरटेक्स c1 = p1⊕r और c2 = P2 cr के लिए दो बार उपयोग नहीं किया जाना चाहिए, एक हमलावर दो सादे अक्षरों के xor को c1⊕c2 - p1⊕r⊕p2⊕r = के रूप में गणना कर सकता है p1⊕p2। इसका मतलब यह भी है कि संदेश को बदलने के लिए पूर्ण पुन: एन्क्रिप्शन की आवश्यकता होती है, अगर मूल संदेश किसी हमलावर द्वारा प्राप्त किया जा सकता था। निम्नलिखित सभी स्टीम सिफर मोड में केवल ब्लॉक सिफर के एन्क्रिप्शन ऑपरेशन की आवश्यकता होती है, इसलिए सिफर के आधार पर यह अत्यंत सीमित वातावरण में कुछ (सिलिकॉन या मशीन कोड) स्थान को बचा सकता है।
    • CTR सरल है, यह एक छद्म यादृच्छिक धारा बनाता है जो कि प्लेटेक्स्ट से स्वतंत्र है, विभिन्न छद्म यादृच्छिक धाराएँ विभिन्न नॉन / IVs से गिनती करके प्राप्त की जाती हैं जो एक अधिकतम संदेश की लंबाई से गुणा होती हैं ताकि ओवरलैप को रोका जा सके, नॉनस मैसेज एन्क्रिप्शन का उपयोग किया जाता है। प्रति संदेश यादृच्छिकता के बिना संभव, डिक्रिप्शन और एन्क्रिप्शन को समानांतर किया जा सकता है, ट्रांसमिशन त्रुटियां केवल गलत बिट्स को प्रभावित करती हैं और इससे अधिक कुछ नहीं
    • ओएफबी प्लेसेक्स्ट से स्वतंत्र एक छद्म यादृच्छिक धारा भी बनाता है, हर संदेश के लिए एक अलग गैर या यादृच्छिक IV के साथ शुरू करके विभिन्न छद्म यादृच्छिक धाराएँ प्राप्त की जाती हैं, न तो एन्क्रिप्शन और न ही डिक्रिप्शन समांतर है, क्योंकि सीटीआर के साथ बिना संदेश का उपयोग किए बिना एन्क्रिप्शन संभव है। यादृच्छिकता, सीटीआर ट्रांसमिशन त्रुटियों के साथ केवल गलत बिट्स को प्रभावित करती है और अधिक कुछ नहीं
    • सीएफबी की छद्म यादृच्छिक धारा प्लेनटेक्स्ट पर निर्भर करती है, हर संदेश के लिए एक अलग नॉन या रैंडम IV की आवश्यकता होती है, जैसे कि सीटीआर और ओएफबी के साथ नॉनस मैसेज एन्क्रिप्शन का उपयोग करना प्रति संदेश यादृच्छिकता के बिना संभव है, डिक्रिप्शन समानांतर करने योग्य / एन्क्रिप्शन नहीं है, ट्रांसमिशन त्रुटियों पूरी तरह से है। निम्न ब्लॉक को नष्ट करें, लेकिन केवल वर्तमान ब्लॉक में गलत बिट्स को प्रभावित करें
  • डिस्क एन्क्रिप्शन मोड : ये मोड फ़ाइल सिस्टम एब्सट्रैक्शन के नीचे डेटा एन्क्रिप्ट करने के लिए विशेष हैं। दक्षता कारणों से डिस्क पर कुछ डेटा बदलने के लिए केवल एक डिस्क ब्लॉक (512 बाइट्स या 4kib) पर फिर से लिखना होगा। वे इस उत्तर के दायरे से बाहर हैं क्योंकि उनके पास अन्य की तुलना में अलग-अलग उपयोग परिदृश्य हैं। ब्लॉक स्तर डिस्क एन्क्रिप्शन को छोड़कर किसी भी चीज़ के लिए उनका उपयोग न करें । कुछ सदस्य: XEX, XTS, LRW।

प्रमाणित एन्क्रिप्शन:

गद्दी हमलों और सिफरटेक्स्ट में परिवर्तन को रोकने के लिए, कोई सिफरटेक्स्ट पर एक संदेश प्रमाणीकरण कोड (मैक) की गणना कर सकता है और केवल तभी इसे डिक्रिप्ट कर सकता है यदि इसके साथ छेड़छाड़ नहीं की गई है। इसे एन्क्रिप्ट-तब-मैक कहा जाता है और इसे किसी अन्य क्रम में पसंद किया जाना चाहिए । बहुत कम उपयोग मामलों को छोड़कर प्रामाणिकता उतनी ही महत्वपूर्ण है जितनी गोपनीयता (जिसका उत्तरार्द्ध एन्क्रिप्शन का उद्देश्य है)। प्रमाणित एन्क्रिप्शन योजनाएं (संबंधित डेटा (AEAD) के साथ) एन्क्रिप्शन और प्रमाणीकरण की दो भाग प्रक्रिया को एक ब्लॉक सिफर मोड में जोड़ती है जो प्रक्रिया में एक प्रमाणीकरण टैग भी बनाती है। ज्यादातर मामलों में यह गति में सुधार होता है।

  • CCM CTR मोड और CBC-MAC का एक सरल संयोजन है। प्रति ब्लॉक दो ब्लॉक सिफर एनक्रिप्ट का उपयोग करना बहुत धीमा है।
  • OCB तेज है लेकिन पेटेंट से मुग्ध है। मुक्त (स्वतंत्रता के रूप में) या गैर-सैन्य सॉफ्टवेयर के लिए पेटेंट धारक ने एक मुफ्त लाइसेंस दिया है , हालांकि।
  • जीसीएम सीटीआर मोड और जीएचएएसएच का एक बहुत तेज लेकिन यकीनन जटिल संयोजन है, 2 ^ 128 तत्वों के साथ गैलोज़ मैदान पर एक मैक। TLS 1.2 जैसे महत्वपूर्ण नेटवर्क मानकों में इसका व्यापक उपयोग एक विशेष निर्देश द्वारा परिलक्षित होता है, जिसे Intel ने GHASH की गणना को गति देने के लिए पेश किया है।

सिफ़ारिश करना:

प्रमाणीकरण के महत्व को ध्यान में रखते हुए, मैं अधिकांश उपयोग के मामलों (डिस्क एन्क्रिप्शन उद्देश्यों को छोड़कर) के लिए निम्नलिखित दो ब्लॉक सिफर मोड की सिफारिश करूंगा: यदि डेटा एक असममित हस्ताक्षर सीबीसी द्वारा प्रमाणित है, अन्यथा GCM का उपयोग करें।


211
"यदि आपको यह प्रश्न पूछने की आवश्यकता है तो आप शायद सुरक्षित प्रणाली को लागू करने के लिए क्रिप्टोग्राफी के बारे में पर्याप्त नहीं जानते हैं।" - आप सही हैं, लेकिन आपको एहसास है कि सवाल पूछना लोगों को सीखना है? तो शायद थोड़ा आराम करें।
रॉबर्ट मैकलीन

69
@RobertMacLean सच है, लेकिन आईटी में कई अन्य क्षेत्रों के विपरीत आपको कोशिश और त्रुटि से सुरक्षा अधिकार नहीं मिलेगा। जबकि वेब डिज़ाइन, एप्लिकेशन स्केलेबिलिटी आदि के साथ आप अपनी आवश्यकताओं को सक्रिय रूप से जांच सकते हैं, सुरक्षा पहलुओं का परीक्षण कठिन से असंभव तक होता है। दुर्भाग्य से यह एक सबक है जिसे शायद ही कभी पढ़ाया जाता है। अधिकांश संसाधन आपको बताते हैं कि क्रिप्टोग्राफी कैसे काम करती है और न कि असंख्य तरीके यह अभ्यास में विफल रहता है, इसके बारे में भी आपको जानकारी नहीं है। एकमात्र तरीका विषय के बारे में बहुत कुछ जानना है। और यह पद का मनोबल है:
पर्स

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

32
माइनस एक: शुरुआती शीर्षक गलत है; यह कहना चाहिए "यदि आप इस प्रश्न को पूछ रहे हैं तो आप सही दिशा में जा रहे हैं, इसे बनाए रखें और आप उत्कृष्टता प्राप्त करेंगे!"
हेनरिक

11
@FerminSilva: सच है, लेकिन तर्क का एक और पहलू यह है कि क्रिप्टो कोड को कॉपी-पेस्ट करने की तुलना में सही और परीक्षण किए गए समाधानों का उपयोग करना अक्सर आसान होता है । उदाहरण के लिए, जब आप एक स्मार्टफ़ोन ऐप से अपने सर्वर के साथ बात करना चाहते हैं, तो लेट्स एनक्रिप्ट टीएलएस प्रमाणपत्र के साथ अपाचे रिवर्स प्रॉक्सी सेट करना और https://your.serverअपने ऐप में हर जगह लिखना आसान है, कुछ प्रमुख एक्सचेंज प्रोटोकॉल का आविष्कार करने के लिए और दोनों क्रिप्टोग्राफी पुस्तकालयों को सुचारू रूप से एक साथ काम करने के लिए प्राप्त करें।
पर्सिड्स

36

एक औपचारिक विश्लेषण 2011 में फिल Rogaway द्वारा किया गया है, यहाँ । खंड 1.6 एक सारांश देता है जिसे मैं यहां प्रस्तुत करता हूं, अपने खुद के जोर को जोड़कर (यदि आप अधीर हैं, तो उसकी सिफारिश सीटीआर मोड का उपयोग करती है, लेकिन मेरा सुझाव है कि आप संदेश अखंडता बनाम नीचे एन्क्रिप्शन के बारे में मेरे पैराग्राफ पढ़ें)।

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

साथ ही, संदेश की अखंडता और एन्क्रिप्शन के बीच अंतर को समझना महत्वपूर्ण है। एन्क्रिप्शन डेटा छुपाता है, लेकिन एक हमलावर एन्क्रिप्टेड डेटा को संशोधित करने में सक्षम हो सकता है, और यदि आप संदेश अखंडता की जांच नहीं करते हैं, तो परिणाम संभवतः आपके सॉफ़्टवेयर द्वारा स्वीकार किए जा सकते हैं। हालांकि डेवलपर "लेकिन डिक्रिप्ट किए जाने के बाद संशोधित डेटा कचरा के रूप में वापस आ जाएगा" कहेगा, एक अच्छे सुरक्षा इंजीनियर को यह संभावना मिल जाएगी कि कचरा सॉफ्टवेयर में प्रतिकूल व्यवहार का कारण बनता है, और फिर वह उस विश्लेषण को एक वास्तविक हमले में बदल देगा। मैंने ऐसे कई मामले देखे हैं जहां एन्क्रिप्शन का उपयोग किया गया था लेकिन संदेश की अखंडता एन्क्रिप्शन की तुलना में वास्तव में अधिक आवश्यक थी। समझें कि आपको क्या चाहिए।

मुझे यह कहना चाहिए कि यद्यपि जीसीएम में एन्क्रिप्शन और संदेश अखंडता दोनों हैं, यह एक बहुत ही नाजुक डिजाइन है: यदि आप एक आईवी का फिर से उपयोग करते हैं, तो आप खराब हो जाते हैं - हमलावर आपकी कुंजी को पुनर्प्राप्त कर सकता है। अन्य डिज़ाइन कम नाजुक हैं, इसलिए मैं व्यक्तिगत रूप से खराब एन्क्रिप्शन कोड की मात्रा के आधार पर GCM की सिफारिश करने से डरता हूं जो मैंने व्यवहार में देखा है।

यदि आपको संदेश, अखंडता और एन्क्रिप्शन दोनों की आवश्यकता है, तो आप दो एल्गोरिदम को जोड़ सकते हैं: आमतौर पर हम सीबीसी को एचएमएसी के साथ देखते हैं, लेकिन खुद को सीबीसी से जोड़ने का कोई कारण नहीं है। जानना जरूरी हैपहले एन्क्रिप्टेड है, फिर एन्क्रिप्टेड सामग्री को मैक , आसपास के अन्य तरीके से नहीं। साथ ही, IV को मैक गणना का हिस्सा होना चाहिए।

मुझे आईपी मुद्दों की जानकारी नहीं है।

अब प्रोफेसर रोगवे से अच्छे सामान के लिए:

ब्लॉक सिफर मोड, एन्क्रिप्शन लेकिन संदेश अखंडता नहीं

ECB : एक अवरोधक, मोड उन संदेशों को अलग करता है जो प्रत्येक n-bit के टुकड़े को अलग-अलग करके कई n बिट्स होते हैं। सुरक्षा गुण कमजोर हैं , विधि दोनों ब्लॉक पदों और समय पर ब्लॉक की समानता लीक कर रही है। काफी विरासत मूल्य, और अन्य योजनाओं के लिए बिल्डिंग ब्लॉक के रूप में मूल्य की, लेकिन मोड अपने आप में किसी भी आम तौर पर वांछनीय सुरक्षा लक्ष्य को प्राप्त नहीं करता है और इसका उपयोग काफी सावधानी से किया जाना चाहिए; ईसीबी को "सामान्य-उद्देश्य" गोपनीयता मोड के रूप में नहीं माना जाना चाहिए

सीबीसी : एक IV- आधारित एन्क्रिप्शन योजना, मोड एक संभाव्य एन्क्रिप्शन एन्क्रिप्शन योजना के रूप में सुरक्षित है, यादृच्छिक बिट्स से अविभाज्यता प्राप्त करता है, एक यादृच्छिक IV मानता है। यदि चतुर्थ केवल एक गैर है , तो गोपनीयता हासिल नहीं की जाती है , और न ही यह योजना के द्वारा उपयोग की जाने वाली कुंजी के तहत एक गैर-परिचित है, जैसा कि मानक गलत तरीके से करने का सुझाव देता है। सिफरटेक्स्ट अत्यधिक निंदनीय हैं। कोई चुना हुआ सिफरटेक्स्ट अटैक (CCA) सुरक्षा नहीं। कई गद्दी विधियों के लिए एक सही-गद्दी की स्थिति की उपस्थिति में गोपनीयता को जब्त किया जाता है। स्वाभाविक रूप से धारावाहिक होने से अक्षम अक्षमता। व्यापक रूप से उपयोग किया जाता है, मोड की गोपनीयता-केवल सुरक्षा गुणों के परिणामस्वरूप अक्सर दुरुपयोग होता है। CBC-MAC एल्गोरिदम के लिए बिल्डिंग ब्लॉक के रूप में इस्तेमाल किया जा सकता है। मैं सीटीआर मोड पर कोई महत्वपूर्ण लाभ की पहचान नहीं कर सकता।

सीएफबी : एक आईवी-आधारित एन्क्रिप्शन योजना, मोड एक संभाव्य एन्क्रिप्शन एन्क्रिप्शन योजना के रूप में सुरक्षित है, यादृच्छिक बिट्स से अविभाज्यता प्राप्त करते हुए, एक यादृच्छिक IV मानती है। यदि IV की भविष्यवाणी की जाती है , तो गोपनीयता हासिल नहीं की जाती है , और न ही यह योजना द्वारा उपयोग की गई कुंजी के तहत एक गैर-प्रवर्धित व्यक्ति द्वारा बनाई गई है, जैसा कि मानक गलत तरीके से करने का सुझाव देता है। सिफरटेक्ट्स निंदनीय हैं। कोई सीसीए-सुरक्षा नहीं। स्वाभाविक रूप से धारावाहिक होने से अक्षम अक्षमता। योजना एक पैरामीटर s, 1 ≤ s, n पर निर्भर करती है, आमतौर पर s = 1 या s = 8. केवल एक बिट्स को संसाधित करने के लिए एक अवरोधक कॉल की आवश्यकता के लिए अक्षम। मोड एक दिलचस्प "आत्म-सिंक्रनाइज़ेशन" संपत्ति प्राप्त करता है; किसी भी संख्या में s-bit वर्णों के सम्मिलन या विलोपन से केवल अस्थायी रूप से सही डिक्रिप्शन बाधित होता है।

ओएफबी : एक आईवी-आधारित एन्क्रिप्शन स्कीम, मोड एक संभाव्य एन्क्रिप्शन एन्क्रिप्शन योजना के रूप में सुरक्षित है, यादृच्छिक बिट्स से अविभाज्यता प्राप्त करता है, एक यादृच्छिक आईवी मान लेता है। यदि IV एक गैर है, तो गोपनीयता हासिल नहीं की जाती है, हालांकि IVs का एक निश्चित अनुक्रम (जैसे, एक काउंटर) ठीक काम करता है। सिफरटेक्स्ट अत्यधिक निंदनीय हैं। कोई CCA सुरक्षा नहीं। एन्क्रिप्शन और डिक्रिप्शन स्वाभाविक रूप से धारावाहिक होने से अक्षम है। मूल रूप से किसी भी बिट की लंबाई (कोई पैडिंग की आवश्यकता है) के तारों का प्रयास करता है। मैं सीटीआर मोड पर कोई महत्वपूर्ण लाभ की पहचान नहीं कर सकता।

CTR : एक IV-आधारित एन्क्रिप्शन स्कीम, मोड एक गैर-IV को मानते हुए यादृच्छिक बिट्स से अप्रभेद्यता प्राप्त करता है। सुरक्षित गैर-आधारित योजना के रूप में, मोड को एक यादृच्छिक IV के साथ एक संभाव्य एन्क्रिप्शन एन्क्रिप्शन योजना के रूप में भी इस्तेमाल किया जा सकता है। एन्क्रिप्शन या डिक्रिप्शन पर यदि कोई नॉन का पुन: उपयोग होता है तो गोपनीयता की पूर्ण विफलता। मोड की समांतरता अक्सर इसे अन्य गोपनीयता मोड की तुलना में, कुछ सेटिंग्स में अधिक तेज़ बनाती है। प्रमाणित-एन्क्रिप्शन योजनाओं के लिए एक महत्वपूर्ण बिल्डिंग ब्लॉक। कुल मिलाकर, आमतौर पर गोपनीयता-केवल एन्क्रिप्शन प्राप्त करने का सबसे अच्छा और सबसे आधुनिक तरीका है।

XTS : एक IV- आधारित एन्क्रिप्शन स्कीम, मोड प्रत्येक n-बिट चंक के लिए एक tweakable blockcipher (एक मजबूत-पीआरपी के रूप में सुरक्षित) को लागू करके काम करता है। उन संदेशों के लिए जिनकी लंबाई n से विभाज्य नहीं है, अंतिम दो ब्लॉक विशेष रूप से व्यवहार किए जाते हैं। मोड का एकमात्र अनुमत उपयोग ब्लॉक-स्ट्रक्चर्ड स्टोरेज डिवाइस पर डेटा एन्क्रिप्ट करने के लिए है। अंतर्निहित पीआरपी की संकीर्ण चौड़ाई और आंशिक अंतिम ब्लॉकों के खराब उपचार समस्याएं हैं। एक विस्तृत (विस्तृत-ब्लॉक) पीआरपी-सुरक्षित अवरोधक की तुलना में अधिक कुशल लेकिन कम वांछनीय होगा।

एमएसीएस (संदेश अखंडता लेकिन एन्क्रिप्शन नहीं)

ALG1–6 : एमएसीएस का एक संग्रह, ये सभी सीबीसी-मैक पर आधारित हैं। बहुत सारी योजनाएँ। कुछ सिद्ध रूप से VIL PRFs के रूप में सुरक्षित हैं, कुछ FIL PRFs के रूप में, और कुछ के पास कोई सुरक्षा योग्य नहीं है। कुछ योजनाएं हानिकारक हमलों को स्वीकार करती हैं। कुछ विधाएँ दिनांकित हैं। कुंजी-पृथक्करण अपर्याप्त रूप से उन मोड के लिए भाग लिया जाता है जो इसके पास हैं। एन मास्स को नहीं अपनाया जाना चाहिए, लेकिन चुनिंदा रूप से "सर्वश्रेष्ठ" योजनाओं को चुनना संभव है। सीएमएसी के पक्ष में इनमें से कोई भी तरीका अपनाना भी ठीक रहेगा। आईएसओ 9797-1 एमएसीएस में से कुछ व्यापक रूप से मानकीकृत और उपयोग किए जाते हैं, खासकर बैंकिंग में। मानक का एक संशोधित संस्करण (आईएसओ / आईईसी एफडीआईएस 9797-1: 2010) जल्द ही जारी किया जाएगा [93]।

सीएमएसी : सीबीसी-मैक पर आधारित एक मैक, मोड (जन्मदिन की सीमा तक) सुरक्षित रूप से सुरक्षित है (वीआईएल) पीआरएफ (अंतर्निहित अवरोधक मानकर एक अच्छा पीआरपी है)। CBCMAC- आधारित योजना के लिए अनिवार्य रूप से न्यूनतम ओवरहेड। स्वाभाविक रूप से धारावाहिक प्रकृति कुछ अनुप्रयोग डोमेन में एक समस्या है, और 64-बिट अवरोधक के साथ उपयोग कभी-कभार पुन: कुंजीकरण की आवश्यकता होगी। एमएसीएस के आईएसओ 9797-1 संग्रह की तुलना में क्लीनर।

एचएमएसी : एक मैक एक अवरोधक हैश के बजाय एक क्रिप्टोग्राफिक हैश फ़ंक्शन पर आधारित है (हालांकि अधिकांश क्रिप्टोग्राफ़िक हैश फ़ंक्शन स्वयं ब्लॉकर्स पर आधारित हैं)। तंत्र मजबूत साबित-सुरक्षा सीमा का आनंद लेता है, यद्यपि पसंदीदा मान्यताओं से नहीं। साहित्य में कई निकटता से संबंधित वेरिएंट को ज्ञात होने की समझ पाने में कठिनाई होती है। किसी भी तरह के नुकसानदेह हमलों का सुझाव नहीं दिया गया है। व्यापक रूप से मानकीकृत और उपयोग किया जाता है।

GMAC : एक गैर-आधारित मैक जो GCM का एक विशेष मामला है। जीसीएम की कई अच्छी और बुरी विशेषताओं की पुष्टि करता है। लेकिन गैर-आवश्यकता एक मैक के लिए अनावश्यक है, और यहां यह थोड़ा लाभ खरीदता है। यदि ≤ 64 बिट्स पर टैग्स को छोटा किया जाता है और डिक्रिप्शन की सीमा पर निगरानी नहीं की जाती है, तो प्रैक्टिकल हमले। गैर-पुन: उपयोग पर पूर्ण विफलता। वैसे भी अगर जीसीएम को अपनाया जाता है तो उपयोग निहित है। अलग मानकीकरण के लिए अनुशंसित नहीं है।

प्रमाणित एन्क्रिप्शन (एन्क्रिप्शन और संदेश अखंडता दोनों)

CCM : एक गैर-आधारित AEAD योजना जो CTR मोड एन्क्रिप्शन और कच्चे CBC-MAC को जोड़ती है। स्वाभाविक रूप से धारावाहिक, कुछ संदर्भों में गति को सीमित करता है। अच्छी तरह से सुरक्षित, अच्छी सीमा के साथ, अंतर्निहित अवरोधक को संभालने के लिए एक अच्छा पीआरपी है। Ungainly निर्माण कि demonstrably काम करता है। जीसीएम की तुलना में लागू करने के लिए सरल। एक गैर-आधारित मैक के रूप में इस्तेमाल किया जा सकता है। व्यापक रूप से मानकीकृत और उपयोग किया जाता है।

GCM : एक गैर-आधारित AEAD योजना जो CTR मोड एन्क्रिप्शन और एक GF (2128) आधारित सार्वभौमिक हैश फ़ंक्शन को जोड़ती है। कुछ कार्यान्वयन वातावरण के लिए अच्छी दक्षता विशेषताएँ। कम से कम टैग ट्रंकेशन मानने वाले अच्छे-सुरक्षित परिणाम। पर्याप्त टैग ट्रंकेशन की उपस्थिति में हमलों और खराब साबित-सुरक्षा सीमा। एक गैर-आधारित मैक के रूप में इस्तेमाल किया जा सकता है, जिसे तब GMAC कहा जाता है। 96-बिट्स के अलावा अन्य गैर-अनुमति देने के लिए संदिग्ध विकल्प। नॉनवेज को 96-बिट्स और टैग को कम से कम 96 बिट्स तक सीमित रखने की सलाह देते हैं। व्यापक रूप से मानकीकृत और उपयोग किया जाता है।


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

3
CTR मोड: मैं CTR मोड से असहमत हूं, क्योंकि अभ्यास में बहुत सारी असफलता के कारण, मुख्य रूप से IV पुन: उपयोग। यहां तक ​​कि माइक्रोसॉफ्ट ने भी कम से कम एक दो बार इसे खराब कर दिया है।
ज़ाफ

1
सीबीसी मोड: संभवतः एसओ, ईसीबी (जिसका उपयोग नहीं किया जाना चाहिए) को छोड़कर सबसे आम मोड और सबसे अधिक इस्तेमाल किया जाने वाला मोड है। प्रमुख उपयोग दोष एक गैर-यादृच्छिक IV हैं लेकिन हम CSPRNG के साथ अधिक सही उपयोग देख रहे हैं। पैडिंग ऑरेकल, जबकि एक मुद्दा, केवल आसानी से अनदेखा कर दिया जाता है और पैडिंग त्रुटियों को वापस नहीं किया जाता है। कुछ कार्यान्वयन (जैसे कॉमन क्रिप्टो) एपीआई स्तर पर उनसे बचने के अनिवार्य रूप से सफल तरीके से पैडिंग त्रुटियों की रिपोर्ट नहीं करते हैं।
ज़ाफ़

1
IMO CTR बदतर है क्योंकि यह एक साधारण xor है जहाँ CBC में ब्लॉक से ब्लॉक के रूप में कई अन्य मोड में प्रचार है। यह आसान लग सकता है लेकिन बड़े पैमाने पर बाजार कोड में बड़ी विफलताएं हुई हैं।
ज़ाफ

1
लिंक किए गए पेपर को पढ़ने से ऐसा लगता है कि केवल प्रमाणीकरण कुंजी प्राप्त की गई है, न कि पुन: उपयोग से एन्क्रिप्शन कुंजी। ऐसा लगता नहीं है कि यहां टिप्पणियों में दावा किया गया है कि एन्क्रिप्शन कुंजी प्राप्त की गई है। प्रमाणीकरण कुंजी प्राप्त करते समय संदेश के साथ छेड़छाड़ की अनुमति देता है यह संदेश को पुनर्प्राप्त करने की अनुमति नहीं देता है। कृपया इंगित करें कि मैं कहां गलत हो सकता हूं।
ज़ाफ

30
  1. कुछ भी हो लेकिन ई.सी.बी.
  2. CTR का उपयोग करते समय, यह जरूरी है कि आप प्रत्येक संदेश के लिए एक अलग IV का उपयोग करें, अन्यथा आप हमलावर को दो सिफरटेक्स लेने में सक्षम होते हैं और एक संयुक्त अनएन्क्रिप्टेड प्लेनटेक्स्ट प्राप्त करते हैं। कारण यह है कि सीटीआर मोड अनिवार्य रूप से एक ब्लॉक सिफर को एक धारा सिफर में बदल देता है, और धारा सिफर का पहला नियम कभी भी एक ही कुंजी + IV का दो बार उपयोग नहीं करना है।
  3. वास्तव में इतना अंतर नहीं है कि मोड को लागू करना कितना मुश्किल है। कुछ मोडों को केवल एन्क्रिप्ट की दिशा में काम करने के लिए ब्लॉक सिफर की आवश्यकता होती है। हालाँकि, AES सहित अधिकांश ब्लॉक सिफर, डिक्रिप्शन को लागू करने के लिए अधिक कोड नहीं लेते हैं।
  4. सभी सिफर मोड के लिए, प्रत्येक संदेश के लिए अलग-अलग IVs का उपयोग करना महत्वपूर्ण है यदि आपके संदेश पहले कई बाइट्स में समान हो सकते हैं, और आपको यह जानने के लिए एक हमलावर नहीं चाहिए।

: अपने प्वाइंट 1 (+1 कि btw के लिए) का समर्थन करने के codinghorror.com/blog/archives/001267.html
माइकल Stum

1
आपको CTR की शुरुआत एक यादृच्छिक संख्या से नहीं करनी चाहिए, क्योंकि इसमें पिछले संदेश के भाग से टकराने की एक छोटी-सी-बढ़ती संभावना है। इसके बजाय नीरस रूप से वेतन वृद्धि (इसका मतलब यह याद रखना है कि आप लगातार स्टोरेज में कहां हैं), और यदि आप (जब) ​​काउंटर से बाहर निकलते हैं तो फिर से कुंजी लगाएं।
कैफे

@Theran - बिंदु 2 - प्रत्येक संदेश के लिए एक अलग यादृच्छिक संख्या? नहीं, मुझे लगता है कि यह सही नहीं है। मैं इस धारणा के तहत हूं कि हमेशा शून्य पर काउंटर शुरू करना ठीक है। @ कैफ, मुझे लगता है कि जब थेरान "संदेश" कहता है तो उसका मतलब "ब्लॉक" नहीं होता है। बेशक काउंटर एक विशेष संदेश के प्रत्येक ब्लॉक के लिए बढ़ जाता है जो सिफर के माध्यम से चलता है। थेरान जो कह रही है ऐसा लगता है कि प्रत्येक संदेश को काउंटर के लिए एक अलग प्रारंभिक मूल्य के साथ शुरू करना चाहिए। और मुझे लगता है कि यह सही नहीं है।
चेसो

1
पुन: बिंदु 3 - मैंने ऐसे कागज पढ़े हैं जो कहते हैं, उदाहरण के लिए, CTR मोड को लागू करने के लिए छोटा है क्योंकि डिक्रिप्ट एन्क्रिप्ट के रूप में एक ही रूपांतर है। इसलिए आधा कोड। लेकिन जैसा कि मैं कहता हूं, सर्वर-क्लास मशीन पर प्रासंगिक नहीं है।
चेसो

हां, मुझे याद आ रहा है। यह IV / nonce है जिसे CTR मोड के लिए बदलना चाहिए, लेकिन यह एन्क्रिप्ट करने से पहले काउंटर के साथ संयुक्त हो जाता है, इसलिए मैं इसे काउंटर के लिए एक यादृच्छिक प्रारंभिक बिंदु के रूप में सोचता हूं। जहां तक ​​केवल एन्क्रिप्ट करने की दिशा में सिफर का उपयोग करने की जगह की बचत है, तो कई सिफर के लिए आपको केवल उपकुंजियों को डिक्रिप्ट करने के लिए रिवर्स करना होगा। एईएस डिक्रिप्टिंग के लिए थोड़ा भारी है, लेकिन यह ऐसा नहीं है कि आप इसे यूसी पर रैम बाइट्स के 128 बाइट्स के साथ लागू कर सकते हैं। उपकुंजियों की तुलना में अधिक रैम लेते हैं!
थेरान

13

क्या आपने विकिपीडिया पर इस जानकारी को पढ़ने से शुरू किया है - ऑपरेशन के सिफर मोड ? फिर विकिपीडिया पर NIST के संदर्भ लिंक का अनुसरण करें : ऑपरेशन के ब्लॉक सिफर मोड्स के लिए सिफारिश


6
यह उत्तर स्टैकेवरफ्लो के गुणवत्ता मानकों को पूरा नहीं करता है: कृपया मान लें, आपके उत्तर में, कि सभी बाहरी लिंक मृत हो गए होंगे, और संक्षेप में बताएंगे - यदि एकमुश्त प्रतिलिपि नहीं - प्रासंगिक जानकारी, मूल रूप से मूल प्रश्न का उत्तर देने के लिए डिज़ाइन किए गए तरीके से।
मीराबिलोस

5
@mirabilos लगभग 5 साल बाद उन मानदंडों और मानकों का जिक्र करता है जो उस समय मौजूद नहीं थे, वास्तव में? मुझे विशेष रूप से मृत लिंक के बारे में बात करना पसंद है, जब दोनों यहां वास्तव में अभी भी बहुत जीवित हैं, और प्रश्न में साइट को दिए जाने के लिए एक और 5 साल तक बने रहने की संभावना है। ओह अच्छा।
KTC

3
@mirabilos आप यकीनन सही आ सकते हैं , लेकिन 5 साल पहले किए गए एक जवाब के खिलाफ आपकी शिकायत जहां मानदंड अलग थे, वह लागू नहीं है। आपको बस अपनी गलती माननी चाहिए थी। यहां तक ​​कि अगर यह मामला नहीं है और आप इसके बजाय यह आरोप लगा रहे हैं कि इसे अद्यतन या परिवर्तित किया जाना चाहिए, यह अभी भी अनिवार्य नहीं है। जवाब यह था कि यह कैसे हुआ।
konsolebox

@KTC को छोड़कर जब सरकार बंद हो जाती है और साइट ऑफ़लाइन हो जाती है। आपका उत्तर उपयोगी जानकारी हो सकता था, लेकिन फिलहाल पूरी तरह से गायब है। इस सवाल के पाठक और इसका उत्तर अभी भी दोनों को आश्चर्यचकित करता है कि 2014 में क्या अपडेट किया गया था (एक अपूर्ण उत्तर के कारण) और वर्तमान स्थिति (एनआईएसटी वेबसाइट के एक सरकारी शटडाउन के कारण)। हालाँकि, लापता जानकारी को जोड़ना मुझे अच्छा लगेगा ...
G DeMasters

11

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

हार्डवेयर सीमाएँ

STM32L (low energy ARM cores) from ST Micro support ECB, CBC,CTR GCM
CC2541 (Bluetooth Low Energy) from TI supports ECB, CBC, CFB, OFB, CTR, and CBC-MAC

स्रोत सीमाएँ खोलें

Original rijndael-api source  - ECB, CBC, CFB1
OpenSSL - command line CBC, CFB, CFB1, CFB8, ECB, OFB
OpenSSL - C/C++ API    CBC, CFB, CFB1, CFB8, ECB, OFB and CTR
EFAES lib [1] - ECB, CBC, PCBC, OFB, CFB, CRT ([sic] CTR mispelled)  
OpenAES [2] - ECB, CBC 

[१] http://www.codeproject.com/Articles/57478/A-Fast-and-Easy-to-Use-AES-Library

[२] https://openaes.googlecode.com/files/OpenAES-0.8.0.zip


1
एसटी माइक्रो: ईबीसी ईसीबी होना चाहिए; FYI करें: जैसे STM32L4A6 ECB, CBC, CTR, GCM के साथ 128-बिट और 256-बिट AES को सपोर्ट करता है, साथ ही Galois के मैसेज ऑथेंटिकेशन कोड (GMAC) या सिफर मैसेज सर्टिफिकेशन कोड मोड CMAC लाइनिंग एल्गोरिदम को भी हार्डवेयर द्वारा सपोर्ट किया जाता है।
टॉम कुशेल

-3

मुझे एक पहलू पता है: हालांकि सीबीसी प्रत्येक ब्लॉक के लिए IV बदलकर बेहतर सुरक्षा देता है, यह बेतरतीब ढंग से एक्सेस की गई एन्क्रिप्टेड सामग्री (जैसे एन्क्रिप्टेड हार्ड डिस्क) पर लागू नहीं होता है।

इसलिए, यादृच्छिक पहुंच के लिए अनुक्रमिक धाराओं और ईसीबी के लिए सीबीसी (और अन्य अनुक्रमिक मोड) का उपयोग करें।


आह, ठीक है, बिल्कुल। CBC X एन्क्रिप्शन से पहले प्लेनटेक्स्ट ब्लॉक के साथ पूर्व सिफरटेक्स्ट ब्लॉक को XOR करता है। पहला ब्लॉक IV का उपयोग करता है। तो किसी भी ब्लॉक को डिक्रिप्ट करने के लिए, आपको सभी पूर्व ब्लॉक को सफलतापूर्वक डिक्रिप्ट करना होगा। ठीक है, यह एक अच्छी अंतर्दृष्टि है।
चेसो

6
नहीं, आपको केवल पूर्व सिफरटेक्स्ट का उपयोग करना होगा , जिसे किसी भी पिछले ब्लॉक को डिक्रिप्ट करने की आवश्यकता नहीं है।
कैफे

आह, अच्छी तरह से इसका मतलब है कि सीबीसी यादृच्छिक अभिगम के साथ ठीक है, है ना?
चीजो

4
@ चेहेसो: सीबीसी यादृच्छिक रीड एक्सेस के लिए ठीक है, लेकिन रैंडम राइट एक्सेस के लिए नहीं। वहां सीटीआर का उपयोग करें।
पाओलो एबरमन

3
@ Pa @loEbermann यादृच्छिक अभिगम के लिए सीटीआर एक अच्छा विचार नहीं है, क्योंकि यह गंभीर हमलों की अनुमति देता है अगर कोई हमलावर सिफरटेक्स्ट के दो संस्करणों को देखता है। इसके बजाय XTS या एक ट्विकेबल ब्लॉकपीशर का उपयोग करें।
कोडइन्चोस
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.