Anubis एन्क्रिप्शन एल्गोरिथ्म PHP में

हैबर पर क्रिप्टोग्राफी के एक अजीब सप्ताह को जारी रखते हुए, मैंने PHP में एनबिस एन्क्रिप्शन एल्गोरिथ्म के अपने कार्यान्वयन को साझा करने का निर्णय लिया। Anubis एक ब्लॉक एन्क्रिप्शन एल्गोरिथ्म है, जो वास्तव में, Rijndael एल्गोरिथ्म का एक संशोधन है, जिसे संयुक्त राज्य अमेरिका में एन्क्रिप्शन मानक के रूप में अपनाया गया है। सिफर्स विन्सेन्ट रेमैन हैं, जो रिजंडेल और पाउलो एस। एल। एम। बैरेटो के डेवलपर्स में से एक हैं, जो एक प्रसिद्ध क्रिप्टोग्राफर हैं, जो व्हर्लपूल हैश फ़ंक्शन के डेवलपर्स में से एक है।

मैंने अनुबिस क्यों चुना? यह एक मालिकाना एल्गोरिथ्म नहीं है जो मुफ्त उपयोग के लिए उपलब्ध है। एबिस आधुनिक सुरक्षा आवश्यकताओं को पूरा करता है - ब्लॉक का आकार एईएस, 128 बिट्स की तरह है, और कुंजी की लंबाई 128 से 320 बिट्स तक भिन्न हो सकती है। इसके अलावा, 2000 में इसके प्रकाशन के बाद से, Anubis एल्गोरिथ्म में कोई कमजोरियां नहीं हुई हैं। वह NESSIE परियोजना में नहीं आए , बल्कि केवल रिजिन्देल के साथ उनकी समानता के कारण।

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

