AES-256 VPN انکرپشن سوٹ کی وضاحت کیوں نہیں کرتا
ایک سوٹ چار کردار ادا کرتا ہے: بڑے پیمانے پر انکرپشن، سالمیت، کلید کی تشکیل اور ساتھی کی تصدیق۔ سائفر کا نام ان میں سے صرف ایک کو، ایک پرت میں ڈھکتا ہے۔
پوچھیں کہ VPN کون سی انکرپشن استعمال کرتا ہے اور جواب عام طور پر ایک لفظ میں آتا ہے: AES-256، یا ChaCha20، یا شاید WireGuard۔ یہ جواب ایک پرت کے ایک جزو کا نام لیتا ہے، جبکہ رابطے کو واقعی بچانے والی چیز چار مختلف کردار ادا کرنے والے الگورتھم کا مجموعہ ہے۔ جزو کو ترتیب کے ساتھ ملانا ان بات چیت میں سب سے عام غلطی ہے، اور یہ ایسی موازنے پیدا کرتی ہے جنہیں طے نہیں کیا جا سکتا۔
ایک رابطے کے اندر چار کام
بڑے پیمانے پر انکرپشن ڈیٹا چینل کے لیے واضح متن کو سائفر متن میں بدلتا ہے، اور اس کی کلید بھیجی نہیں جاتی بلکہ اخذ کی جاتی ہے۔ سالمیت کا تحفظ تبدیلی کا پتہ لگاتا ہے، جو الگ کام ہے چاہے ایک ہی ساخت دونوں کرے۔ کلید کی تشکیل مشترکہ ٹریفک مواد پیدا کرتی ہے، اور ساتھی کی تصدیق طے کرتی ہے کہ دوسرے سرے پر کون ہے۔ ان میں سے کوئی ایک بھی نہ ہو تو رابطہ محفوظ نہیں، باقی حصہ کتنا ہی مضبوط ہو۔
کچھ ڈیزائن دو کرداروں کو ایک میں جوڑ دیتے ہیں۔ AES-GCM اور ChaCha20-Poly1305 تصدیق شدہ انکرپشن ساختیں ہیں، اس لیے رازداری اور سالمیت ساتھ آتی ہیں؛ AES-CBC ایسا نہیں، اور اسے اپنی کلید کے ساتھ الگ پیغام تصدیق کوڈ درکار ہے۔ اس لیے تجویز کو آزاد اعداد کی تھیلی کے طور پر پڑھنا ان کو غلط پڑھتا ہے جو جوڑوں کے طور پر بنائے گئے۔
کردار مختلف پرتوں پر بھی ہوتے ہیں، اسی لیے ایک ہی لفظ دو مصنوعات میں مختلف معنی دے سکتا ہے۔ ESP کے اندر بلاک سائفر اور TLS کے اندر بلاک سائفر مختلف تقاضوں والی مختلف بات چیت میں ایک ہی بنیادی عنصر ہیں۔ اس لیے بنیادی عنصر کو اس کے موڈ اور پرت کے بغیر بیان کرنا کچھ بھی نہ کہنے سے بدتر ہو سکتا ہے۔
سائفر کا نام تقریباً کچھ کیوں نہیں کہتا
AES-256 کے فقرے کو ایک لمحے سنجیدگی سے لیں: یہ ایک بلاک سائفر اور کلید کا حجم بتاتا ہے۔ یہ کام کرنے کے موڈ، سالمیت ملتی ہے یا نہیں، کلیدیں کیسے قائم ہوئیں یا ساتھی کی تصدیق کیسے ہوئی کے بارے میں کچھ نہیں کہتا۔ دو مصنوعات دونوں AES-256 کی تشہیر کر سکتی ہیں اور باقی ہر بات میں مختلف ہو سکتی ہیں، جن میں ایک غیر تصدیق شدہ موڈ کے ساتھ اور دوسری جدید کلید تبادلے کے ساتھ AEAD موڈ استعمال کرتی ہے۔
TLS 1.3 نے یہ تقسیم معیار میں لائی، جو پرانی اصطلاحات سیکھنے والے ہر شخص کے لیے مفید اصلاح ہے۔ اس کے سائفر سوٹ صرف AEAD اور ہیش کا نام لیتے ہیں، جبکہ کلید تبادلے کے گروہ اور دستخط الگورتھم الگ پیرامیٹر کے طور پر بات چیت ہوتے ہیں۔ اس لیے TLS 1.3 سوٹ کا نام TLS 1.2 سوٹ کے نام کے ساتھ مساوی بنیاد پر موازنے کے قابل نہیں، اگرچہ دونوں کنفیگریشن فائل کے ایک ہی میدان میں نظر آتے ہیں۔ دو ڈوروں کا براہ راست موازنہ کرنے والا آڈیٹر ایسا نتیجہ نکالتا ہے جس کی پروٹوکول تائید نہیں کرتا۔ بات چیت شدہ گروہ اور دستخط پیرامیٹر بھی پڑھیں، ورنہ موازنہ نامکمل ہے۔
WireGuard مخالف راستہ چنتا ہے اور بات چیت کو تقریباً مکمل طور پر ہٹا دیتا ہے: پروٹوکول ایک مقررہ الگورتھم مجموعہ طے کرتا ہے، اس لیے دو عمل درآمد مل کر کام کرتے ہیں یا نہیں۔ یہ ایک جائز ڈیزائن انتخاب ہے، اور اس کا یہ بھی مطلب ہے کہ WireGuard کون سا سوٹ بات چیت کرتا ہے اس سوال کا موازنے کے قابل جواب نہیں۔ اگر آپ اس کا آڈٹ کر رہے ہیں، تفصیلات ایک بار پڑھیں اور پھر بات چیت کے بجائے اس کے گرد کلید کے انتظام کا آڈٹ کریں۔
اصطلاحات کا تعین پرت کرتی ہے
IPsec کی تعیناتی دو بار بات چیت کرتی ہے: کنٹرول چینل کے لیے IKE تجویز اور ڈیٹا کے لیے ESP تبدیلی، اور دونوں جائز طور پر مختلف ہو سکتے ہیں۔ پہلی پڑھ کر یہ سمجھنا کہ وہ دوسری کی وضاحت کرتی ہے آڈٹ کے دوران الجھن کا عام ذریعہ ہے، کیونکہ کنفیگریشن فائل دونوں کا ذکر کرتی ہے اور دلچسپ دوسری ہے۔
| Layer | What is negotiated there | What it does not cover |
|---|---|---|
| IKE proposal | Algorithms and groups for the control channel that builds the tunnel | The algorithms protecting the data itself |
| ESP transform | Encryption and integrity for tunneled packets | Peer identity, which authentication already settled |
| TLS handshake | AEAD and hash, plus separately negotiated groups and signatures | Routing, authorization or retention policy |
| WireGuard | Nothing; the algorithm set is fixed by the protocol | Everything above the cryptographic arrangement |
ایک لائبریری میں دستیاب نام دوسرے ڈیٹا راستے کے لیے خود بخود نافذ نہیں ہوتا۔ اس لیے یہ دعویٰ کہ ہماری مصنوعات AES-256 کی تائید کرتی ہے سننے سے کمزور ہے، اور اسی لیے باہمی عمل کی دشواری عام طور پر دونوں طرف تمام پرانے الگورتھم فعال کرنے کے بجائے محفوظ تراش کو ڈھونڈ کر حل کی جاتی ہے۔
TLS 1.3 کی تفصیلات اس تقسیم کی سب سے واضح شائع شدہ مثال ہیں، کیونکہ یہ سوٹ کو جوڑی کے طور پر متعین کرتی ہے اور باقی کو اس کی اپنی بات چیت میں منتقل کرتی ہے۔ جب وہ شکل مانوس ہو جائے تو IPsec تجویز اور WireGuard کا واحد مقررہ مجموعہ ایک ہی خیال کی اقسام کے طور پر پڑھے جاتے ہیں۔
بات چیت شدہ نتیجہ پڑھیں، پھر رکیں
تشکیل شدہ تجویز اس بات کا ثبوت نہیں کہ دو فریقوں نے کیا چنا۔ زندہ سیشن جواب رکھتا ہے، اور ہر بڑا عمل درآمد پیکٹ پکڑے بغیر اس کی اطلاع دے سکتا ہے۔
openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg showآؤٹ پٹ میں دی گئی فہرست کے بجائے منتخب الگورتھم پڑھیں۔ اگر جواب پالیسی کے ارادے سے کمزور ہے تو اصلاح ایک یا دوسرے فریق کی تجویز کنفیگریشن میں ہے، اور جدید عمل درآمد میں عدم مطابقت عام طور پر خاموش کمی کے بجائے ناکام بات چیت کے طور پر ظاہر ہوتی ہے۔
پھر یاد رکھیں کہ سوٹ کیا نہیں ڈھکتا۔ راستے، ایپ اجازتیں، لاگنگ اور برقراری اپنے جائزے والے الگ فیصلے ہیں، اور موافق کرپٹوگرافک ترتیب ان کے بارے میں کچھ نہیں کہتی۔ سائفر پر بحث کرنے کے قابل ہے، لیکن یہ اس سوال سے تنگ سوال کا جواب دیتی ہے جو زیادہ تر لوگ واقعی پوچھتے ہیں۔
اصطلاحات درست رکھیں اور دلیل مختصر ہو جاتی ہے۔ سوٹ ایک پرت پر کرداروں کا مجموعہ ہے، سائفر ایک جزو ہے، اور بات چیت شدہ نتیجہ ہی واحد چیز ہے جو اس رابطے کی وضاحت کرتی ہے جو آپ کے پاس واقعی ہے۔ موازنے میں باقی سب آرائش ہے۔