دوال التجزئة موجودة في كل مكان في تطوير البرمجيات، حتى لو لم تدرك ذلك. في كل مرة تقوم فيها بتحميل ملف والتحقق من مجموعه الاختباري، أو تسجيل الدخول إلى موقع ويب، أو عمل commit في Git، أو تعدين البيتكوين (حسناً، ربما ليس هذا الأخير)، فإن دوال التجزئة تقوم بالعمل الشاق وراء الكواليس.

دعنا نفهم ماهيتها، وكيف تختلف، ومتى نستخدم كل واحدة.

ما هي دالة التجزئة؟

دالة التجزئة تأخذ أي مدخل — حرف واحد، رواية، ملف فيديو بحجم 4 غيغابايت — وتنتج مخرجاً بحجم ثابت يسمى "هاش" أو "خلاصة". فكر فيها كبصمة إصبع للبيانات. مهما كان حجم المدخل كبيراً أو صغيراً، فإن المخرج دائماً بنفس الطول.

إليك ما يجعل دوال التجزئة مميزة:

  • حتمية: نفس المدخل يعطي دائماً نفس المخرج. hash("hello") سيعيد نفس القيمة في كل مرة، على أي جهاز، وبأي لغة برمجة.
  • أحادية الاتجاه: لا يمكنك عكس هندسة المدخل من المخرج. بمعلومية الهاش، لا توجد طريقة لمعرفة ما أنتجه (بخلاف التخمين). هذا ما يجعلها مفيدة لتخزين كلمات المرور.
  • تأثير الانهيار: غيّر بتاً واحداً في المدخل، ويتغير المخرج بشكل جذري. على سبيل المثال، هاش SHA-256 لـ "hello" و "Hello" هما سلسلتان مختلفتان تماماً.
  • مقاومة التصادم: يجب أن يكون من المستحيل عملياً إيجاد مدخلين مختلفين ينتجان نفس الهاش. كلما كانت الخوارزمية أقوى، كان إيجاد التصادمات أصعب.

دعنا نراها عملياً:

plaintext

مخرجات مختلفة تماماً من مدخلات تختلف بحرف واحد فقط — حرف "h" صغير مقابل حرف "H" كبير. هذا هو تأثير الانهيار في العمل.

كيف تعمل دوال التجزئة تحت الغطاء

بينما الرياضيات وراء دوال التجزئة معقدة، فإن العملية العامة واضحة. معظم دوال التجزئة تتبع هذه الخطوات:

1. الحشو (Padding): يتم حشو رسالة المدخل بحيث يصبح طولها مضاعفاً لحجم كتلة ثابت (مثل 512 بت لـ SHA-256). هذا يضمن أن الخوارزمية تستطيع معالجة البيانات في أجزاء موحدة.

2. تقسيم الكتل: يتم تقسيم الرسالة المحشوة إلى كتل بحجم ثابت.

3. جولات الضغط: كل كتلة تتم معالجتها عبر جولات متعددة من العمليات على مستوى البت — XOR و AND و OR والإزاحات البتية والجمع المعياري. هذه العمليات تمزج البتات بشكل شامل بحيث يعتمد كل بت مخرج على كل بت مدخل.

4. التسلسل: مخرج معالجة كتلة واحدة يغذي معالجة الكتلة التالية. لهذا السبب حتى تغيير صغير في بداية المدخل يتتالى عبر كل كتلة لاحقة.

5. الخلاصة النهائية: بعد معالجة جميع الكتل، يتم إخراج الحالة الداخلية كقيمة الهاش النهائية.

الفكرة الرئيسية هي أن هذه العمليات سهلة الحساب للأمام لكن مستحيلة عملياً للعكس. لا يمكنك "فك مزج" البتات لاستعادة المدخل الأصلي.

MD5: المخضرم المتقاعد

تم تصميم MD5 بواسطة رونالد ريفست في عام 1991 وينتج هاش بحجم 128 بت (32 حرف ست عشري). كان الخيار الأول لعقود — كنت ترى مجاميع MD5 الاختبارية بجانب كل تحميل ملف على الإنترنت.

