CFB1 व CFB8 व CFB128 मधील फरक फीडबॅक आकार आहे, की आकार नाही
CFB नंतरचा अंक फीडबॅक पायरी आहे, की लांबी नाही: CFB1, CFB8 व CFB128 सर्व 128-बिट ब्लॉक वापरतात. जुन्या नावे कमकुवत की कल्पून न घेता वाचा.
AES-256-CFB1 सारख्या नावात दोन अंक असतात आणि ते वेगळ्या प्रश्नांची उत्तरे देतात. 256 ही AES कीची लांबी आहे. 1 हा CFB फीडबॅक, म्हणजे सेगमेंट आकार, मोड आपली स्थिती कशी पुढे नेतो याचा गुणधर्म. 1 ला की लांबी म्हणून वाचले तर नाव एखाद्या विनाशकारी चुकीच्या संरचनेसारखे दिसते, म्हणूनच हा प्रश्न पुन्हा पुन्हा येतो.
नावाचे मूल्यांकन करण्यापूर्वी तुम्ही तीन परिमाणांपैकी कोणते पाहत आहात ते ठरवा: की आकार, ब्लॉक आकार किंवा सेगमेंट आकार. नेहमीच्या अर्थाने सुरक्षा मापदंड फक्त पहिलेच आहे.
तीन अंक, तीन परिमाणे
AES 128, 192 किंवा 256-बिट की स्वीकारते आणि तुम्ही कोणतेही निवडा, तिच्याकडे 128-बिट ब्लॉक असतो. ब्लॉक आकार मोडचा नाही, AES चा आहे. CFB प्रत्यय हे तिसरे परिमाण आहे: मोड प्रत्येक पायरीला किती डेटा वापरतो आणि परत देतो. OpenSSL AES दस्तऐवजीकरण CFB प्रकारांसाठी ते शिफ्ट आकार स्पष्टपणे सूचीबद्ध करते.
CFB1 एका वेळी एक बिट, CFB8 एक बाइट, CFB128 पूर्ण ब्लॉक परत देतो. तिन्ही आतून तोच 128-बिट ब्लॉक सायफर वापरतात; बदलतो तो प्रत्येक क्रियेसाठी मोजलेल्या ब्लॉकमधून किती बिट वापरले जातात हा. म्हणूनच प्रत्यय कीची ताकद नाही, तर खर्च व बफरिंग वर्तन बदलतो.
| Name | Key | AES block | Feedback |
|---|---|---|---|
| AES-256-CFB1 | 256 bits | 128 bits | 1 bit |
| AES-256-CFB8 | 256 bits | 128 bits | 8 bits |
| AES-256-CFB128 | 256 bits | 128 bits | 128 bits |
ब्लॉक आकार कधीही बदलत नाही का
AES हा स्थिर 128-बिट ब्लॉक असलेला ब्लॉक सायफर आहे आणि मोड हे त्याभोवती उभारलेली रचना आहेत. त्यांपैकी कोणतीही सेगमेंट आकाराशी जुळण्यासाठी ब्लॉक लहान करत नाही. CFB1 अंमलबजावणीही पूर्ण AES ब्लॉक मोजते आणि निकालातून एक बिट घेते. उर्वरित बिट त्या पायरीसाठी टाकून दिले जातात, कार्यक्षमतेचा खर्च नेमका तिथेच आहे.
म्हणून एका बिटचा फीडबॅक म्हणजे एका बिटची की नाही, आणि नाव त्याच्या प्रत्ययाने क्रमवार लावता येत नाही. CFB128 हा CFB32 पेक्षा चार पट मजबूत नाही; तो मोठे सेगमेंट हाताळतो.
सेगमेंट आकार प्रत्यक्षात काय बदलतो
सेगमेंट आकार प्रत्येक पायरीला किती सायफरटेक्स्ट परत दिला जातो आणि प्रत्येक पायरी किती साधा मजकूर वाहू शकते हे बदलतो. तो त्रुटी प्रसार आणि बफरिंग वर्तनही बदलतो, जे प्रवाहासारख्या वापरासाठी महत्त्वाचे आहे. बाइट-केंद्रित सेगमेंट बफरशी जुळतात, बिट-केंद्रित जुळत नाहीत.
प्रत्यक्षात मोड प्रोटोकॉल निवडतो, ऑपरेटर नाही. VPN डेटा चॅनेल आपल्या प्रोटोकॉलने निर्दिष्ट केलेली रचना स्वतःच्या अखंडता संरक्षणासह वापरते, आणि लायब्ररीची यादी फक्त कोणती नावे अस्तित्वात आहेत ते सांगते.
अपात्र CFB लेबल वाचणे
अपात्र CFB लेबलला त्याचा अंमलबजावणी संदर्भ लागतो. OpenSSL 1.0.2 हेडरमध्ये EVP_aes_128_cfb हा EVP_aes_128_cfb128 साठी मॅक्रो आहे, 192 व 256-बिट कीसाठी जुळणाऱ्या अलियाससह. ती एका शाखेची API नामकरण परंपरा आहे, प्रत्येक लायब्ररी, फाइल स्वरूप किंवा GUI ते संक्षेप त्याच पद्धतीने विस्तारते असा दावा नाही. तुमच्यासमोर असलेल्या आवृत्तीचे हेडर किंवा दस्तऐवज तपासा.
जुना प्रोफाइल CFB म्हणतो आणि समोरचा स्वीकारतो, तर वाटाघाटी केलेले मापदंड कुठेतरी नोंदवले जातात: लॉगमध्ये, कॉन्फिगरेशन डंपमध्ये, API प्रतिसादात. प्रदर्शन स्ट्रिंगवरून सेगमेंट आकाराचा अंदाज करण्याऐवजी ते वाचा.
मोडचे नाव तुम्हाला काय सांगत नाही
नाव एन्क्रिप्शन वर्तनाचे वर्णन करते आणि दुसरे काही नाही. VPN ला अजूनही अखंडता संरक्षण, की व्युत्पत्ती आणि समोरच्याचे प्रमाणीकरण आवश्यक आहे, आणि CFB त्यांपैकी काहीही देत नाही. CFB8 च्या जागी CFB1 टाकणेही बाह्य बदल नाही: तारेवरील वर्तन वेगळे असते आणि दोन्ही बाजूंनी तीच रचना समर्थित असणे आवश्यक आहे. लायब्ररीतील नाव हे देखील सिद्ध करत नाही की तैनात केलेला गेटवे आपल्या डेटा चॅनेलसाठी ते स्वीकारतो.
देखभाल केलेल्या कोणत्याही गोष्टीसाठी प्रोटोकॉलची संपूर्ण संरक्षण व्यवस्था आणि ऑपरेटरचे धोरण वापरा, आणि लायब्ररी व गेटवे आवृत्त्या, नेमका पर्याय आणि वाटाघाटीचा निकाल नोंदवा. जुने नाव तुम्ही काय वाचत आहात ते स्पष्ट करते; ते संरचना पुनर्जीवित करण्याचे समर्थन देत नाही.