هل تستخدم حقًا SHA-3 أم رمزًا قديمًا؟

SHA-2 هي وظيفة تجزئة يتم الاستفادة منها بواسطة الكثير من أنظمة الإنترنت والتشفير الحالية (بما في ذلك TLS و SSL و SSH و Bitcoin). تم نشر SHA-2 في عام 2001 ولإكماله بأخرى جديدة ، أعلنت NIST عن مسابقة في عام 2007 لتحديد SHA-3. تم الإعلان عن تقديم فريق Keccak باعتباره الفائز في عام 2012 ، ومنذ ذلك الحين طبق المطورون “sha3” باستخدام هذا الإرسال (بما في ذلك Ethereum). ومع ذلك ، في عام 2014 ، قام NIST بإجراء تغييرات طفيفة على إرسال Keccak ونشر FIPS 202 ، والذي أصبح معيار SHA-3 الرسمي في أغسطس 2015. لذلك هناك الكثير من التعليمات البرمجية القديمة التي تسمي نفسها sha3 والتي لم يتم تحديثها إلى المعيار. تشرح هذه المقالة التناقض الواسع النطاق حاليًا مع “sha3” وتشجع المطورين على أن يكونوا أكثر دقة حول SHA-3 والكود الأقدم.

يجب أن تدرك أن الشفرة القديمة لن تنتج نفس تجزئة SHA-3. عند استخدام مكتبة “sha3” ، هل تعرف ما إذا كانت رمزًا قديمًا أم مكتبة SHA-3 القياسية؟

يتمثل الاختبار البسيط في استخدام إدخال فارغ لـ SHA3–256.

الناتج الصحيح حسب المعيار هو:

a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a

هناك الكثير من الرموز القديمة هي Keccak-256 والتي تنتج هذا الناتج:

c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470

هذا رمز يجب ألا يصف نفسه بـ sha3.

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

نريد استخدام مصطلح Keccak ، لأننا لا نريد إرباك المطورين الذين يستخدمون مكتبات SHA-3 القياسية ، ولماذا لا تتطابق تجزئات SHA-3 مع تجزئات “sha3” التي تم إنتاجها بواسطة السلوك القديم.

وبالمثل ، يُرجى عدم الاتصال بشيء ما بـ sha3 ما لم تتحقق من أنه SHA-3 حقًا. إذا افترضت أن مكتبة sha3 “القياسية” في لغة البرمجة الخاصة بك هي SHA-3 ، فقد تكون مخطئًا. على سبيل المثال ، في Javascript ، حزمة NPM المسماة sha3 ليست متوافقة بعد.

مكتبة أخرى لم يتم تحديثها هي CryptoJS الشهيرة. لسوء الحظ ، لا يذكر الملف التمهيدي في Github أي ذكر ، ويجب على المستخدم إلقاء نظرة على الموقع القديم للعثور على “ملاحظة: لقد ارتكبت خطأ عندما أطلقت على هذا التطبيق SHA-3. يجب أن يكون اسمه Keccak “. لذا فإن أي تابعين لـ CryptoJS يستخدم sha3 يستخدم رمزًا قديمًا يمكن وصفه بشكل أفضل بمصطلح مثل Keccak. احذر أيضًا من حاسبات sha3 عبر الإنترنت ، لأن بعضها لم يتم تحديثه إلى SHA-3.

للحصول على مثال صحيح ، راجع js-sha3. يمكنك أن ترى الفرق بين sha3 والسلوك القديم واختباره المحدث.

تقول NIST أن “اختبار SHA-3 قيد التطوير” ، ولكن لحسن الحظ لديهم أمثلة اختبار وتؤكد أن SHA3–256 لإدخال فارغ هو:

a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a

(للأسف ، لم تقم NIST بتحديث شهادة SSL لمدة عامين تقريبًا.)

ما ورد أعلاه هو دعوة لجميع مشاريع مكتبة “sha3” ، لتوضيح ما إذا كانت الشفرة ليست SHA-3 ، وما هي الخطط للتحديث إلى المعيار. يجب أن تفكر المشروعات التابعة أيضًا في توضيح قاعدة الرموز الخاصة بها ، أو التحديث إلى المكتبات التي تستخدم SHA-3.

إلى مجتمع Ethereum

تستخدم Ethereum نفس الخوارزمية الأساسية المستخدمة في SHA-3 ، وبالتالي فهي تستفيد من أمانها ، لكن بروتوكولها يستخدم إصدارًا من الخوارزمية يختلف قليلاً عن FIPS 202. يشير Ethereum Yellow Paper على وجه التحديد ” وظيفة تجزئة Keccak-256 (وفقًا للمشاركة الفائزة في مسابقة SHA-3). “

في تفاعلاتنا ، دعنا نصف ما نستخدمه بدقة أكبر. لا نريد إرباك المطورين الذين يستخدمون مكتبات SHA-3 القياسية ، فلماذا لا تتطابق تجزئات SHA-3 مع تجزئات Ethereum. عندما يخبرنا أحدهم أنه يستخدم “sha3” ، لا نريد أن نتساءل عما إذا كانوا يقصدون حقًا SHA-3 أو Keccak-256 – لذلك فلنكن أكثر دقة فيما نقول للآخرين. في Solidity و web3.js و EVM والوثائق ، يجب أن نفكر في إعادة التسمية / التعيين بعيدًا عن “sha3” ، ربما باستخدام مصطلح مثل “ksha3” إذا كان “keccak” غير عملي.

للجميع

إذا كانت شفرتك غير متوافقة مع معيار SHA-3 ، فيرجى توضيح أنها ليست SHA-3. نظرًا لانتشار التشفير على نطاق واسع ، سيشكرك المطورون الآن وفي المستقبل على تقليل الالتباس.

جوزيف تشاو ، كونسينسيس





المراجع

[1] “استخدم التجزئة الخاطئة ، وفقد كل أموالك!” ملصق أصلي قديم للحرب العالمية الثانية بقلم جون باروت
[2] صورة رقصة الكيكاك بواسطة Chang’r
[3] من “SHA3 انتهى. تحيا SHA3! ” http://blog.cryptographyengineering.com/2012/10/long-live-sha3.html