ومع ذلك، أصبح MD5 الآن مكسوراً تشفيرياً. أظهر الباحثون هجمات تصادم عملية — مما يعني أنهم يستطيعون إنشاء ملفين مختلفين ينتجان نفس هاش MD5. في عام 2008، استخدم الباحثون تصادم MD5 لإنشاء شهادة SSL مزيفة، مثبتين أن هذا لم يكن مجرد ضعف نظري.

لا يزال مقبولاً لـ: فحوصات سلامة الملفات (التحقق من اكتمال التحميل بشكل صحيح)، ومجاميع التحقق لإزالة التكرار، وجداول الهاش غير الأمنية، وبصمات البيانات السريعة حيث لا يكون الأمان مصدر قلق.

لا تستخدمه أبداً لـ: تخزين كلمات المرور، أو التوقيعات الرقمية، أو شهادات الأمان، أو أي شيء حيث قد يقوم شخص ما بإنشاء تصادمات عمداً.

SHA-1: متقاعد أيضاً

تم تصميم SHA-1 بواسطة وكالة الأمن القومي ونُشر في عام 1995. ينتج هاش بحجم 160 بت (40 حرف ست عشري). لسنوات كان المعيار في شهادات SSL وتوقيعات PGP وأنظمة التحكم في الإصدارات.

تم إهماله بعد أن أظهرت Google هجوم تصادم عملي في عام 2017 (هجوم SHAttered الشهير). أنشأوا ملفي PDF مختلفين بنفس هاش SHA-1. تطلب الهجوم 9,223,372,036,854,775,808 عملية حساب SHA-1 — هائل، لكنه ممكن بموارد الحوسبة السحابية الحديثة.

لا يزال Git يستخدم SHA-1 داخلياً لهاشات commits، لكنه ينتقل إلى SHA-256. توقفت المتصفحات وسلطات الشهادات عن قبول شهادات SHA-1 منذ سنوات. إذا رأيت SHA-1 يُستخدم للأمان في أي كود اليوم، يجب تمييزه وترحيله.

SHA-256 و SHA-512: المعايير الحالية

هذه جزء من عائلة SHA-2، التي صممتها وكالة الأمن القومي ونُشرت في عام 2001. هذا ما يجب أن تستخدمه اليوم لمعظم الأغراض.

  • SHA-256: مخرج 256 بت (64 حرف ست عشري). يُستخدم في البيتكوين وشهادات TLS ومعظم تطبيقات الأمان. إنه التوازن المثالي بين الأمان والأداء. نظام إثبات العمل بالكامل في البيتكوين مبني على تجزئة SHA-256 المزدوجة.
  • SHA-512: مخرج 512 بت (128 حرف ست عشري). مخرج أكبر يعني مقاومة أكبر للتصادم. من المثير أن SHA-512 غالباً أسرع من SHA-256 على المعالجات 64 بت لأنه يعمل بكلمات 64 بت أصلياً، بينما SHA-256 يستخدم كلمات 32 بت.
  • SHA-384 و SHA-512/256: هذه متغيرات مقتطعة من SHA-512. SHA-384 يعطيك مخرج 384 بت، بينما SHA-512/256 يعطي مخرج 256 بت لكن بمزايا أداء عمليات 64 بت لـ SHA-512.

مقارنة سريعة:

plaintext

SHA-3: الجيل التالي

تم توحيد معايير SHA-3 في عام 2015 بعد مسابقة عامة أدارها NIST. على عكس SHA-2 الذي يستخدم بنية Merkle-Damgard، فإن SHA-3 مبني على بنية الإسفنجة Keccak — تصميم مختلف جذرياً.

لماذا هذا مهم؟ إذا أدى اختراق رياضي إلى اختراق نهج تصميم SHA-2، فلن يتأثر SHA-3 لأنه يعمل بشكل مختلف تماماً. إنه بوليصة تأمين لمجتمع التشفير.

يأتي SHA-3 بنفس أحجام المخرجات — SHA3-256 و SHA3-384 و SHA3-512 — ويقدم أيضاً SHAKE128 و SHAKE256، وهي "دوال مخرجات قابلة للتمديد" يمكنها إنتاج هاش بأي طول مطلوب.