class Anubis { /* Properties */ string $key //,  string $KDF_salt //     string $KDF_algo //-     int $file_blocksize //     /* Methods */ string function encrypt($data) //  string function decrypt($data) //  void function encryptFile($src, $dest) //  void function decryptFile($src, $dest) //  void function setKey($key, $raw_key = false) //  } 

Anubis::setKey($key, $raw_key = false) , जैसा कि इसके नाम का अर्थ है, कुंजी सेट करने के लिए उपयोग की जाती है। मेरे कार्यान्वयन में, मैंने एक साधारण पाठ कुंजी का उपयोग करने की संभावना के लिए प्रदान किया (उदाहरण के लिए, "VeryStrongPassword" ), और थोड़ा स्ट्रिंग निर्दिष्ट करने की क्षमता (उदाहरण: hex2bin('575a42654a85020b4f6eaeff03aecb0e') )। कुंजी के रूप में बिट स्ट्रिंग का उपयोग करने के लिए, पैरामीटर $raw_key ।

यदि हम एक कुंजी के लिए एक बिट स्ट्रिंग का उपयोग करते हैं, तो हम प्रत्येक बिट की सामग्री और उसकी लंबाई (32-बिट वेतन वृद्धि में 128 से 320 बिट तक) को नियंत्रित करते हैं, लेकिन हम इसकी शुद्धता का भी ध्यान रखते हैं। विशेष रूप से, यदि कुंजी बहुत लंबी है, बहुत छोटी है, या 32 बिट्स से अधिक नहीं है, तो Anubis::setKey() विधि अपवाद को फेंक देगी। यदि हम एक सरल पाठ कुंजी का उपयोग करते हैं, तो एन्क्रिप्शन से पहले इसे प्रमुख आउटपुट फ़ंक्शन द्वारा बदल दिया जाएगा (साहित्य में कोई भी ऐसे अनुवाद को "प्रमुख पीढ़ी फ़ंक्शन" या "कुंजी पीस फ़ंक्शन" के रूप में पा सकता है)।

एक प्रमुख व्युत्पत्ति समारोह के रूप में, मैंने एक नियमित एचएमएसी का उपयोग किया, जिसके पैरामीटर संगत गुणों ( Anubis::KDF_salt , Anubis::KDF_algo ) द्वारा निर्धारित किए गए हैं। डिफ़ॉल्ट रूप से, 16 शून्य ओकटेट्स की एक स्ट्रिंग "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0" उपयोग नमक के रूप "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0" किया जाता है, और एल्गोरिथ्म की गुणवत्ता SHA-256 है । सिद्धांत रूप में, बिना किसी नमक के नियमित एमडी 5 का उपयोग करना संभव होगा, क्योंकि जब आप कुंजी प्रिंट करते हैं, तो हमें केवल मूल पासवर्ड के प्रतिबंध को नष्ट करने की आवश्यकता होती है, जैसे कि एक अनुपयुक्त लंबाई (128 से कम, 320 से अधिक या 32 बिट्स से अधिक नहीं), वर्णों का एक सीमित सेट (आमतौर पर, a-zA-Z0-9!@#$%^&*(){}[]\/*-+.,?';:~`_"| ) और पाठ की सांख्यिकीय निर्भरता (यदि पासवर्ड पाठ वाक्यांश है); लेकिन मैंने अभी भी विशिष्ट कार्यों के लिए एल्गोरिथ्म को अनुकूलित करने के लिए अधिक जगह छोड़ने का फैसला किया।

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

पाठ कुंजियों का उपयोग करने के बारे में थोड़ा और। जैसा कि मैंने कहा, Anubis सिफर की कुंजी 128-बिट्स (16 बाइट्स) से 320-बिट्स (40 बाइट्स) में 320 बिट्स (40 बाइट्स) तक होनी चाहिए। एक टेक्स्ट कुंजी सौंपी गई है, उदाहरण के लिए, Anubis::key माध्यम से, बहुत बार निर्दिष्ट आकारों में फिट नहीं होगी। सिद्धांत रूप में, कुंजी आउटपुट फ़ंक्शन का उपयोग करते हुए, कोई भी कम से कम प्रतिरोध द्वारा जा सकता है और आकार में सभी कुंजियों को समान रूप से बराबर कर सकता है - या तो उन्हें कम से कम करें, या पैरानॉयड मोड चालू करें और इसके विपरीत, लंबाई को 320 बिट तक बढ़ाएं। लेकिन मैंने इस दृष्टिकोण को गलत माना, क्योंकि अगर मैं अलग-अलग लंबाई की चाबियाँ स्थापित कर सकता हूं, तो तदनुसार मैं उम्मीद कर सकता हूं कि एन्क्रिप्शन प्रणाली विभिन्न लंबाई की कुंजियों का उपयोग करेगी।

नतीजतन, मेरे कार्यान्वयन में, कुंजी, मुख्य आउटपुट फ़ंक्शन द्वारा संसाधित होने के बाद, हमेशा कम से कम संभव लंबाई होगी, लेकिन मूल कुंजी की लंबाई से कम नहीं। यानी यदि, उदाहरण के लिए, मैं कुंजी "010101010101" (12 बाइट्स) दर्ज करता हूं, तो एन्क्रिप्शन के दौरान कुंजी को 16 बाइट्स (128 बिट्स) तक विस्तारित किया जाएगा। यदि मैं "10101010101010101" (17 बाइट्स) दर्ज करता हूं, तो एन्क्रिप्शन में उपयोग की जाने वाली कुंजी पहले से ही 20 बाइट्स (160 बिट्स) लंबी होगी, और इसी तरह।

कुंजी को पहले से ही पर्याप्त कहा गया है, इसलिए अन्य तरीकों के विवरण पर लौटने का समय है।

Anubis::encrypt($data) और Anubis::decrypt($data) विधियों के नाम अपने लिए बोलते हैं। यह स्पष्ट है कि decrypt(encrypt($data)) == $data ।

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

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

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

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

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

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

तरीके Anubis::encryptFile($src, $dest) और Anubis::decryptFile($src, $dest) Anubis::encrypt($data) समान Anubis::decryptFile($src, $dest) Anubis::encrypt($data) और Anubis::decrypt($data) इस अपवाद के साथ कि मूल संदेश यहाँ इसे $src नामक फाइल से पढ़ा जाता है, और परिणाम $dest फाइल पर लिखा जाता है। डेटा चंक्स द्वारा पढ़ा और लिखा जाता है (यहां मैं "ब्लॉक" शब्द से बचता हूं ताकि इसे उस ब्लॉक के साथ न दें जो डेटा को एन्क्रिप्ट करता है), जिसका आकार Anubis::file_blocksize माध्यम से सेट किया जा सकता है Anubis::file_blocksize , यह चयन करते हुए कि फाइल सिस्टम पढ़ता है और रिकॉर्ड्स को जितनी जल्दी हो सके बाहर ले जाया गया, जबकि उचित मात्रा में मेमोरी (चंक को पूरी रैम में पढ़ा जाता है) खर्च किया जाता है। डिफ़ॉल्ट रूप से, चंक का आकार आधा मेगाबाइट पर सेट होता है।

खैर, यहाँ, वास्तव में, पूरा विवरण है। यह केवल उपयोग का एक छोटा सा उदाहरण देने के लिए बना हुआ है:

 <?php require_once 'anubis.class.php'; $src = 'secret_message.txt'; $encrypted = 'encrypted.file'; $decrypted = 'decrypted_message.txt'; $cypher = new Anubis(); $cypher->key = 'strong password'; $cypher->encryptFile($src, $encrypted); $cypher->decryptFile($encrypted, $decrypted); $src_hash = md5_file($src); $decrypted_hash = md5_file($decrypted); echo "Src: $src_hash\n"; echo "Dest: $decrypted_hash\n"; 

अंत में, मैं कहूंगा कि एन्क्रिप्शन इतना तेज़ नहीं था। अधिकतम कुंजी लंबाई के साथ, मेरा सिस्टम लगभग 100 KB / s (लगभग 6400 ब्लॉक प्रति सेकंड) एन्क्रिप्ट कर सकता है, जिसकी न्यूनतम कुंजी लंबाई 150-160 KB / s (लगभग 10,000 ब्लॉक प्रति सेकंड) है। इसलिए अगर किसी के पास एल्गोरिदम के मेरे कार्यान्वयन को अनुकूलित करने के लिए सुझाव हैं (प्रोफाइलर कहता है कि यह सब समय निजी विधि Anubis::crypt() - सीधे एन्क्रिप्शन / डिक्रिप्शन फ़ंक्शन द्वारा खाया जाता है), मैं इसे बहुत बार सुनूंगा।

गिटहब परियोजना रिपॉजिटरी (स्रोत कोड, उदाहरण, विकी): https://github.com/kolonist/php-bubis
Anubis आधिकारिक एल्गोरिथ्म पृष्ठ: http://www.larc.usp.br/~pbarreto/AnubisPage.html