CFB1, CFB8 और CFB128: यह फ़ीडबैक का आकार है, कुंजी का आकार नहीं
CFB के बाद की संख्या फ़ीडबैक चरण है, कुंजी की लंबाई नहीं: CFB1, CFB8 और CFB128 128-बिट ब्लॉक का उपयोग करते हैं। कमज़ोर कुंजियाँ गढ़े बिना पुराने नाम पढ़ें।
AES-256-CFB1 जैसा नाम दो संख्याएँ रखता है, और वे अलग-अलग सवालों का जवाब देती हैं। 256 AES कुंजी की लंबाई है। और 1 CFB फ़ीडबैक है, यानी खंड का आकार: इस बात का गुण कि मोड अपनी स्थिति को कैसे आगे बढ़ाता है। अगर 1 को कुंजी की लंबाई के रूप में पढ़ा जाए, तो नाम विनाशकारी गलत कॉन्फ़िगरेशन जैसा दिखता है, और इसीलिए सवाल बार-बार लौटता है।
नाम का फ़ैसला करने से पहले तय करें कि आप तीन में से कौन-सी मात्रा देख रहे हैं: कुंजी का आकार, ब्लॉक का आकार या खंड का आकार। सामान्य अर्थ में केवल पहली ही सुरक्षा पैरामीटर है।
तीन संख्याएँ, तीन मात्राएँ
AES 128, 192 या 256-बिट कुंजियाँ स्वीकार करता है और आप जो भी चुनें उसका ब्लॉक 128 बिट का होता है। ब्लॉक का आकार AES का है, मोड का नहीं। CFB प्रत्यय तीसरी मात्रा है: मोड हर चरण में कितना डेटा खर्च करता है और लौटाता है। AES पर OpenSSL दस्तावेज़ 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 से बदलना भी दिखावटी बदलाव नहीं है: नेटवर्क पर व्यवहार अलग है और दोनों पक्षों को वही रचना समर्थित करनी होगी। लाइब्रेरी में मौजूद नाम भी यह साबित नहीं करता कि तैनात गेटवे इसे अपने डेटा चैनल के लिए स्वीकार करता है।
जो भी बनाए रखा जाता है, उसके लिए प्रोटोकॉल की पूरी सुरक्षा व्यवस्था और ऑपरेटर की नीति अपनाएँ, और लाइब्रेरी तथा गेटवे के संस्करण, सटीक विकल्प और बातचीत का परिणाम दर्ज करें। पुराना नाम समझाता है कि आप क्या पढ़ रहे हैं; यह कॉन्फ़िगरेशन को पुनर्जीवित करने का औचित्य नहीं देता।