عملياً، لا يزال SHA-2 أكثر استخداماً وأسرع على معظم الأجهزة. اعتماد SHA-3 ينمو، لكنه معيار احتياطي أكثر منه بديل.

حالات الاستخدام في العالم الحقيقي

التحكم في الإصدارات Git: كل commit وشجرة وblob في Git يتم تعريفه بهاش SHA-1 الخاص به. عندما تنفذ git commit، يقوم Git بتجزئة محتوى تغييراتك، وبنية الشجرة، وهاش commit الأب، ومعلومات المؤلف، والطابع الزمني. لهذا السبب تبدو هاشات commits مثل a1b2c3d4e5f6... — فهي حرفياً خلاصات SHA-1.

تعدين البيتكوين: يتنافس المعدنون لإيجاد قيمة nonce التي، عند دمجها مع بيانات الكتلة وتجزئتها بـ SHA-256 المزدوج، تنتج هاش أقل من عتبة محددة. صعوبة إيجاد هذا الهاش هي ما يؤمن الشبكة بأكملها. اعتباراً من 2024، تحسب شبكة البيتكوين حوالي 500 كوينتيليون هاش SHA-256 في الثانية.

إزالة تكرار الملفات: خدمات التخزين السحابي مثل Dropbox تقوم بتجزئة كل ملف تحمله. إذا تطابق الهاش مع ملف موجود، فإنها لا تخزن نسخة مكررة — بل تضيف مؤشراً فقط. هذا يوفر كميات هائلة من مساحة التخزين.

التوقيعات الرقمية: عندما توقع مستنداً أو إصدار برنامج، فأنت لا توقع الملف بأكمله. بدلاً من ذلك، يتم تجزئة الملف، والهاش هو ما يتم توقيعه بمفتاحك الخاص. المستلم يقوم بتجزئة الملف بنفسه ويتحقق من التوقيع مقابل ذلك الهاش.

مصادقة API: يجمع HMAC (رمز مصادقة الرسائل المبني على الهاش) بين مفتاح سري وهاش رسالة للتحقق من سلامة وأصالة طلبات API. تستخدم AWS و Stripe ومعظم واجهات API الرئيسية HMAC-SHA256 لتوقيع الطلبات.

أخطاء شائعة يرتكبها المطورون مع التجزئة

استخدام دوال التجزئة لكلمات المرور: SHA-256 العادي سريع جداً لتجزئة كلمات المرور. مهاجم بـ GPU يمكنه حساب مليارات هاشات SHA-256 في الثانية، مما يجعل هجمات القوة الغاشمة تافهة. استخدم دائماً دوال تجزئة كلمات مرور مخصصة مثل bcrypt أو scrypt أو Argon2، وهي بطيئة عمداً وتستهلك ذاكرة كبيرة.

عدم استخدام ملح (salt): إذا قمت بتجزئة كلمات المرور بدون ملح (قيمة عشوائية تضاف لكل كلمة مرور قبل التجزئة)، فإن كلمات المرور المتطابقة تنتج هاشات متطابقة. مهاجم بـ "جدول قوس قزح" محسوب مسبقاً يمكنه البحث عن كلمات المرور الشائعة فوراً. أضف دائماً ملحاً فريداً وعشوائياً لكل مستخدم.

مقارنة الهاشات بطريقة غير آمنة زمنياً: استخدام == لمقارنة الهاشات في كود حساس أمنياً يمكن أن يسرب معلومات عبر القنوات الجانبية الزمنية. يمكن للمهاجم قياس مدة المقارنة واستنتاج الهاش حرفاً بحرف. استخدم دوال المقارنة ذات الوقت الثابت مثل crypto.timingSafeEqual() في Node.js أو hmac.compare_digest() في Python.

