اسٹیٹک کلید فائل میں بٹوں کی تعداد OpenVPN سائفر کی طاقت نہیں ہے

اسکینر یا ساتھی OpenVPN کی اسٹیٹک کلید فائل کے اندر چھپی بٹوں کی تعداد کی طرف اشارہ کر کے پوچھتا ہے کہ سرنگ اس حجم کا سائفر کیوں استعمال نہیں کر رہی۔ سوال معقول لگتا ہے، اور جواب کوئی عدد نہیں: بینر ذخیرہ شدہ کلید کا مواد گنتا ہے، جبکہ سائفر صرف وہ حصہ خرچ کرتا ہے جو اس کے کلید کے حجم کو درکار ہوتا ہے۔ اس میزان کو طاقت کی سیٹنگ سمجھنے سے ایسی تبدیلیاں ہوتی ہیں جو کچھ نہیں بدلتیں۔ یہ فارمیٹ کسی بھی ایک الگورتھم کے استعمال سے زیادہ مواد رکھنے کے لیے بنایا گیا ہے۔

یہاں دو سوال مل جاتے ہیں: فائل کتنا کلیدی مواد محفوظ کرتی ہے، اور طے شدہ سائفر کتنا مضبوط ہے۔ سرنگ کو صرف دوسرا بیان کرتا ہے۔

بینر کا عدد دراصل کیا گنتا ہے

کنٹینر سائفر کے مواد اور HMAC کے مواد کو الگ الگ ڈھانچوں کے طور پر ترتیب دیتا ہے، اور دو طرفہ شکل ایسے دو مجموعے رکھتی ہے تاکہ ہر سمت اپنی کلیدیں لے جا سکے۔ لکھنے والا کوڈ چھپے ہوئے عدد کو ترتیب شدہ ڈھانچوں کی تعداد، ان کے حجم اور فی بائٹ آٹھ بٹوں سے اخذ کرتا ہے۔ یہ ذخیرے پر حساب ہے، یہ دعویٰ نہیں کہ ایک سائفر ہر محفوظ بائٹ خرچ کرتا ہے۔ ہیڈر زیادہ سے زیادہ سائفر مواد کی تقسیم بھی مقرر کرتا ہے تاکہ لائبریری کی تبدیلی فارمیٹ کے پیمانے خاموشی سے نہ بدل سکے۔

اس کا موازنہ سرٹیفکیٹ کی کلید سے کریں، جہاں بٹوں کی تعداد واقعی ایک شے کا حجم بیان کرتی ہے۔ 4,096 بٹ کی RSA کلید اور وہ کلید فائل جس کے بینر پر 4,096 بٹ لکھا ہو، الگ کاموں والی الگ چیزیں ہیں، اور انہیں ایک ہی ڈائل کی دو سیٹنگوں کے طور پر رکھنا برے نتائج دیتا ہے۔

ایک فائل میں دو کلیدی مجموعے

فائل کا ہر نصف حصہ خفیہ کاری اور توثیق کا مواد فراہم کرتا ہے، کیونکہ پیشگی مشترکہ کلید کا موڈ ان الگ ٹکڑوں سے دونوں سمتوں میں پیکٹ محفوظ رکھتا ہے۔ فعال سائفر صرف وہ بائٹس استعمال کرتا ہے جو اس کے کلید کے حجم کو درکار ہوں، اور ڈائجسٹ اپنا آؤٹ پٹ حجم استعمال کرتا ہے، اسی لیے قابل استعمال طاقت فائل کی لمبائی سے نہیں بلکہ اختیارات سے آتی ہے۔ ہیکساڈیسیمل بلاک کو بڑھانا تشکیل شدہ الگورتھم سے اس کا زیادہ خرچ کرنے کو نہیں کہتا۔ تبصرے کو بڑے عدد سے بدلنے سے اس سے بھی کم بدلتا ہے۔

اگر واقعی لمبی کلید چاہیے تو بدلنے والی سیٹنگ سائفر یا ڈائجسٹ ہے، اور جنریٹر وہی بناتا ہے جو منتخب الگورتھم کو درکار ہوتا ہے۔

پروفائل پڑھنے سے معلوم ہوتا ہے کہ آپ کے پاس کون سا موڈ ہے

ایک ہی فائل فارمیٹ دو بالکل مختلف کام کرتا ہے، اور کون سا آپ کے پاس ہے یہ صرف پروفائل بتاتا ہے۔ پرانی secret لائن فائل کو سرنگ کا واحد کلیدی مواد بنا دیتی ہے، جبکہ tls-auth یا tls-crypt اسے سرٹیفکیٹس کے ساتھ کنٹرول چینل کی حفاظت بناتا ہے۔ کوئی بھی استعمال بلاک کتنا ہی مشابہ نظر آئے اسے کلائنٹ کے سرٹیفکیٹ کی نجی کلید نہیں بناتا۔ متبادل بنانے سے پہلے اختیار اور ورژن کی نشاندہی کریں، اور حروف بڑھانے کے بجائے دستاویزی جنریٹر استعمال کریں۔

یہی فرق افشا کے ردعمل کا بھی تعین کرتا ہے۔ رسنے والی tls-auth کلید سیشن کلیدیں ظاہر نہیں کرتی، لیکن حملہ آور کو کنٹرول چینل کا ٹریفک داخل کرنے دیتی ہے، اس لیے اسے پھر بھی بدلنا ہوتا ہے۔ رسنے والی secret کلید زیادہ بری ہے، کیونکہ وہی وہ مواد تھا جو خود ڈیٹا کی حفاظت کرتا تھا۔

حفاظتی جائزے میں کیا درج ہونا چاہیے

تین چیزیں الگ الگ درج کریں: طے شدہ ڈیٹا چینل کی حفاظت، کنٹرول چینل کی حفاظت، اور یہ کہ ساتھی ایک دوسرے کی توثیق کیسے کرتے ہیں۔ data-ciphers AES-256-GCM جیسی لائن صرف پہلی کی وضاحت کرتی ہے، اور وہیں رکنے والی رپورٹ یہ جواب نہیں دے سکتی کہ کنٹرول چینل بالکل محفوظ ہے یا نہیں۔ اسٹیٹک کلید فائل tls-auth یا tls-crypt کے ساتھ استعمال ہونے پر دوسری قسم میں آتی ہے، اور استعمال نہ ہونے پر کسی میں نہیں۔ اقسام ملا دینے والے جائزہ لینے والے زیادہ مضبوط سائفر چاہتے ہوئے بڑی کلید فائل مانگتے ہیں۔

اگر فائل افشا ہو گئی ہے تو اسے گھمائیں اور منظور شدہ چینل سے دوبارہ تقسیم کریں۔ سمجھوتے میں آئے راز میں حروف بڑھانا گھمانا نہیں، اور یہ افشا شدہ مواد کو کارآمد رکھتا ہے۔

گھمانے کا ریکارڈ اسی پروفائل کے ساتھ رکھیں جس کا وہ ہے۔ اگلا جائزہ پوچھے گا کون سی کلید نے کون سی مدت محفوظ رکھی، اور بینر اس کا جواب نہیں دے گا۔