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 দিয়ে বদলানোও আলংকারিক পরিবর্তন নয়: নেটওয়ার্কের আচরণ আলাদা এবং উভয় পক্ষকে একই নির্মাণ সমর্থন করতে হবে। লাইব্রেরিতে থাকা একটি নামও প্রমাণ করে না যে স্থাপিত গেটওয়ে তার ডেটা চ্যানেলের জন্য এটি গ্রহণ করে।
রক্ষণাবেক্ষণযোগ্য যেকোনো কিছুর জন্য প্রোটোকলের সম্পূর্ণ সুরক্ষা বিন্যাস ও অপারেটরের নীতি ব্যবহার করুন, এবং লাইব্রেরি ও গেটওয়ে সংস্করণ, সঠিক অপশন ও সমঝোতাকৃত ফলাফল রেকর্ড করুন। পুরনো নামটি ব্যাখ্যা করে আপনি কী পড়ছেন; এটি কনফিগারেশন পুনরুজ্জীবিত করার ন্যায্যতা দেয় না।