اقتطاع الهاشات: بعض المطورين يقتطعون الهاشات لتوفير المساحة (مثل تخزين أول 16 حرفاً فقط من هاش SHA-256). هذا يقلل بشكل كبير من مقاومة التصادم. هاش SHA-256 الكامل لديه 2^256 قيمة ممكنة؛ الاقتطاع إلى 16 حرف ست عشري يترك فقط 2^64 — رقم يمكن للأجهزة الحديثة كسره بالقوة الغاشمة.

أي دالة تجزئة يجب استخدامها؟

  • سلامة الملفات (بدون أمان): SHA-256 أو حتى MD5 كافٍ. أنت تتحقق من التلف العرضي، وليس التلاعب الخبيث.
  • تخزين كلمات المرور: لا شيء من هذه! استخدم bcrypt أو scrypt أو Argon2 — فهي بطيئة عمداً، مما يجعل هجمات القوة الغاشمة غير عملية. دوال التجزئة العادية سريعة جداً لتجزئة كلمات المرور.
  • التوقيعات الرقمية والشهادات: SHA-256 أو SHA-512.
  • HMAC (مصادقة الرسائل): SHA-256 أو SHA-512.
  • عنونة المحتوى بنمط Git: SHA-256 (حيث يتجه Git).
  • التحصين للمستقبل: إذا كنت تبني نظاماً يحتاج للبقاء لعقود وتريد خطة احتياطية في حالة اختراق SHA-2، فكر في SHA-3.
  • مجاميع التحقق في خطوط أنابيب البيانات: SHA-256 للتحقق من سلامة البيانات بين مراحل خط الأنابيب. CRC32 أسرع لكنه يكتشف الأخطاء العرضية فقط، وليس التلاعب المتعمد.

دوال التجزئة في الكود: أمثلة عملية

حسناً، كفى نظريات — لنكتب بعض الكود. لأنه بصراحة، أفضل طريقة لفهم التجزئة هي ببساطة... القيام بها. إليك كيف تحسب الهاشات في اللغات التي ربما تستخدمها كل يوم.

Node.jsوحدة crypto المدمجة تجعل هذا بسيطاً للغاية:

javascript

والجزء الرائع — تجزئة ملف تكاد تكون نفس الشيء:

javascript

Pythonhashlib في Python بنفس البساطة. في الواقع أعتقد أن Python لديها أجمل واجهة برمجية لهذا:

python

Go — المكتبة القياسية في Go مصممة بشكل ممتاز لهذا:

go

Java — أكثر إسهاباً بقليل (لأن... Java)، لكنها تعمل بشكل ممتاز:

java

التحقق من تحميل ملف: هذا أحد أكثر الاستخدامات العملية للتجزئة. لنقل أنك حملت ISO لينكس والموقع يقول أن مجموع SHA-256 الاختباري يجب أن يكون abc123.... إليك كيف تتحقق:

bash

أعلم أن هذا يبدو بسيطاً، لكنك ستندهش من عدد المطورين الذين يتخطون هذه الخطوة. بايت واحد تالف في تحميل 4 غيغابايت يمكن أن يضيع عليك فترة ما بعد الظهر بأكملها.

جداول قوس القزح ولماذا هي مرعبة

حسناً، هذا الجزء الذي فجر ذهني عندما تعلمته لأول مرة. تخيل أن شخصاً ما يحسب مسبقاً الهاش لكل كلمة مرور ممكنة حتى، لنقل، 8 أحرف. كل مجموعة من الحروف والأرقام والرموز. يخزنون كل هذه التعيينات من الهاش إلى كلمة المرور في جدول بحث عملاق.

هذا هو جدول قوس القزح. وهي مرعبة تماماً.

إليك السبب: إذا خزنت كلمات المرور كهاشات SHA-256 عادية (بدون ملح)، فإن المهاجم الذي يحصل على قاعدة بياناتك لا يحتاج لـ "كسر" أي شيء. يبحث ببساطة عن كل هاش في جدول قوس القزح الخاص به. بوم — استعادة فورية لكلمة المرور. البحث يستغرق ميكروثوانٍ.

