متى يكون ضارًا للتجزئة

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

يتم فهم تعقيد الاسترداد على أنه حقيقة أنه من أجل العثور على النموذج الأولي [دالة تجزئة تشفير موثوقة] ، يلزم إكمال متوسط ​​لا يقل عن $$$2 ^ {n-1}$عمليات التجزئة حيث $$$ن$- عدد البتات في إخراج وظيفة تجزئة التشفير. بأخذ دالة هاش حديثة ذات حجم إخراج كبير (يبدأ من 256 بت) ، فإن مطور نظام المعلومات متأكد من أنه من المستحيل استعادة البيانات الأصلية من قيمة دالة التجزئة. في معظم الأحيان كان على حق.

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

مثال: رقم الهاتف . أرقام الهواتف المختلفة مع البادئة "+7" و 10 أرقام هي $$$10 ^ {10} \ approx 2 ^ {33}$. تقوم الأجهزة الحديثة التي تم تحسينها للتكرار على قيم التجزئة بفرز الملايين من التجزئة في الثانية. هذا يعني أن حساب قيم وظائف التجزئة لجميع أرقام الهواتف الممكنة مع بادئة لا يزيد عن بضع ثوان.

مثال: رقم بطاقة الائتمان (PAN ، رقم بطاقة الدفع ). غالبًا ما يكون رقم البطاقة مقنعا ، ويكشف عن أول 4 (6) و / أو آخر 4 أرقام ، بينما يخفي الباقي. يوجد 16 رقمًا على البطاقة ، هل يمكن تجميع أرقام البطاقات لإخفائها عن المهاجم؟ لا. إذا تلقى المهاجم 8 أرقام من 16 (أول 4 وأخير 4) ، وكذلك قيمة دالة التجزئة من رقم البطاقة الكامل ، فيمكنه استرداد الرقم الكامل في أقل من ثانية. للقيام بذلك ، سوف يحتاج إلى فرز كل شيء $$$10 ^ {8} \ approx 2 ^ {26}$خيارات الرقم.

مثال مثير للاهتمام مع عنوان البريد الإلكتروني . يبدو أنه من خلال قيمة دالة هاش موثوقة ، من المستحيل استعادة العنوان الأصلي. عدد المتغيرات المختلفة من 8 أحرف لاتينية و 10 خانات تعطي بالفعل $$$36 ^ 8 \ approx 2 ^ {41}$خيارات لأسماء صناديق البريد دون مراعاة مختلف مجالات خدمات البريد ( @mail.ru ، @gmail.com ، إلخ). إذا كنت تأخذ أحرفًا مسموحًا بها أخرى ، بالإضافة إلى إطالة العنوان ، فهناك المزيد من الخيارات. لكن ... حتى عام 2006 ، نجح مشروع Blue Frog (Blue Frog) ، والذي قدم لمستخدميها حماية ضد البريد العشوائي. لقد استخدم إشعارًا تلقائيًا لموفري الخدمات حول البريد العشوائي المرسل من خوادمهم ، مما أجبر المعلنين على رفض إرسال البريد العشوائي إلى العناوين التي شاركوا في المشروع على الأقل. لفهم ما إذا كان المربع ينتمي إلى المشارك أم لا ، تم توزيع ملف مع قائمة قيم وظيفة تجزئة التشفير من عنوان صندوق بريد كل عضو.

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

كما كان من قبل ، لا يؤثر استخدام أي ملح يأتي مع قيمة دالة التجزئة على وقت التعداد (ولكنه لا يزال يحمي من هجمات القاموس).

الحلول الممكنة للحالات الموصوفة.

1. لا تجزئ القيم نفسها ، بل تسلسل القيمة الأصلية وبعض السر المخزن بشكل منفصل. على سبيل المثال ، ليس في جدول قاعدة البيانات (جنبًا إلى جنب مع قيم وظائف التجزئة) ، ولكن في تكوين خادم التطبيق. بنجاح مماثل ، بدلاً من التجزئة ، يمكنك استخدام وظيفة تشفير البلوك في مفتاح سري.
2. استخدم وظائف التجزئة التي لا يمكن الاعتماد عليها فحسب ، ولكن أيضًا بطيئة في الحوسبة. سواء بالنسبة ل cryptanalyst وللمستخدم القانوني. مثال على هذه الوظائف هو PBKDF2 ، bcrypt ، scrypt ، Argon2 ، والتي ، عند استدعاء دالة ، نشير بالإضافة إلى ذلك إلى عدد مرات تكرار التجزئة. ومع ذلك ، إذا كانت زيادة طول ناتج دالة التجزئة ببت واحد فقط (من 256 أو 512) تزيد من تعقيد هجوم المشفر بواسطة أمر ثنائي (بعامل اثنين) ، فإن زيادة عدد التكرارات لوظيفة دالة التجزئة PBKDF2 سوف يضاعف من تعقيد الهجمات بواسطة اثنين فقط مرات. وهذا يعني أن الحصول على قيمة تجزئة حتى بواسطة مستخدم قانوني يصبح مكلفًا من حيث موارد الحوسبة والطاقة المستهلكة.