الأدوات
الأدلة

مولّد HMAC

التشفير

احسب توقيعات HMAC-SHA-1/256/384/512 عبر Web Crypto. الإخراج Hex أو Base64، بالكامل داخل متصفحك.

100% من جهة العميل بدون خادم خلفي

لا يتم جلب الروابط البعيدة؛ الصق JSON مباشرة.

أدخل رسالة ومفتاحًا سريًا لحساب HMAC.
HMAC
لا يغادر مفتاحك السري المتصفح إطلاقًا.
في هذه الصفحة

ما هو HMAC؟#

HMAC اختصار لـ Hash-based Message Authentication Code (رمز مصادقة الرسائل المعتمد على الهاش). الهاش المجرّد (مثل SHA-256) يجيب عن سؤال «هل تغيّر تيار البايتات هذا؟». أمّا HMAC فيجيب عن سؤال أقوى: «هل تغيّر تيار البايتات هذا، و هل أُرسل من طرف يشاركني فعلًا المفتاح السري؟». يهمّ الفرق كلّما سافرت رسالة عبر قناة لا تثق بها ثقةً تامّة — استدعاءات webhook الخلفية، والعناوين الموقَّعة، وتوقيع طلبات الواجهات البرمجية، والرموز بين الخدمات.

ميكانيكيًّا، يخلط HMAC المفتاح السري في دالة الهاش بطريقة معرَّفة (جولتان مع حشو) فلا يمكن تزييف الملخّص بلا المفتاح. المخرج سلسلة بايتات بطول ثابت يطابق الهاش الأساسي: 20 بايتًا لـ SHA-1، و32 لـ SHA-256، و48 لـ SHA-384، و64 لـ SHA-512.

تحسب هذه الصفحة HMAC داخل متصفحك عبر واجهة Web Crypto. تختار الهاش، وتلصق الرسالة والسرّ، فتحصل على الملخّص بصيغة hex أو base64.

كيفية الاستخدام#

  1. اكتب أو الصق الرسالة — الحمولة التي تريد مصادقتها. هذه هي البايتات التي سيُجزّئها المستلم في طرفه.
  2. أدخل المفتاح السري. الحقل مقنّع افتراضيًا؛ انقر زرّ العين على اليمين لكشفه أثناء الكتابة. يُرمَّز كلٌّ من المفتاح والرسالة بصيغة UTF-8.
  3. اختر الخوارزمية:
    • SHA-1 — 160-بت. سريع، لكنه يصلح فقط لـ HMAC القديم (بعض تدفقات التوقيع الأقدم لا تزال تفرضه). لا تستخدم SHA-1 للتوقيعات الرقمية.
    • SHA-256 — 256-بت. الافتراضي الحديث؛ الغالبيّة العظمى من تواقيع webhook (تدفقات Stripe وGitHub وشبه Slack) تستخدم HMAC-SHA-256.
    • SHA-384 / SHA-512 — ملخّصات أطول، مقاومة تصادم أعلى قليلًا، أبطأ نسبيًّا. اختر أحدها حين يطلب النظام المستلم ذلك صراحةً.
  4. اختر ترميز الإخراج: hex (المعتاد لترويسات النمط X-Signature) أو base64 (المعتاد حين يُضمَّن الملخّص في JSON أو رمز).
  5. انقر توليد. يظهر الملخّص في اللوحة اليمنى؛ ويعرض سطر الحالة الخوارزمية وطول البايتات كفحص صحّة. استخدم نسخ لأخذه.