ما حجم هذه الجداول؟ جدول قوس قزح يغطي جميع كلمات المرور الأبجدية الرقمية حتى 8 أحرف يمكن أن يكون حوالي 100-200 غيغابايت. يبدو كثيراً، لكن هذا يتسع على قرص SSD واحد. مواقع مثل CrackStation لديها جداول بمليارات الهاشات المحسوبة مسبقاً، وتكسر هاشات كلمات المرور الشائعة في ثوانٍ مجاناً.

والآن الخبر السار: التمليح يهزم جداول قوس القزح تماماً. الملح هو مجرد سلسلة عشوائية تضيفها لكلمة المرور قبل التجزئة:

plaintext

هل رأيت ما حدث؟ نفس كلمة المرور ("password123") تنتج هاشات مختلفة تماماً بسبب الأملاح المختلفة. سيحتاج المهاجم لبناء جدول قوس قزح منفصل لكل ملح ممكن، وهو مستحيل حسابياً.

كل مكتبة حديثة لتجزئة كلمات المرور (bcrypt، Argon2، scrypt) تتعامل مع التمليح تلقائياً. إذا أغراك يوماً أن تكتب تجزئة كلمات المرور الخاصة بك — لا تفعل. بجدية. استخدم bcrypt وامضِ في حياتك.

HMAC: التجزئة بسر

HMAC يعني رمز مصادقة الرسائل المبني على الهاش، وأعلم أن هذا يبدو مخيفاً. لكن تحمّل معي — إنه في الواقع مفهوم بسيط جداً ربما استخدمته دون أن تدرك.

التجزئة العادية تأخذ رسالة وتنتج هاش. HMAC يأخذ رسالة ومفتاح سري وينتج هاش. الفرق الجوهري هو أن الشخص الذي يعرف المفتاح السري فقط يمكنه إنتاج أو التحقق من HMAC. يثبت شيئين في وقت واحد: الرسالة لم يتم التلاعب بها، وجاءت من شخص يعرف السر.

أين ترى هذا في العالم الحقيقي؟ توقيعات webhooks. عندما يرسل GitHub أو Stripe webhook إلى خادمك، يتضمنون توقيع HMAC-SHA256 في الرؤوس. يمكن لخادمك التحقق من أن webhook جاء فعلاً من GitHub (ولم يتم تزييفه من مهاجم عشوائي) بحساب HMAC بنفسك والمقارنة.

إليك مثالاً عملياً للتحقق من توقيع webhook GitHub في Node.js:

javascript

هل لاحظت استدعاء timingSafeEqual؟ هذا حاسم. المقارنة العادية بـ === تعيد false بمجرد أن تجد أول حرف غير متطابق، مما يعني أن المهاجم يمكنه قياس وقت الاستجابة واستنتاج التوقيع بايت ببايت. المقارنة الآمنة زمنياً تستغرق دائماً نفس الوقت بغض النظر عن مكان عدم التطابق.

معايير أداء دوال التجزئة

أنا أفهم — الأداء مهم. خاصة إذا كنت تقوم بتجزئة ملايين الملفات في خط أنابيب البناء أو تعالج تيار بيانات. إليك كيف تقارن دوال التجزئة الرئيسية من حيث السرعة (معايير تقريبية على أجهزة x86_64 حديثة):

plaintext

انتظر، هل لاحظت ذلك؟ BLAKE3 أسرع 10 مرات من SHA-256 مع كونه آمناً تشفيرياً. هذا ليس خطأ مطبعياً.

BLAKE3 هو الأحدث والأفضل في عالم التجزئة، ولسبب وجيه. يعتمد على عائلة BLAKE2 (التي تفوقت بالفعل على SHA-3 في مسابقة NIST) لكنه أُعيد تصميمه للاستفادة من التوازي SIMD والخيوط المتعددة. يمكنه تجزئة البيانات بسرعة memcpy تقريباً.

لماذا يجب أن تهتم؟ أدوات البناء تهتم. كثيراً. أدوات مثل Bazel و Buck وأنظمة التخزين المعنونة بالمحتوى المختلفة تقضي وقتاً مذهلاً في تجزئة الملفات. التحول من SHA-256 إلى BLAKE3 يمكن أن يسرع فحص التبعيات بمقدار عشرة أضعاف. نظام Rust البيئي يتبنى BLAKE3 بقوة، ويظهر في المزيد والمزيد من الأماكن.

