एंड्रॉइड, एईएस-जीसीएम या सादे एईएस पर डेटा एन्क्रिप्शन?

Question

मेरी टीम को जावा में लिखे गए एंड्रॉइड एप्लिकेशन के संदर्भ में द्विआधारी डेटा (byte[] के रूप में संग्रहीत) को एन्क्रिप्ट करने के लिए एक समाधान विकसित करने की आवश्यकता है। एन्क्रिप्टेड डेटा प्रसारित और विभिन्न तरीकों से संग्रहीत किया जाएगा, जिसके दौरान डेटा भ्रष्टाचार से इनकार नहीं किया जा सकता है। आखिर में एक और एंड्रॉइड एप्लिकेशन (जावा में फिर से लिखा गया) को डेटा को डिक्रिप्ट करना होगा।

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

यहाँ चिंताओं/आवश्यकताओं/प्रश्नों की एक सूची है हमने:

• पैडिंग: डेटा हम एन्क्रिप्ट करने के लिए हमेशा 128 बिट्स की एक बहु नहीं होगा की जरूरत है, तो एईएस कार्यान्वयन/मोड पैडिंग जोड़ना चाहिए, फिर भी जब आवश्यक हो। मैं इस धारणा के तहत था कि एक सादा एईएस कार्यान्वयन, जैसे javax.crypto.Cipher द्वारा प्रदान किया गया, ऐसा नहीं करेगा, लेकिन प्रारंभिक परीक्षणों से संकेत मिलता है कि यह करता है। तो मैं अपने आप में पैडिंग आवश्यकता का अनुमान लगा रहा हूं कि "सादा" एईएस की बजाय जीसीएम जैसे कुछ का सहारा लेने का कोई कारण नहीं है। क्या वो सही है?

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

• ओवरहेड को कम करें: हमें एन्क्रिप्टेड डेटा के संग्रहण और संचरण पर ओवरहेड सीमित करने की आवश्यकता है। इसलिए हम जानना चाहते हैं कि, और किस हद तक, एक विशिष्ट एईएस कार्यान्वयन/मोड के लिए विकल्प ओवरहेड की मात्रा को प्रभावित करता है।

• एन्क्रिप्शन/डिक्रिप्शन प्रदर्शन: यद्यपि यह एक प्राथमिक चिंता का विषय है कि हम करने के लिए सोच रहे हैं नहीं है किस हद तक एक विशिष्ट एईएस कार्यान्वयन/मोड को प्रभावित करती है एन्क्रिप्शन और डिक्रिप्शन प्रदर्शन की पसंद, दोनों CPU समय और स्मृति पदचिह्न के संदर्भ में।

किसी भी सलाह, स्पष्टीकरण और/या कोड उदाहरणों के लिए अग्रिम धन्यवाद।

संपादित करें: डेलन ने मदद से बताया कि "सादे एईएस" जैसी कोई चीज़ नहीं है। तो स्पष्टीकरण के लिए, इसका मतलब जावा के अंतर्निहित एईएस समर्थन का उपयोग कर रहा है।
इस तरह: Cipher localCipher = Cipher.getInstance("AES");

Answer 1

2012 में उत्तर जीसीएम के लिए जाना है, जब तक कि आपके पास गंभीर संगतता समस्या न हो।

GCMप्रमाणीकृत एन्क्रिप्शन मोड है। यह आपको एक ही समय में गोपनीयता (एन्क्रिप्शन), अखंडता, और प्रमाणीकरण (मैक) प्रदान करता है।

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

प्रमाणीकृत एन्क्रिप्शन मोड (काफी हाल ही में) क्रिप्टोग्राफ़रों द्वारा उस समस्या को हल करने के लिए बनाए गए हैं। जीसीएम सबसे सफल है: इसे NIST द्वारा चुना गया है, यह कुशल है, यह पेटेंट मुक्त है, और इसमें अतिरिक्त प्रमाणीकृत डेटा (यानी, डेटा जो स्पष्ट में रहता है, लेकिन जिसके लिए आप सत्यापित कर सकते हैं प्रामाणिकता)। अन्य मोड के विवरण के लिए this excellent article of Matthew Green देखें।

अपनी समस्याओं से आ रहा है:

• पैडिंग: डिफ़ॉल्ट रूप से, जावा 7 गद्दी का उपयोग करता है PKCS #। यह काम करता है, लेकिन यह अक्सर padding oracle attacks के लिए कमजोर होता है जो MAC के साथ सबसे अच्छा हराया जाता है। जीसीएम पहले से ही एक मैक एम्बेड करता है (जीएमएसी कहा जाता है)।

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

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

• प्रदर्शन: GCM में यह एक ऑनलाइन विधा है कि (कोई पूरे पेलोड है, तो कम स्मृति बफ़र की जरूरत) बहुत अच्छा है, यह में चलाने योग्य है, और यह एक एईएस संचालन और एक गाल्वा गुणा की आवश्यकता है प्रति सादे पाठ ब्लॉक। ईसीबी जैसे क्लासिक मोड तेज हैं (केवल एक ब्लॉक प्रति एईएस ऑपरेशन), लेकिन - फिर से - आपको अखंडता तर्क में भी कारक होना चाहिए, जो जीएमएसी की तुलना में धीमी गति से समाप्त हो सकता है।

यह कहकर, एक को पता होना चाहिए कि जीसीएम सुरक्षा IV के निर्माण के लिए एक अच्छी यादृच्छिक संख्या पीढ़ी पर निर्भर करती है।