SHA-1 مقابل SHA-256 مقابل SHA-512: اختيار خوارزمية التجزئة الصحيحة في 2026
افتح شهادة TLS، أو قاعدة بيانات كائنات Git، أو رأس كتلة Bitcoin، أو مدير حزم لينكس، أو بيان صورة Docker — ستجد تجزئة SHA في كلٍّ منها. لكنها ليست نفس SHA. SHA-1 وSHA-256 وSHA-384 وSHA-512 وSHA-3: تمتد هذه العائلة عبر ثلاثة عقود وسلسلتَي تصميم مختلفتَين وهجوم تصادم محوري أسقط أقدم أعضائها في الإنتاج.
يرسم هذا الدليل خريطة للعائلة بأكملها لتتمكن من اختيار الخوارزمية المناسبة لحالة استخدامك دون تردد.
شجرة القرار السريع
قبل الغوص في التفاصيل، إليك ملخص الجدول الوحيد الذي يحتاجه معظم المطورين فعلاً:
| حالتك | الخيار الأمثل | السبب |
|---|---|---|
| شهادة TLS/HTTPS | SHA-256 (حد أدنى)، SHA-384 للأمان العالي | مطلوب بموجب متطلبات منتدى CA/Browser Forum الأساسية |
| توقيع JWT (HMAC أو RSA) | SHA-256 (HS256/RS256) | دعم شامل؛ SHA-384/512 لأنظمة الامتثال |
| مجموع اختباري لسلامة البرامج | SHA-256 | المعيار الصناعي؛ مفهوم على نطاق واسع |
| سلامة أرشيفية أو طويلة الأمد | SHA-512 | مخرجات أكبر، هامش أمان للعقود القادمة |
| عنونة المحتوى (IPFS، OCI) | SHA-256 | المعيار الفعلي للتخزين القابل للعنونة بالمحتوى |
| Git (قراءة/كتابة مستودعات موجودة) | SHA-1 للموجودة؛ SHA-256 للجديدة عبر --object-format=sha256 | Git في منتصف الترحيل؛ SHA-1 لا تزال سائدة |
| التشغيل البيني مع Ethereum | Keccak-256 (وليس NIST SHA-3) | تستخدم Ethereum متغير Keccak ما قبل المعيار |
| الدفاع المتعمق أو الأنظمة المصنفة | SHA-384 أو SHA-512 | NSA Suite B؛ يتكامل مع AES-256-GCM |
| كود جديد بلا قيود إرث | SHA-3 (SHA3-256) | سلسلة تصميم مختلفة؛ لا ثغرة امتداد الطول |
| تخزين كلمات المرور | لا شيء مما سبق | استخدم bcrypt أو Argon2id أو scrypt — SHA سريعة جداً |
عائلة SHA في لمحة
| الخوارزمية | المعيار | بتات المخرجات | أحرف سداسية | السنة | حالة NIST | الاستخدام الأساسي اليوم |
|---|---|---|---|---|---|---|
| SHA-1 | FIPS 180-4 | 160 | 40 | 1995 | مُستهلكة (2011)، مُسحوبة للتوقيعات الرقمية | إرث Git، البصمات |
| SHA-256 | FIPS 180-4 | 256 | 64 | 2001 | حالية | TLS، JWT، Bitcoin، المجاميع الاختبارية |
| SHA-384 | FIPS 180-4 | 384 | 96 | 2001 | حالية | Suite B، TLS عالي الأمان |
| SHA-512 | FIPS 180-4 | 512 | 128 | 2001 | حالية | الأرشفة، LUKS، HMAC-SHA-512 |
| SHA-3 (أي متغير) | FIPS 202 | 224/256/384/512 | متغير | 2015 | حالية | سلسلة بديلة، تسريع عتادي |
تشترك SHA-1 وSHA-2 (مجموعة 256/384/512) في بنية Merkle-Damgård. تستخدم SHA-3 بنية الإسفنجة — وهو تمييز أكثر أهمية مما قد يبدو، وسنتناوله أدناه.
SHA-1: مكسورة لكنها لم تمت
كانت SHA-1 حصان العمل في عقد 2000. تقاطعت عليها شهادات SSL ورسائل S/MIME وبصمات PGP وGit. ثم في فبراير 2017، نشرت Google وCWI Amsterdam هجوم SHAttered: هجوم تصادم ببادئة مختارة أنتج ملفَّي PDF متمايزَيْن بتجزئة SHA-1 متطابقة. تطلّب الهجوم نحو 6.5 × 10^19 تقييماً لـSHA-1 — مكلف في 2017، في متناول اليد اليوم بالحوسبة السحابية.
كانت NIST قد استهلكت SHA-1 للتوقيعات الرقمية في 2011 (NIST Special Publication 800-131A). عجّل عرض SHAttered عملية التنظيف: توقفت المتصفحات عن الوثوق بشهادات TLS من نوع SHA-1 في 2017، وجعل منتدى CA/Browser Forum الـSHA-256 إلزامياً للإصدارات الجديدة.
ما تُستخدم فيه SHA-1 حتى الآن:
- قاعدة بيانات كائنات Git: صُمِّمت Git حول SHA-1 كتجزئة محتوى سريعة، لا كعنصر أمني. يُرمِّز تنسيق المستودع معرّفات الكائنات السداسية ذات الـ40 حرفاً. مسار الترحيل إلى SHA-256 (
git init --object-format=sha256) موجود لكن التبنّي بطيء لأن كل منصة استضافة وأداة CI وكل نسخة موجودة تحتاج إلى الترحيل معاً. - بصمات الأنظمة القديمة: بصمات مفاتيح المضيف القديمة في SSH وبصمات مفاتيح PGP ومخططات أرقام تسلسل الشهادات لا تزال تُظهر قيم SHA-1. هذه إعلامية، وليست حرجة أمنياً في معظم السياقات.
ما يجب فعله: لا تستخدم SHA-1 لأي شيء جديد. بالنسبة لـGit، مخاطر التصادم منخفضة لسير العمل النموذجية في تطوير البرامج (يحتاج المهاجم للتحكم في كلا الملفَّيْن في التصادم)، لكن المشاريع الجديدة التي تستخدم --object-format=sha256 هي الاتجاه الصحيح على المدى البعيد.
ولّد تجزئة SHA-1 في متصفحك: مولّد SHA-1.
SHA-256: حصان العمل
SHA-256 هي الخوارزمية التي تُشغّل الإنترنت في 2026. كل شهادة TLS صادرة من هيئة شهادات عامة تستخدم SHA-256 لتجزئة توقيعها. كل JWT موقَّع بـHS256 أو RS256 أو ES256 يستخدم SHA-256 داخلياً. إثبات عمل Bitcoin هو SHA-256 مزدوج. تجزئة محتوى Docker هي SHA-256. تكامل حزم npm يستخدم SHA-256.
الأسباب عملية:
- هامش الأمان: 256 بتاً من المخرجات تعني 2^128 عملية لهجوم استعادة الصورة الأولية بالقوة الغاشمة — خارج نطاق أي عتاد متصوَّر في المستقبل المنظور. المستوى الفعلي للأمان أقل قليلاً بسبب هجمات التصادم بحد عيد الميلاد (2^128 عملية)، لا يزال منيعاً.
- التسريع العتادي: تُنفَّذ SHA-256 على مستوى الرقائق في كل معالج Intel Goldmont+ (امتداد SHA-NI)، وكل رقاقة Apple silicon، وكل معالج ARMv8، ودوائر متكاملة مخصصة في الأجهزة الشبكية ووحدات التخزين. عند أخذ مسار العتاد، يتجاوز معدل نقل SHA-256 كثيراً من البدائل البرمجية التي تبدو أسرع.
- دعم المكتبات في كل مكان: كل مكتبة TLS، وكل مكتبة JWT، وكل مكتبة قياسية لأي لغة تُنفِّذ SHA-256. لن تصطدم بجدار توافق.
للعنونة بالمحتوى والتحقق من السلامة ومعظم سير عمل التوقيع، SHA-256 هي الافتراضي الصحيح ما لم يتطلب معيار محدد خلاف ذلك.
ولّد تجزئة SHA-256 في متصفحك: مولّد SHA-256.
SHA-384: تخصص TLS
SHA-384 هي SHA-512 مُقتطَعة إلى 384 بتاً. أُنشئت لتوفير مستوى أمان 192 بت (نصف حجم المخرجات هو حد مقاومة التصادم) وأُدرجت في تعمية NSA Suite B إلى جانب AES-256-GCM ومفاتيح المنحنى الإهليلجي P-384.
خاصيتان تجعلان SHA-384 جذابة تحديداً لـTLS:
- حصانة امتداد الطول عند هذا الحجم: SHA-256 وSHA-512 عرضة لهجمات امتداد الطول — يستطيع مهاجم يعرف H(secret || message) حساب H(secret || message || extension) دون معرفة السر. SHA-384 وSHA-512/256 مُقتطَعتان من الحالة الداخلية الكاملة، لذا لا ينطبق امتداد الطول. إذا كنت تستخدم تجزئات SHA خام كرموز تحقق من الرسائل (بدلاً من HMAC)، فإن SHA-384 أكثر أماناً.
- الامتثال لـSuite B: المؤسسات الملزَمة بمتطلبات NSA/CNSA (Commercial National Security Algorithm) يجب عليها استخدام SHA-384 أو SHA-512 إلى جانب RSA-3072+ وECDH P-384 وAES-256-GCM. إذا كان عميلك وكالة فيدرالية أمريكية أو متعاقداً يعمل تحت متطلبات FIPS 140-3، فقد تكون SHA-384 إلزامية.
SHA-384 ليست أكثر أماناً بشكل ملموس من SHA-256 لمعظم حالات الاستخدام — الفجوة العملية بين مقاومة التصادم 128 بت و192 بت نظرية على مستويات الحوسبة الحالية. اختَرها حين يتطلب الامتثال أو تكامل Suite B ذلك، لا للاستخدام العام.
ولّد تجزئة SHA-384 في متصفحك: مولّد SHA-384.
SHA-512: حين تحتاج مزيداً من البتات
تُنتج SHA-512 ملخصاً بحجم 512 بت (128 حرفاً سداسياً). على عتاد 64 بت، تكون في الغالب أسرع من SHA-256 لأن الخوارزمية تعمل على كلمات 64 بت بدلاً من كلمات 32 بت — جدول العمليات الداخلي لـSHA-256 يستخدم حساباً بحجم 32 بت، بينما يستخدم SHA-512 حساباً بحجم 64 بت يُعيَّن بكفاءة أكبر على المعالجات الحديثة.
قياسات الأداء على عتاد 64 بت (استرشادية؛ Web Crypto API في المتصفح):
| الخوارزمية | معدل النقل التقريبي |
|---|---|
| SHA-1 | ~600 ميغابايت/ثانية |
| SHA-256 | ~500 ميغابايت/ثانية |
| SHA-384 | ~700 ميغابايت/ثانية |
| SHA-512 | ~700 ميغابايت/ثانية |
| SHA-3-256 | ~300 ميغابايت/ثانية |
ملاحظة: تشترك SHA-384 وSHA-512 في نفس دالة الضغط الداخلية، لذا تعملان بنفس السرعة. SHA-256 أبطأ على 64 بت لأن حجم كلمتها 32 بت يعني مزيداً من التكرارات لمعالجة كل كتلة رسالة 512 بت. على عتاد 32 بت أو عتاد محدود الموارد، SHA-256 أسرع.
SHA-512 مناسبة لـ:
- سلامة الأرشيف: المجاميع الاختبارية المخصصة للبقاء عقوداً تستفيد من هامش المخرجات الأكبر.
- تعمية القرص الكامل: يستخدم لينكس LUKS تجزئة PBKDF2 الافتراضية SHA-512 لاشتقاق المفاتيح (كمكوّن لـPBKDF2، لا كتجزئة مستقلة).
- HMAC-SHA-512: يُستخدم في بعض مخططات توقيع JWT (HS512) والتحقق من هوية API حيث تُفضَّل رموز التحقق الأكبر.
- توليد كميات كبيرة من البيانات شبه العشوائية: التطبيقات التي تجزّئ بذرة وتحتاج كثيراً من بتات المخرجات يمكنها استخدام SHA-512 لتقليل عدد استدعاءات التجزئة.
ولّد تجزئة SHA-512 في متصفحك: مولّد SHA-512.
SHA-3: فلسفة تصميم مختلفة
SHA-3 ليست SHA-2 بمخرجات أكبر. إنها خوارزمية مختلفة جوهرياً مبنية على بنية الإسفنجة المسماة Keccak، صمّمها Guido Bertoni وJoan Daemen وMichaël Peeters وGilles Van Assche. اختارتها NIST فائزةً في منافسة عامة استمرت سبع سنوات (2007–2012) بهدف إنتاج عائلة تجزئة يمكنها أن تكون احتياطياً إذا اكتُشفت نقاط ضعف في بنية SHA-2 الـMerkle-Damgård.
تعمل بنية الإسفنجة بشكل مختلف عن Merkle-Damgård:
- تُحشى المدخلات وتُقسَّم إلى كتل.
- يُطبَّق XOR على كل كتلة في الجزء الأول من حالة داخلية كبيرة (“المعدّل”)، ثم تُطبَّق تبديلة Keccak-f على الحالة بأكملها.
- بعد استيعاب جميع المدخلات، تُستخرَج المخرجات من الجزء المعدّل للحالة.
لأن المخرجات تُستخرَج من جزء فقط من الحالة، ولأن جزء السعة لا يُكشف مباشرة قط، فإن بنى الإسفنجة محصّنة بطبيعتها ضد هجمات امتداد الطول دون اقتطاع.
متغيرات معيار SHA-3 (FIPS 202):
| المتغير | بتات المخرجات | مستوى الأمان |
|---|---|---|
| SHA3-224 | 224 | 112 بت |
| SHA3-256 | 256 | 128 بت |
| SHA3-384 | 384 | 192 بت |
| SHA3-512 | 512 | 256 بت |
| SHAKE128 | متغير | 128 بت |
| SHAKE256 | متغير | 256 بت |
SHA-3 مقابل SHA-2 عملياً:
لم تُنشَر SHA-3 على نطاق واسع بعد في البروتوكولات المصمَّمة قبل 2015 — لا تزال TLS وJWT ومعظم البنية التحتية للإنترنت تستخدم SHA-2. تظهر SHA-3 في مخططات التوقيع ما بعد الكمومي (CRYSTALS-Dilithium وSPHINCS+ تستخدمان SHA-3 داخلياً)، وتصاميم البروتوكولات الجديدة التي تريد احتياطياً من سلسلة تصميم مختلفة، والعتاد حيث تتسارع تبديلة Keccak جيداً. في البرامج الخالصة، SHA-3 أبطأ بنحو 40% من SHA-256 على x86.
ولّد تجزئة SHA-3 في متصفحك: مولّد SHA-3.
تمييز Keccak-256 في Ethereum
تحذير حاسم: لا تستخدم Ethereum معيار NIST SHA-3. صُمِّمت Ethereum في حين كانت منافسة Keccak جارية وقبل أن تُصادق NIST على FIPS 202. تستخدم الآلة الافتراضية لـEthereum تقديم Keccak-256 الأصلي، الذي يستخدم حشواً مختلفاً عن معيار NIST SHA-3 المُصادَق عليه.
تحديداً:
- يُلحق NIST SHA3-256 حشواً
0x06قبل الكتلة الأخيرة. - يُلحق Keccak-256 الأصلي (كما تستخدمه Ethereum) حشواً
0x01.
نفس المدخلات تنتج تجزئات مختلفة. استدعاء NIST SHA3-256 واستدعاء keccak256 الخاصة بـEthereum ليسا متبادلَيْن. معظم اللغات تحتوي على كليهما: في Python، hashlib.sha3_256() هي NIST SHA-3؛ لـKeccak-256 كما تستخدمها Ethereum، تحتاج مكتبة مثل pysha3 (التي تُنفِّذ keccak_256). في JavaScript، مكتبة js-sha3 تكشف كليهما. يُنفِّذ مولّد SHA-3 معيار NIST SHA3-256 — إذا احتجت تجزئات Ethereum Keccak-256، استخدم أداة خاصة بـEthereum.
قياسات الأداء
الأرقام أدناه استرشادية لـWeb Crypto API في المتصفح على حاسوب محمول حديث x86-64. يتفاوت معدل النقل الفعلي مع العتاد وحجم الرسالة وما إذا كانت المنصة تستخدم مسار التسريع العتادي.
| الخوارزمية | معدل النقل المتدفق (64 بت) |
|---|---|
| SHA-1 | ~600 ميغابايت/ثانية |
| SHA-256 | ~500 ميغابايت/ثانية |
| SHA-384 | ~700 ميغابايت/ثانية |
| SHA-512 | ~700 ميغابايت/ثانية |
| SHA-3-256 | ~300 ميغابايت/ثانية |
للرسائل الصغيرة (رموز API، مجاميع اختبارية أقل من بضع كيلوبايتات)، تكتمل جميع الخوارزميات في أقل من 2 ميكروثانية — الفرق غير مرئي. للبيانات الكبيرة (أرشيفات tar، صور أقراص)، تتفوق SHA-384/512 على SHA-256 على أنظمة 64 بت لأنها تعمل على كلمات 64 بت. SHA-3 أبطأ في البرامج الخالصة؛ فضّل SHA-2 في الكود الحساس للإنتاجية ما لم يكن تسريع Keccak العتادي متاحاً. معدل نقل SHA-1 ليس مسوّغاً لاستخدامها أبداً.
الأخطاء الشائعة
عدم تطابق الترميز
تعمل SHA على البايتات. إذا جزّأت السلسلة "hello" في متصفح يُرمِّزها بـUTF-16 بدلاً من UTF-8، تحصل على ملخص مختلف عن سكريبت Python الذي يستخدم str.encode("utf-8"). حوّل دائماً إلى UTF-8 قبل التجزئة.
نمط متسق:
const encoder = new TextEncoder(); // UTF-8
const data = encoder.encode(inputString);
const hashBuffer = await crypto.subtle.digest("SHA-256", data);
غياب الإملاح في رموز التحقق من الرسائل
استخدام تجزئة SHA خام كرمز تحقق من رسالة (H(secret || message)) عرضة لهجمات امتداد الطول على SHA-256 وSHA-512. استخدم HMAC (RFC 2104) بدلاً من ذلك: HMAC-SHA256(key, message). يُغلِّف HMAC التجزئة بوسادة مفاتيح داخلية وخارجية تمنع هجمات الامتداد.
امتداد الطول في SHA-256
إذا كنت تبني توقيع API بصيغة SHA256(secret + payload)، يستطيع مهاجم يعرف التجزئة الناتجة حساب SHA256(secret + payload + attacker_extension) دون معرفة السر. الإصلاح: استخدم HMAC، أو استخدم SHA-3 (محصّنة بالبناء)، أو استخدم SHA-384/SHA-512/256 (محصّنة بسبب الاقتطاع).
الخلط بين Keccak-256 و NIST SHA-3
كما وُصف أعلاه: تستخدم Ethereum تجزئة Keccak-256 بحشواً 0x01؛ يستخدم NIST SHA3-256 حشواً 0x06. ينتجان مخرجات مختلفة من نفس المدخلات. تحقق من المتغير الذي تُنفِّذه مكتبتك قبل التكامل مع عقود Ethereum أو ترميز Solidity ABI.
استخدام SHA لكلمات المرور
صُمِّمت خوارزميات SHA لتكون سريعة. هذه هي الخاصية الخاطئة تماماً لتخزين كلمات المرور: تستطيع مجموعة GPU حساب مليارات تجزئات SHA-256 في الثانية، ما يجعل هجوم القاموس على قاعدة بيانات كلمات مرور مجزّأة بـSHA أمراً عملياً. لكلمات المرور، استخدم دالة اشتقاق مفتاح صعبة الذاكرة: Argon2id (مُوصى بها)، أو bcrypt، أو scrypt. لا تخزّن كلمات المرور كتجزئات SHA خام أبداً، حتى مع الإملاح.
الأسئلة الشائعة
ما الفرق بين SHA-1 وSHA-256؟
SHA-1 وSHA-256 كلتاهما دالتا تجزئة من نوع Merkle-Damgård مُقنَّنتان في FIPS 180-4، لكن SHA-256 تُنتج ملخصاً بحجم 256 بت مقابل 160 بت لـSHA-1. الأهم من ذلك، كُسِرت SHA-1: أظهر هجوم تصادم حقيقي (SHAttered، 2017) ملفَّيْ PDF متمايزَيْن بنفس تجزئة SHA-1. لا هجمات تصادم معروفة على SHA-256 وهي توفر مستوى مقاومة تصادم 128 بت. استخدم SHA-256 لأي شيء يتطلب ضمانات السلامة؛ لا تستخدم SHA-1 في أي عمل جديد.
هل SHA-512 أسرع من SHA-256؟
على عتاد 64 بت، نعم، في الغالب بنسبة 30–40% للمدخلات الكبيرة. تستخدم SHA-512 حساب كلمات 64 بت تعالجها المعالجات الحديثة أصلياً. تستخدم SHA-256 حساب كلمات 32 بت، ما يتطلب ضعف عدد العمليات لكل كتلة رسالة على نفس العتاد. على منصات 32 بت أو وحدات التحكم المدمجة المقيّدة، SHA-256 أسرع. للرسائل القصيرة (أقل من بضع كيلوبايتات)، الفرق غير محسوس.
هل يجب أن أنتقل من SHA-1 إلى SHA-256؟
للتوقيعات الرقمية وشهادات TLS وتوقيع الكود: نعم، بكل تأكيد — SHA-1 مُستهلكة ومكسورة فعلياً. لمستودعات Git: مسار الترحيل موجود (git init --object-format=sha256) لكن التبنّي بطيء بسبب متطلبات التنسيق بين النظام البيئي؛ مخاطر التصادم لاستخدام المستودع النموذجي منخفضة. للبصمات الإعلامية (عرض مفاتيح مضيف SSH): التعرض الأمني ضئيل، لكن الترحيل إلى SHA-256 من قبيل الممارسات الجيدة.
هل يمكن عكس SHA-256؟
لا. SHA-256 دالة أحادية الاتجاه بالتصميم. بوجود تجزئة، لا يمكنك استرجاع المدخلات الأصلية رياضياً. ما يستطيع المهاجمون فعله هو تنفيذ هجوم بالقاموس أو القوة الغاشمة: تجزئة ملايين المدخلات المرشحة والمقارنة. للمدخلات منخفضة الإنتروبيا (سلاسل قصيرة، كلمات مرور شائعة، أعداد تسلسلية)، تجعل جداول قوس قزح المحسوبة مسبقاً ذلك عملياً. للمدخلات عالية الإنتروبيا (UUID عشوائية، ملفات كبيرة)، العكس غير ممكن حسابياً. لهذا السبب SHA وحدها غير مناسبة لكلمات المرور — تحتاج دالة اشتقاق مفاتيح بطيئة ومُملَّحة.
متى يجب استخدام SHA-3 بدلاً من SHA-2؟
SHA-3 مناسبة حين: (أ) تريد تجزئة من سلسلة تصميم مختلفة كتأمين ضد نقاط ضعف مستقبلية في SHA-2؛ (ب) يتطلب بروتوكولك حصانة امتداد الطول دون استخدام HMAC؛ (ج) تُنفِّذ مخططات توقيع ما بعد الكمومي التي تحدد SHA-3 داخلياً؛ أو (د) لديك تسريع عتادي لـKeccak وتحتاج إنتاجية. لمعظم حالات الاستخدام اليومية (TLS، JWT، المجاميع الاختبارية)، تتمتع SHA-256 بدعم أوسع في النظام البيئي وهي الخيار العملي الافتراضي. SHA-3 ليست أكثر أماناً من SHA-2 عند أحجام مخرجات مكافئة — إنها رهان مختلف على الأمان طويل الأمد.
لماذا تستخدم Ethereum تجزئة Keccak-256 بدلاً من NIST SHA-3؟
صُمِّمت Ethereum في 2013–2014، قبل أن تنشر NIST معيار FIPS 202 (أغسطس 2015) الذي أقرّ معيار SHA-3. في ذلك الوقت، كان تقديم Keccak يُعتبر الفائز المرجَّح، واستخدمه مؤلفو Ethereum مباشرة. حين أنهت NIST المعيار، غيّرت حشو فصل النطاق من 0x01 (أصلي Keccak) إلى 0x06، مُنتِجةً مخرجات مختلفة من نفس المدخلات. كانت Ethereum قد نُشِرت مع حشو Keccak الأصلي ولم تستطع تغييره. لذا فإن “Ethereum keccak256” و”NIST SHA3-256” خوارزميتان مختلفتان رغم اشتراكهما في نفس تبديلة Keccak-f الأساسية.
جرّب الأدوات: SHA-1 · SHA-256 · SHA-384 · SHA-512 · SHA-3 — تعمل جميعها في متصفحك، لا تغادر أي بيانات جهازك.