ومع ذلك، SHA-256 و SHA-512 لا يزالان الخيار الصحيح عندما تحتاج توافقاً واسعاً أو الامتثال لمعايير مثل FIPS. ليس كل شيء يدعم BLAKE3 بعد، وفي كثير من حالات الاستخدام، سرعة التجزئة ليست العنق الزجاجي على أي حال.

البلوكتشين وأشجار ميركل: التجزئة على نطاق واسع

حسناً، هنا حيث يصبح الأمر رائعاً حقاً. هل تعرف كيف يمكن لـ Git إخبارك بالضبط أي ملف تغير في مستودع ضخم؟ وكيف يمكن للبيتكوين التحقق من معاملة دون تحميل البلوكتشين بالكامل؟ السر هو بنية بيانات تسمى شجرة ميركل (سميت على اسم رالف ميركل الذي سجل براءة اختراعها في عام 1979).

شجرة ميركل هي أساساً شجرة من الهاشات. إليك كيف تعمل — تخيل أن لديك أربع كتل بيانات:

plaintext

كل عقدة ورقة هي هاش كتلة بيانات. كل عقدة أب هي هاش أطفالها المتسلسلين معاً. هاش الجذر (يسمى أحياناً "جذر ميركل") هو هاش واحد يمثل جميع البيانات في الشجرة.

إليك الجزء الأنيق حقاً: إذا تغير حتى بت واحد من Data C، يتغير Hash(C)، مما يعني تغير Hash(CD)، مما يعني تغير Root Hash. يمكنك اكتشاف التلاعب فوراً بمجرد فحص الجذر.

لكنها تتحسن أكثر. لنقل أنك تريد إثبات أن Data C جزء من الشجرة دون الكشف عن Data A أو B أو D. تحتاج فقط لتقديم: Data C و Hash(D) و Hash(AB). يمكن للمتحقق إعادة بناء المسار إلى الجذر والتحقق من تطابقه. هذا يسمى "إثبات ميركل"، وهو فعال بشكل لا يصدق — لشجرة بمليون ورقة، الإثبات يتكون من حوالي 20 هاش فقط (log2 من 1,000,000).

أين يُستخدم هذا عملياً؟

  • Git: مستودعك بالكامل هو شجرة ميركل. commits تشير إلى أشجار، والأشجار تشير إلى blobs، وكل شيء يُعرّف بهاش SHA-1 الخاص به. لهذا يمكن لـ Git معرفة فوراً إذا تغير أي شيء.
  • البيتكوين: كل كتلة تحتوي على جذر ميركل لجميع المعاملات. العملاء الخفيفون (مثل المحافظ المحمولة) يمكنهم التحقق من معاملة محددة باستخدام إثبات ميركل دون تحميل الكتلة الكاملة.
  • IPFS: نظام الملفات بين الكواكب يقسم الملفات إلى أجزاء، ويبني Merkle DAG (رسم بياني موجه غير دوري)، ويستخدم هاش الجذر كمعرف محتوى (CID) للملف.
  • Certificate Transparency: سجلات شفافية الشهادات من Google تستخدم أشجار ميركل حتى يتمكن أي شخص من التحقق بكفاءة مما إذا كانت شهادة قد تم تسجيلها (أو لم تُسجل).

المستقبل: دوال التجزئة ما بعد الكم

ربما سمعت أن الحواسيب الكمومية ستكسر كل تشفيرنا. ونعم، هذا صحيح جزئياً — RSA و ECC و Diffie-Hellman كلها ستنتهي بمجرد وصول الحواسيب الكمومية واسعة النطاق. خوارزمية شور يمكنها تحليل الأعداد الكبيرة وحساب اللوغاريتمات المنفصلة بكفاءة، وهو ما تعتمد عليه هذه الأنظمة.

