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 सँग बदल्नु पनि बाह्य परिवर्तन होइन: तारको व्यवहार फरक हुन्छ र दुवै पक्षले एउटै संरचना समर्थन गर्नुपर्छ. पुस्तकालयमा भएको नामले पनि तैनाथ गरिएको गेटवेले आफ्नो डाटा च्यानलका लागि यसलाई स्वीकार गर्छ भनी प्रमाणित गर्दैन.
मर्मत गरिने जुनसुकै कुराका लागि प्रोटोकलको पूर्ण सुरक्षा व्यवस्था र अपरेटरको नीति प्रयोग गर्नुहोस्, र पुस्तकालय तथा गेटवे संस्करण, ठ्याक्कै विकल्प र वार्ताको नतिजा रेकर्ड गर्नुहोस्. पुरानो नामले तपाईं के पढ्दै हुनुहुन्छ बताउँछ; यसले कन्फिगरेसन पुनर्जीवित गर्नुको औचित्य दिँदैन.