الميزات الرئيسية#

  • مدعوم بـ Web Crypto. يستخدم crypto.subtle الأصلية في المتصفح، ذات البدائي الذي يستخدمه كود الإنتاج — لا إعادة تنفيذ بـ JavaScript.
  • فحص صحّة الطول. يُتحقَّق من كل ملخّص مقابل طول البايتات المتوقَّع لخوارزميته، فلا يمكن لنتيجة مبتورة أو مُعبَّث بها أن تمرّ بصمت.
  • مخرج hex أو base64. بدّل بنقرة واحدة؛ دون إعادة كتابة.
  • السرّ يبقى محليًّا. يُعرض حقل المفتاح كحقل كلمة مرور ولا يغادر الصفحة أبدًا — فلا خادم خلفي.
  • يَعي السياق الآمن. لو حُمِّلت الصفحة عبر HTTP عاديًا يومًا، فإنّ crypto.subtle تكون غير متاحة فتُبلِّغ الأداة عن ذلك صراحةً بدلًا من إنتاج جواب خاطئ.

مثال عملي#

الزوج المرجعي الكلاسيكي (RFC 4231) يستخدم مفتاح Jefe والرسالة what do ya want for nothing?. مع ضبط هذه الصفحة على SHA-256 وhex، الملخّص هو:

5bdcc146bf60754e6a042426089575c75a003f089d2739839dec58b964ec3843

بدِّل إلى SHA-512 بالمدخلات نفسها فيتضاعف طول الملخّص:

164b7a7bfcf819e2e395fbe73b56e0a387bd64222e831fd610270cd7ea2505549758bf75c05a994a6d034f65f8f0e6fdcaeab1a34d4a6b4b636e070a38bce737

يمكنك إعادة إنتاج كليهما هنا: حمِّل مثال، ثم توليد. هذا الزوج تحديدًا هو أيضًا كيف يتحقّق طقم اختبارات الأداة من الصحّة — إن حصلت يومًا على ملخّص مختلف، فقد عُبِث بالصفحة.

الأسئلة الشائعة#

SHA-256 أم SHA-512 — أيّهما أستخدم؟#

لـ HMAC تحديدًا، SHA-256 هو الافتراضي العملي: كلّ مُوقِّع webhook رئيسي يستخدمه، وهو سريع، و256 بت من الملخّص تتجاوز بكثير منطقة القوّة الغاشمة. انتقل إلى SHA-512 فقط حين (أ) يطلب النظام المستلم ذلك، أو (ب) تصمّم بروتوكولًا جديدًا من الصفر وتريد هامش تصادم إضافيًّا بتكلفة سرعة متواضعة. تجنّب SHA-1 كليًّا إلا لتطابق نظام قديم يفرضه.

هل HMAC هو نفسه تشفير الرسالة؟#

لا. HMAC يُصادق فقط — يُثبت أنّ الرسالة لم تُعدَّل وأنّها جاءت ممّن يملك المفتاح. أمّا الرسالة نفسها فتبقى نصًّا مقروءًا. إن احتجت السرّية أيضًا، فاقرن HMAC بمخطّط تشفير، أو استخدم نمط تشفير مُصادَق مثل AES-GCM.

هل يمكن استعادة المفتاح السري من الملخّص؟#

لا. الملخّص دالة أحادية الاتجاه لكلٍّ من الرسالة والمفتاح؛ واستعادة المفتاح من المخرجات غير ممكنة حسابيًّا. ومع ذلك، فالمفتاح القصير أو القابل للتخمين لا يزال قابلًا للكسر بالقوّة الغاشمة بتجربة مفاتيح مرشَّحة دون اتصال — فاستخدم مفتاحًا لا يقلّ عن 128 بت من الإنتروبيا الحقيقية، لا كلمة مرور يختارها إنسان.

المستلم يقول إنّ توقيعي لا يطابق. ماذا أتحقّق أولًا؟#

تسع مرّات من عشر يكون تمثيل بايتات الرسالة: أسطر جديدة لاحقة، أو ترميز URL مقابل متن خام، أو مسافات JSON بيضاء، أو ترتيب حقول مختلف. قارن البايتات التي وقَّعتها تمامًا بالبايتات التي جزّأها المستلم تمامًا، حرفًا بحرف، قبل أن تتحقّق من أيّ شيء آخر.