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 لگانا بھی ظاہری تبدیلی نہیں: تار پر رویہ مختلف ہے اور دونوں فریقوں کو وہی ڈھانچہ سپورٹ کرنا ہوگا۔ لائبریری میں نام ہونا بھی یہ ثابت نہیں کرتا کہ نصب شدہ گیٹ وے اسے اپنے ڈیٹا چینل کے لیے قبول کرتا ہے۔
جو بھی برقرار رکھا جاتا ہے، اس کے لیے پروٹوکول کی مکمل حفاظتی ترتیب اور چلانے والے کی پالیسی استعمال کریں، اور لائبریری و گیٹ وے کے نسخے، درست انتخاب اور طے شدہ نتیجہ درج کریں۔ پرانا نام بتاتا ہے کہ آپ کیا پڑھ رہے ہیں؛ یہ ترتیب کو دوبارہ زندہ کرنے کا جواز نہیں دیتا۔