1. ایک جیسے نام اور ایک جیسے مواد والی فائلیں الگ باتیں ہیں
اگر ڈاؤن لوڈ کردہ انسٹالر کا نام اور حجم ہدایات کے صفحے سے ملتا ہو تو آسانی سے لگ سکتا ہے کہ فائل درست ملی ہے۔ لیکن نام بدلا جا سکتا ہے اور برابر حجم کی فائلوں کا مواد مختلف ہو سکتا ہے۔ اس کے برعکس، تصویر کی فائل کو دوسرے نام سے نقل کرنے کا لازمی مطلب یہ نہیں کہ اس کے اندر کے بائٹس بھی بدل گئے ہیں۔ ہیش یہاں موازنے میں مدد دیتا ہے: فائل کے مواد پر ایک مقررہ حساب لگا کر مختصر قدر حاصل کی جاتی ہے۔ سوال یہ ہے کہ موصولہ بائٹس کسی قابل اعتماد حوالے سے ملتے ہیں یا نہیں، صرف یہ نہیں کہ نام قابل یقین لگتا ہے۔ بیک اپ کو دوسرے ذخیرہ جاتی آلے پر منتقل کرنے کے بعد بھی یہی سوال پوچھا جا سکتا ہے۔
SHA-256 ایک الگورتھم ہے جو ان پٹ سے 256 بِٹ کی ہیش قدر بناتا ہے۔ اسے عموماً سولہ اساس عددی نظام کے 64 ہندسوں میں دکھایا جاتا ہے، کیونکہ اس نظام کا ہر ہندسہ 4 بِٹ کی نمائندگی کرتا ہے۔ فائل بڑی ہونے پر نتیجے کی لمبائی اس کے حجم کے تناسب سے نہیں بڑھتی۔ یکساں بائٹس پر یکساں الگورتھم لگانے سے یکساں نتیجہ ملتا ہے۔ تاہم، محدود لمبائی کی قدروں میں تمام ممکنہ ان پٹ کی نمائندگی ہونے کی وجہ سے اصولاً تصادم موجود ہیں، یعنی مختلف ان پٹ ایک ہی قدر دے سکتے ہیں۔ عملی موازنے میں مفید ہونے اور ہر فائل کو ریاضیاتی طور پر منفرد نام دینے کے دعوے میں فرق رکھنا چاہیے۔ RFC 6234 میں SHA-256 سمیت ہیش کے حساب اور آزمائشی مواد فراہم کیے گئے ہیں۔
2. ہیش نہ خفیہ کاری ہے نہ فائل کی چھوٹی نقل
ہیش قدر جان لینے سے کوئی ایسا رمز کشائی کا بٹن نہیں مل جاتا جو اصل دستاویز یا تصویر واپس لے آئے۔ خفیہ کاری اس طرح بنائی جاتی ہے کہ مناسب کلید سے اصل متن حاصل کیا جا سکے، جبکہ رمزنگاری کا ہیش اصل مواد کو دوبارہ بنانے کے لیے ذخیرہ کرنے کی شکل نہیں ہے۔ اس کا یہ مطلب بھی نہیں کہ صرف ہیش شائع کرنے سے ہر ان پٹ راز میں محفوظ رہتا ہے۔ اگر ممکنہ ان پٹ صرف چند ہوں تو ہر ایک کا ہیش حساب کر کے موازنہ کیا جا سکتا ہے۔ اس لیے فائل جانچنے والے SHA-256 کی وضاحت کو اس مشورے تک نہیں بڑھانا چاہیے کہ پاس ورڈ پر براہ راست ہیش لگا کر محفوظ کرنا کافی ہے۔ سالمیت کی جانچ، رازداری اور پاس ورڈ محفوظ رکھنے کی ضروریات الگ ہیں۔
پوری فائل پر حساب کا مطلب صرف اسکرین پر نظر آنے والے حروف کا موازنہ بھی نہیں ہے۔ ایک جیسے دکھائی دینے والے جملوں کے بائٹس سطر ختم کرنے کے طریقے، حروف کی انکوڈنگ یا دستاویز کے اندرونی میٹاڈیٹا کی وجہ سے مختلف ہو سکتے ہیں۔ کمپریس شدہ آرکائیو سے نکالی گئی فائل اصل آرکائیو سے الگ موازنے کا ہدف ہے۔ اگر حساب سے پہلے حروف کی نارملائزیشن کی جائے یا سطروں کے اختتام بدلے جائیں تو تبدیل شدہ مواد کا ہیش ملتا ہے۔ تقسیم کنندہ نے اصل آرکائیو کی قدر دی ہو تو پہلے خود ڈاؤن لوڈ کردہ آرکائیو سے موازنہ کریں۔ یہ پہلے سے موجود Unicode اور UTF-8 کے مضمون میں بیان کردہ ظاہری متن اور بائٹس کے فرق کو عملی فائل تصدیق پر لاگو کرنے کی مثال ہے۔
3. ڈاؤن لوڈ کو یکساں الگورتھم اور درست حوالہ قدر سے ملائیں
تصدیق سے پہلے بنانے والے کی سرکاری تقسیم کی ہدایات میں متعلقہ ورژن، آپریٹنگ سسٹم، فائل کا نام اور ہیش الگورتھم ایک ساتھ دیکھیں۔ دوسرے آپریٹنگ سسٹم کے انسٹالر یا مختلف ورژن کی قدر موازنے کا درست حوالہ نہیں بن سکتی۔ PowerShell میں Get-FileHash -LiteralPath '.\download.zip' -Algorithm SHA256 سے مقامی فائل پڑھ کر اس کا ہیش حساب کیا جا سکتا ہے۔ یہ حکم اس پاتھ پر موجود مواد کو چلاتا نہیں ہے۔ Microsoft کی سرکاری دستاویز بتاتی ہے کہ قدر فائل کے مواد سے نکلتی ہے اور صرف نام بدلنے سے نہیں بدلتی۔ نام اور پاتھ اصل موصولہ فائل کے مطابق رکھیں اور حساب کے دوران فائل میں تبدیلی نہ کریں۔
نتیجے میں Hash خانے کے تمام 64 ہندسوں کو تقسیم کنندہ کی شائع کردہ SHA-256 قدر سے ملائیں۔ صرف شروع یا آخر کے چند ہندسے ملنے سے پوری قدر کو یکساں نہ سمجھیں۔ سولہ اساس نظام کے بڑے اور چھوٹے انگریزی حروف ایک ہی عدد ظاہر کرتے ہیں؛ لیکن دوسرے حروف شامل ہوں یا ہندسے کم ہوں تو پہلے نقل کردہ قدر دیکھیں۔ مطابقت موصولہ بائٹس اور اس حوالہ قدر کے درمیان یکسانیت کی تائید کرتی ہے جس پر آپ اعتماد کرتے ہیں۔ یہ دستاویز کے حقائق، پروگرام کے معیار یا نقصان دہ رویے کی جانچ کا نتیجہ نہیں ہے۔ حوالہ فائل خود مسئلہ رکھتی ہو تو اس کی بالکل یکساں نقل کا ہیش بھی وہی ہو گا۔ حساب کامیاب ہونا اور فائل استعمال کرنے کے قابل ہونا الگ فیصلے ہیں۔
4. عدم مطابقت تحقیق کا اشارہ ہے، حملے کا قطعی ثبوت نہیں
مثلاً فرض کریں کہ کل موصولہ تقسیم کی فائل کو آج کی ہدایات میں دی گئی قدر سے ملانے پر فرق نکلتا ہے۔ یہ وضاحتی مثال ہے، کسی حقیقی واقعے کا ریکارڈ نہیں۔ پہلے دیکھیں کہ ہدایات اسی ورژن کی ہیں، کسی دوسرے آلے کی فائل تو نہیں لی، اور حساب ڈاؤن لوڈ مکمل ہونے سے پہلے تو نہیں کیا۔ ممکن ہے آرکائیو کے بجائے نکالی ہوئی فائل کا حساب کیا ہو یا ایڈیٹر نے دستاویز دوبارہ محفوظ کی ہو۔ اس طرح موازنے کا ہدف بدلنے اور ترسیل یا ذخیرے کے دوران مواد بدلنے میں فرق رکھنا چاہیے۔ صرف قدر مختلف ہونے سے معلوم نہیں ہوتا کہ کس نے، کب، کیا بدلا۔
عدم مطابقت والے انسٹالر کو جانچنے کے لیے فوراً نہ چلائیں۔ سرکاری تقسیم کی ہدایات اور حوالہ قدر دوبارہ دیکھیں، پھر نئی ڈاؤن لوڈ کردہ فائل سے موازنہ کریں۔ فرق برقرار رہے تو تقسیم کنندہ کی تصحیح کی اطلاع یا معاونت کے ذریعے کو دیکھیں اور نتیجہ محفوظ کریں۔ ریکارڈ میں جانچ کا وقت، ماخذ کا پتہ، فائل کا ورژن، الگورتھم اور حساب شدہ قدر ایک ساتھ لکھیں۔ بار بار ایک جیسا نتیجہ اس بات کا اشارہ ہے کہ موجودہ مقامی فائل یکساں طریقے سے پڑھی گئی، لیکن اس سے شائع کردہ قدر کی غلطی یا تقسیم کے راستے کا مسئلہ حل نہیں ہوتا۔ حوالہ ریکارڈ کو متوقع قدر سے بدل دینے سے بعد کی تبدیلی پرکھنے کی بنیاد ضائع ہو جاتی ہے۔
5. حوالہ قدر پر اعتماد کی بنیاد اور ڈیجیٹل دستخط کا کردار
اگر حملہ آور فائل کے ساتھ دکھائی گئی ہیش قدر بھی بدل سکتا ہو تو تبدیل شدہ فائل کا ہیش حساب کر کے اسے نیا حوالہ بنا سکتا ہے۔ NIST SP 800-175B کلید یا دستخط کے بغیر صرف ہیش استعمال کرنے کی یہ حد بیان کرتا ہے۔ سرکاری پتے کے HTTPS صفحے سے قدر لینا ماخذ اور ترسیل کا راستہ جانچنے میں مدد دیتا ہے، لیکن یہ ضمانت نہیں کہ خود تقسیم کا سرور متاثر ہونے کا امکان بھی ختم ہو گیا۔ اہم بات ہیش کی عبارت کا لمبا دکھائی دینا نہیں، بلکہ یہ ہے کہ حوالہ کہاں سے اور کس قابل اعتماد طریقۂ کار کے ذریعے ملا۔ ایک ہی اسکرین سے نقل کردہ دو قدروں کی مطابقت اکیلے بنانے والے کی شناخت ثابت نہیں کرتی۔
ڈیجیٹل دستخط، مثلاً قابل اعتماد طریقے سے حاصل کردہ عوامی کلید کی مدد سے، دستخط اور مواد کا تعلق جانچنے دیتے ہیں۔ تقسیم کنندہ دستخط کی تصدیق کا طریقہ دے تو کلید کے مالک اور فنگرپرنٹ کی جانچ سمیت سرکاری ہدایات پر عمل کریں۔ غیر واضح ماخذ کی فائل کے پاس پہلی بار نظر آنے والی عوامی کلید پر یوں ہی اعتماد کرنے سے اعتماد کے نقطۂ آغاز کا مسئلہ حل نہیں ہوتا۔ مشترک خفیہ کلید استعمال کرنے والا HMAC بھی عام ہیش سے الگ توثیقی ذریعہ ہے، لیکن ایسی سہولت نہیں جسے ہر ڈاؤن لوڈ میں من مانے طور پر شامل کر کے مسئلہ حل کر لیا جائے۔ درست دستخط بھی پروگرام کے بے عیب ہونے یا دستاویز کے سچا ہونے کا ثبوت نہیں ہیں۔ بائٹس کی مطابقت، ماخذ کی تصدیق اور مواد کی جانچ باہم متعلق ہیں، مگر ہر ایک کے لیے الگ بنیاد درکار ہے۔
6. بیک اپ اور مشترکہ کام میں موازنے کی حدود بھی لکھیں
ذاتی تصاویر کے بیک اپ میں اصل فائلوں کے SHA-256 محفوظ کر کے نقول سے موازنہ کرنا منتقلی کے دوران تبدیلی کا پتہ لگانے میں مدد دیتا ہے۔ حوالہ فہرست بھی اس طرح رکھیں کہ اصل فائلوں کے ساتھ گم یا اوور رائٹ نہ ہو۔ تصویر سنبھالنے والا پروگرام گھماؤ کی معلومات یا تصویر لینے کا میٹاڈیٹا دوبارہ لکھے تو تصویر ملتی جلتی ہونے کے باوجود فائل کا ہیش بدل سکتا ہے۔ پہلے یہ فرق کریں کہ مقصد ہر بائٹ محفوظ رکھنا ہے یا ترمیم شدہ تصویر کا مفہوم یکساں ہونے کی جانچ۔ پورا فولڈر جانچنا ہو تو ایک فائل کے ہیش پر نہ رکیں، بلکہ شامل فائلوں کی فہرست، نسبتی پاتھ اور ہر فائل کی قدر ساتھ رکھیں۔
دستاویز کے مشترکہ جائزے میں ہیش جانچے گئے عین نسخے کی نشاندہی بھی کر سکتا ہے۔ لیکن ہیش ملنے کی جانچ اس ثبوت کی جگہ نہیں لے سکتی کہ کسی نے واقعی پورا متن پڑھا یا ترجمے کا موازنہ کیا۔ پہلے لکھیں کہ کیا، کب اور کس طریقے سے جانچا گیا، پھر اس ریکارڈ کو متعلقہ فائل کی قدر سے جوڑیں۔ اس مضمون کی تصویر خود تیار کردہ وضاحتی خاکہ ہے جو بائٹس کے موازنے، حوالہ قدر کے ماخذ اور تصدیق کی حدود کو منظم کرتا ہے؛ یہ حقیقی پیمائش یا سرٹیفکیٹ نہیں ہے۔ فائل جانچتے وقت ہدف اور الگورتھم، حوالے کا ماخذ اور نتیجے سے کیا کہا جا سکتا ہے، ترتیب سے لکھیں۔ اس طرح مطابقت اور عدم مطابقت کو بڑھا چڑھا کر بیان کیے بغیر اگلا شخص وہی طریقہ دوبارہ اختیار کر سکتا ہے۔