सिंपल डेटा स्क्रैचिंग एल्गोरिदम

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

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

आवश्यक शर्तें

यह माना जाता है कि संभावित क्रैकर या तो कोड का उपयोग नहीं करता है जो एन्क्रिप्शन को निष्पादित करता है, या रिवर्स इंजीनियरिंग के लिए पर्याप्त योग्यता नहीं है, या डेटा इतना मूल्यवान नहीं है जितना अधिक कठिन क्रैकिंग विधियों पर समय बिताना है।

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

और यदि आप एक कुंजी उत्पन्न करते हैं?

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

लेकिन क्या होगा अगर आप इस छद्म यादृच्छिक अनुक्रम को उत्पन्न करने के लिए डेटा का उपयोग करते हैं?

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

इनपुट-निर्भर कुंजी जेनरेटर उदाहरण

इसे स्पष्ट करने के लिए, इस तरह के एक एल्गोरिथ्म का एक सरल उदाहरण पर विचार करें।
स्रोत डेटा में x _n अगला कोड हो, k _n वर्तमान कुंजी हो, k _{n + 1} अगला कुंजी मान हो, y _एन एन्क्रिप्टेड कोड x _{n हो} ।
क्यू (ए, बी) एक निश्चित सराहनीय कार्य है, अर्थात ऐसे कि q (a, b) == q (b, a)।
एफ (ए, बी, सी) एक निश्चित पूर्णांक फ़ंक्शन है।
फिर (डी) कोडिंग पर चलना इस प्रकार वर्णित किया जा सकता है:
y _n : = x _n xor k _n ;
k _{n + 1} : = F (k _n , Q (x _n , y _n ), n);
यदि फ़ंक्शन F () के लिए यह स्पष्ट है कि इसका कार्यान्वयन आम तौर पर केवल हमारी कल्पना और सामान्य ज्ञान से सीमित है, तो Q () के बारे में, आप संभवतः विवरण देखना चाहते हैं, अर्थात्, यह किन शर्तों को पूरा करने के लिए आवश्यक है। इसे प्राप्त करने का सबसे आसान तरीका है कि कम्यूटेटिव ऑपरेशंस में जोड़े में केवल तर्कों का उपयोग करना है, उदाहरण के लिए एक्सोर, जोड़, गुणा। उदाहरण:
क्यू (ए, बी) = एक एक्सोर बी । ( फिक्स्ड: शायद मैं यहां उत्साहित हो गया, क्योंकि जब आप स्रोत और एन्क्रिप्टेड कोड को ओवरले करते हैं, तो एक कुंजी प्राप्त की जाती है, जो अवांछनीय है। मैं व्यक्तिगत रूप से थोड़े अधिक जटिल कार्यों का उपयोग करता हूं)।
क्यू (ए, बी) = ((एक एक्सोर बी) या 1) * ((ए + बी) एक्सर 1)।
जैसा कि आप देख सकते हैं, अपने सुपर-डुपर फ़ंक्शन Q () के साथ आना बिल्कुल भी मुश्किल नहीं है। एक और बात, क्या इसे जटिल बनाना आवश्यक है? मुझे लगता है कि इसकी पुन: जटिलता में कोई विशेष अर्थ नहीं है।

अच्छा, अब बुरा क्या है?

हां, एन्कोडिंग फ़ंक्शन के कोड को जानने के बिना, कुछ पढ़ना बहुत मुश्किल होगा। लेकिन क्या सुराग अभी भी बने हुए हैं? यदि स्क्रैंबलर के लिए इनपुट पैरामीटर समान हैं, तो

1. यदि दो संदेश एक ही डेटा से शुरू होते हैं, तो एन्क्रिप्टेड डेटा की शुरुआत बिल्कुल उसी तरह होगी;
2. पहले कोड की कुंजी समान है;
3. एन्क्रिप्ट किए गए संदेश की लंबाई मूल संदेश की लंबाई से बिल्कुल मेल खाती है।

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

क्या आपके पास कोई अन्य विचार है?

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

डेटा शफलर

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

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

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

अब जनरेटर पैरामीटर x _{n + 1} = (a * x _n + c) mod m : के मानदंड के बारे में

1. c और m कोप्रेम हैं;
2. a - 1, m के सभी प्रधान विभाजकों के लिए p का एक गुणक है;
3. a - 1 का गुणज 4 होना चाहिए यदि m 4 का गुणक है।

थोड़ा रक्त के साथ इसे कैसे प्राप्त करें? मैं इस विकल्प का सुझाव देता हूं:
m = 2 ⁿ , जहां n> 3;
c = p, p एक अभाज्य संख्या है और p> 2;
a = 4 * k + 1।
यह नोटिस करना आसान है कि सभी तीन शर्तें पूरी हो गई हैं और ऐसे मानों का चयन करना काफी आसान है।

कोई और विचार?

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

मुझे लगता है कि आज के लिए इतना ही काफी है।

सुधार: एक धब्बेदार बग को ठीक किया और एक असफल उदाहरण को पार किया।