ہیش کیا ہے، اور کس کام آتا ہے
ہیش فنکشن کسی بھی سائز کا ان پٹ لے کر سولہ عددی حروف کی ایک مقررہ لمبائی والی اسٹرنگ بناتا ہے۔ ایک ہی ان پٹ ہمیشہ ایک ہی ہیش دیتا ہے؛ ایک بائٹ بدلنے سے بالکل مختلف ہیش بن جاتا ہے۔ ہیش کو واپس موڑ کر اصل ان پٹ حاصل نہیں کیا جا سکتا۔
یہ امتزاج انہیں سب سے بڑھ کر ایک کام کے لیے مفید بناتا ہے: یہ ثابت کرنا کہ ڈیٹا کے دو ٹکڑے ایک جیسے ہیں، بغیر ان کا براہِ راست موازنہ کیے۔ کوئی Linux ISO ڈاؤن لوڈ کریں، اس کا ہیش بنائیں، منصوبے کے شائع کردہ چیک سم سے موازنہ کریں، اور آپ کو معلوم ہو جائے گا کہ فائل صحیح سالم اور بغیر تبدیلی کے پہنچی یا نہیں۔ یہی روزمرہ استعمال ہے، اور اوپر دیا گیا موازنے کا خانہ اسی کے لیے ہے۔
کون سا الگورتھم استعمال کرنا چاہیے؟
| الگورتھم |
آؤٹ پٹ |
صورتحال |
| MD5 | 32 سولہ عددی حروف | ٹوٹ چکا۔ صرف غیر سیکیورٹی استعمال کے لیے۔ |
| SHA-1 | 40 سولہ عددی حروف | ٹوٹ چکا۔ 2017ء سے متروک۔ |
| SHA-256 | 64 سولہ عددی حروف | محفوظ۔ عام مقاصد کا ڈیفالٹ۔ |
| SHA-384 | 96 سولہ عددی حروف | محفوظ۔ |
| SHA-512 | 128 سولہ عددی حروف | محفوظ۔ 64-bit سسٹمز پر اکثر SHA-256 سے تیز۔ |
اگر آپ انتخاب کر رہے ہیں اور کوئی خاص تقاضا نہیں، تو SHA-256 استعمال کریں۔
MD5 اور SHA-1 اب تک یہاں کیوں موجود ہیں
دونوں خفیہ نگاری کے لحاظ سے ٹوٹ چکے ہیں، یعنی ایسے دو مختلف ان پٹ بنانا عملاً ممکن ہے جو ایک ہی ہیش دیں — اسے تصادم کہتے ہیں۔ MD5 کے لیے یہ برسوں سے عام ہارڈویئر پر کر کے دکھایا جا چکا ہے۔ SHA-1 کے لیے، Google اور CWI Amsterdam نے پہلا عملی تصادم 2017ء میں شائع کیا، اور تب سے یہ حملہ خاصا سستا ہو چکا ہے۔
تصادم اُس وقت اہمیت رکھتا ہے جب ہیش کو اصلیت کے ثبوت کے طور پر استعمال کیا جا رہا ہو، کیونکہ حملہ آور ایسی نقصان دہ فائل بنا سکتا ہے جس کا ہیش کسی جائز فائل سے مل جائے۔ یہ اُس وقت اہم نہیں جب ہیش محض ایک غیر مخاصمانہ چیک سم کے طور پر استعمال ہو رہا ہو — اتفاقی خرابی پکڑنا، فائلوں کی نقل ختم کرنا، کیش کی کلیدیں بنانا، یا ریکارڈ تقسیم کرنا۔ یہی وجہ ہے کہ دونوں الگورتھم اب بھی وسیع استعمال میں ہیں اور یہاں پیش کیے گئے ہیں۔
قاعدہ سادہ ہے۔ اگر کسی حملہ آور کو مطابق ہیش بنانے سے فائدہ ہو سکتا ہو، تو MD5 یا SHA-1 استعمال نہ کریں۔ اگر آپ صرف خراب ڈاؤن لوڈ یا نقل شدہ قطار سے بچاؤ کر رہے ہیں، تو دونوں میں سے کوئی بھی ٹھیک ہے۔
عبارت کا ہیش اور فائل کا ہیش
یہ ٹول دونوں سنبھالتا ہے۔ عبارت لکھیں یا پیسٹ کر کے براہِ راست اس کا ہیش بنائیں، یا کوئی فائل منتخب کر کے اس کے مواد کا ہیش بنائیں۔ فائل والا راستہ چیک سم کے موازنے کے لیے استعمال ہوتا ہے؛ کسی ڈاؤن لوڈ کی گئی ISO، انسٹالر یا آرکائیو کا ہیش بنا کر ناشر کا چیک سم موازنے کے خانے میں پیسٹ کرنے سے مطابقت کی تصدیق ہو جائے گی، یا صاف بتا دیا جائے گا کہ مطابقت نہیں ہے۔
عبارت کا ہیش بناتے وقت ایک چیز لوگوں کو دھوکہ دیتی ہے: آخر میں لگی خالی جگہ اور سطر کے اختتام کا طریقہ نتیجہ بدل دیتے ہیں۔ Windows کے CRLF سطر اختتام کے ساتھ محفوظ کی گئی فائل کا ہیش اُسی عبارت کے Unix LF اختتام والے نسخے سے مختلف ہوتا ہے، حالانکہ اسکرین پر دونوں ایک جیسی نظر آتی ہیں۔ اگر ہیش نہ ملے اور مواد ایک جیسا لگے، تو سب سے پہلے سطر کے اختتام دیکھیں۔
سب کچھ آپ کے براؤزر میں چلتا ہے۔ نہ عبارت اپ لوڈ ہوتی ہے نہ فائل، اور یہ بات اُس وقت اہم ہے جب آپ کسی خفیہ چیز کا ہیش بانٹنے کے بجائے تصدیق کے لیے بنا رہے ہوں۔
ہیش کس کام کے لیے نہیں ہیں
دو عام غلط استعمال بیان کرنے کے قابل ہیں۔
ہیشنگ خفیہ کاری نہیں ہے۔ خفیہ کاری کلید سے واپس کھولی جا سکتی ہے؛ ہیشنگ سرے سے واپس نہیں ہوتی۔ اگر آپ کو بعد میں اصل ڈیٹا واپس چاہیے ہو، تو آپ کو خفیہ کاری درکار ہے، ہیش نہیں۔
پاس ورڈ محفوظ کرنے کا طریقہ سادہ SHA-256 نہیں ہے۔ تیز ہیش فنکشن بالکل غلط اوزار ہیں، کیونکہ ان کی رفتار ہی وہ چیز ہے جو کسی حملہ آور کو چرائے ہوئے ڈیٹابیس کے خلاف فی سیکنڈ اربوں اندازے آزمانے دیتی ہے۔ پاس ورڈ محفوظ کرنے کے لیے جان بوجھ کر سست، سالٹ شدہ اور اسی مقصد کے لیے بنایا گیا الگورتھم درکار ہے — bcrypt، scrypt یا Argon2۔ پاس ورڈز کے لیے SHA-256 استعمال کرنا ایک معروف اور سنگین غلطی ہے۔