لكن إليك الخبر السار المفاجئ: دوال التجزئة آمنة فعلاً إلى حد كبير ضد الحواسيب الكمومية. التهديد الكمومي الرئيسي لدوال التجزئة هو خوارزمية غروفر، التي يمكنها البحث في مساحة غير منظمة بشكل أسرع تربيعياً. عملياً، هذا يعني أنها تنصف بتات الأمان — SHA-256 ينخفض من 2^256 إلى 2^128 قوة ضد الهجمات الكمومية.

2^128 لا يزال رقماً هائلاً تماماً. هذا تقريباً عدد الذرات في الكون المرصود مربعاً. لن يكسر أحد هذا بالقوة الغاشمة، حاسوب كمومي أم لا.

لذلك بينما يعمل NIST بنشاط على معايير التشفير ما بعد الكم (وأنهى عدة معايير في 2024)، فإن الإلحاح يتركز بشكل رئيسي حول تشفير المفتاح العام والتوقيعات — وليس دوال التجزئة. إذا كنت تستخدم SHA-256 اليوم، يمكنك النوم بهدوء مع العلم أن الحواسيب الكمومية لن تجعله عديم الفائدة.

ومع ذلك، إذا كنت حقاً من النوع الحذر (وفي التشفير، الحذر فضيلة)، فإن الانتقال إلى SHA-512 أو SHA3-256 يمنحك هامش أمان إضافي. بعض مخططات التوقيع ما بعد الكم مثل SPHINCS+ مبنية بالكامل على دوال التجزئة، وهو تصويت ثقة جميل في مقاومتها الكمومية.

تصادمات الهاش: شرح هجوم عيد الميلاد

لنتحدث عن واحدة من أكثر الأشياء غير البديهية في علوم الحاسوب: هجوم عيد الميلاد. سُمي على اسم مفارقة عيد الميلاد، وهو السبب في أن دوال التجزئة تحتاج أن تكون أكبر مما تتوقعه بديهياً.

إليك مفارقة عيد الميلاد: في غرفة بها 23 شخصاً فقط، هناك احتمال 50% أن اثنين منهم يشتركان في نفس يوم الميلاد. ليس يوم ميلاد محدد — فقط أي زوج متطابق. مع 70 شخصاً، يقفز الاحتمال إلى 99.9%. معظم الناس يخمنون أنك تحتاج حوالي 183 شخصاً (نصف 365)، لكن الرقم الفعلي أقل بكثير لأننا نبحث عن أي تصادم، وليس تصادماً محدداً.

نفس الرياضيات بالضبط تنطبق على دوال التجزئة. إذا كانت دالة التجزئة تنتج N مخرج ممكن، فلا تحتاج لحساب N هاش لإيجاد تصادم — تحتاج فقط تقريباً الجذر التربيعي لـ N.

لهاش 256 بت مثل SHA-256، هناك 2^256 مخرج ممكن. إيجاد تصادم يتطلب تقريباً 2^128 عملية (الجذر التربيعي لـ 2^256). هذا لا يزال رقماً مستحيلاً — لكنه السبب في أننا لا نستطيع مجرد استخدام هاش 64 بت والاكتفاء بذلك.

plaintext

هذا بالضبط لماذا انهار MD5 (128 بت). مقاومته للتصادم كانت فقط 2^64 من البداية، ونقاط الضعف الهيكلية في الخوارزمية أنقصتها أكثر. وجد الباحثون في النهاية تصادمات في ثوانٍ على لابتوب عادي.

الخلاصة العملية؟ استخدم دائماً دالة تجزئة 256 بت على الأقل لأي شيء متعلق بالأمان. SHA-256 أو SHA3-256 أو BLAKE3 كلها خيارات ممتازة. وإذا اقترح شخص ما استخدام هاش 64 بت أو 128 بت لأغراض أمنية، الآن تعرف بالضبط لماذا هذه فكرة سيئة.

جربها بنفسك

هل تريد معرفة هاش بياناتك؟ استخدم مولد هاش MD5 أو مولد هاش SHA-256 أو مولد هاش SHA-512. الصق نصاً وشاهد كيف أن أصغر التغييرات تنتج هاشات مختلفة تماماً — إنها أفضل طريقة لبناء حدسك حول كيفية عمل هذه الخوارزميات.