IPsec پہلے سے مشترکہ کلید: آپ کے ٹائپ کردہ تار کے پیچھے کی بائٹس

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

گیٹ وے تار کے ساتھ کیا کرتا ہے

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

اس لیے مفید سوال کبھی «کیا یہ ایک جیسے نظر آتے ہیں» نہیں، بلکہ «ہر عمل درآمد کون سی قطعی بائٹ ترتیب ہیش کرتا ہے» ہے۔

اضافی بائٹس کہاں سے آتے ہیں

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

گلف نہیں بلکہ بائٹس دکھانے والے آلے سے موازنہ کریں۔ printf '%s' "$PSK" | xxd | tail -2 قدر کا اختتام ہیکس میں چھاپتا ہے، جہاں گمشدہ 0a یا 20 واضح نظر آتا ہے۔ یہ دونوں طرف کریں اور دونوں ڈمپ ساتھ ساتھ موازنہ کریں۔ یہ تیار شدہ آزمائشی مواد پر کریں، کسی پیداواری راز پر نہیں جسے بعد میں شیل کی تاریخ میں چھوڑ دیں۔

انکوڈ شدہ ہونا انکرپٹ شدہ ہونا نہیں ہے

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

Apple کی IPSec لغت قسم کی اہمیت کی مفید مثال ہے: یہ SharedSecret کو L2TP اور Cisco IPsec پے لوڈز میں مشترکہ راز کی تصدیق کے طریقے کے لیے ڈیٹا کے طور پر درج کرتی ہے۔ یہ کسی مخصوص پے لوڈ میں مخصوص خصوصیت ہے، کوئی عمومی متنی فیلڈ نہیں جسے آپ کسی دوسرے پروٹوکول کے لیے دوبارہ استعمال کر سکیں جو اتفاق سے راز مانگتا ہو۔

دعویٰ کردہ حد ایک ہی امتزاج کی ہوتی ہے

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

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

طاقت نہیں، پیشکش درست کریں

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

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