التشفير ما بعد الكمي لم يعد موضوعًا نظريًا ينتظر ظهور حاسوب كمي قادر على كسر الإنترنت. نشرت NIST ثلاثة معايير نهائية يمكن تطبيقها الآن، وتدعو المؤسسات إلى بدء الانتقال قبل وصول الخطر. السبب بسيط: تغيير التشفير داخل الشهادات والأنظمة والأجهزة وسلاسل التوريد يستغرق سنوات، وهناك بيانات تُسرق اليوم لتُفك لاحقًا عندما تتوفر القدرة المناسبة، وهو ما يعرف بهجوم «اجمع الآن وافك لاحقًا».
في 2026 زاد الاهتمام بعد تطورات في المعايير والجداول الحكومية وإعلان اكتشاف ضعف في خوارزمية HAWK المرشحة، من دون تأثير في المعايير النهائية ML-KEM وML-DSA. هذا يوضح كيف تعمل المراجعة المفتوحة: المرشح الضعيف يُسحب قبل اعتماده. في هذا الدليل نوضح الخطر، والخوارزميات، ولماذا يبدأ المشروع بجرد التشفير لا بشراء منتج، وكيف تبني خطة انتقال من دون كسر الأنظمة الحالية.
ما الذي يمكن أن تكسره الحوسبة الكمية؟
تعتمد أنظمة كثيرة على RSA والمنحنيات البيضاوية ECC لصعوبة مسائل رياضية أمام الحاسوب التقليدي. خوارزمية Shor النظرية تستطيع حل هذه المسائل بكفاءة على حاسوب كمي كبير ومستقر بما يكفي، ما يهدد تبادل المفاتيح والتوقيعات. لا يعني ذلك أن AES أو كل تشفير متماثل ينهار بالطريقة نفسها؛ التأثير الأكبر والمباشر يقع على تشفير المفتاح العام الذي يثبت الهوية ويؤسس اتصالًا آمنًا.
لا يوجد إعلان موثوق بأن حاسوبًا كميًا ذا صلة تحليلية قادر اليوم على كسر RSA المستخدم عمليًا. لكن غياب الجهاز لا يلغي الحاجة إلى العمل. شهادة داخل جهاز صناعي قد تبقى عشر سنوات، ومستند طبي أو حكومي قد يحتاج السرية لعقود. إذا التقط خصم الاتصال المشفر الآن واحتفظ به، فقد يحاول فكّه مستقبلًا. لذلك يعتمد توقيت الانتقال على عمر سرية البيانات وزمن تغيير النظام، لا على تاريخ متوقع للحاسوب فقط.
التوقيعات خطر مختلف. إذا أمكن تزوير توقيع مطور أو جهة شهادات، يستطيع المهاجم نشر تحديث مزيف أو انتحال خدمة. حماية الماضي لا تكفي؛ يجب أن تثق الأنظمة المستقبلية بالمفاتيح الجديدة وسلسلة تحديث آمنة. الأجهزة غير القابلة للتحديث تمثل تحديًا أكبر من خادم يمكن تغيير مكتبته خلال نافذة صيانة.
ما المعايير التي أنهتها NIST؟
توضح صفحة NIST الرسمية للتشفير ما بعد الكمي أن ثلاثة معايير جاهزة للتطبيق. FIPS 203 يحدد ML-KEM لتغليف المفاتيح، وهو آلية تستخدم لتأسيس سر مشترك بين طرفين. FIPS 204 يحدد ML-DSA للتوقيعات الرقمية المعتمدة على الشبكات الرياضية. FIPS 205 يحدد SLH-DSA، توقيعًا يعتمد على دوال hash ويقدم أساسًا رياضيًا مختلفًا للتنوع.
اختيار أكثر من خوارزمية ليس تكرارًا بلا فائدة. التنوع يقلل الاعتماد على عائلة واحدة إذا ظهر ضعف جديد. كما أن الأحجام والأداء ومتطلبات التنفيذ تختلف. ML-DSA مناسب لحالات كثيرة، بينما SLH-DSA يقدم مسارًا احتياطيًا بخصائص مختلفة وتوقيعات أكبر. لا تختار الخوارزمية من جدول سرعة فقط؛ اتبع البروتوكول والمنتج والمعيار الذي يحدد كيفية استخدامها بأمان.
اختارت NIST أيضًا HQC في 2025 بوصفها خوارزمية احتياطية مستقبلية للتشفير العام. وما يزال العمل مستمرًا على مرشحين إضافيين. هذا لا يجعل المعايير الحالية «مؤقتة وغير صالحة»، بل يعكس سياسة crypto agility: وجود بدائل ومسار تحديث إذا تطورت الأبحاث. المعايير النهائية الحالية مصممة للتطبيق الآن.
ماذا حدث لخوارزمية HAWK؟
في يوليو 2026 أُعلن اكتشاف ضعف في HAWK، وهي خوارزمية توقيع كانت قيد النظر، ثم سحبها فريقها من عملية التقييس. تؤكد NIST أن ذلك لا يؤثر في ML-KEM أو ML-DSA، لأنهما يستخدمان أسسًا مختلفة. الدرس ليس أن «التشفير الكمي فشل»، بل أن المنافسة والمراجعة تحاول كشف المشكلات قبل الاعتماد والنشر الواسع.
لماذا لا ننتظر حتى تصبح المنتجات جاهزة تلقائيًا؟
لأن المؤسسة غالبًا لا تعرف أين تستخدم التشفير. قد ترى شهادات الويب، لكنها لا ترى مفاتيح داخل VPN، توقيع firmware، مكتبة ضمن تطبيق قديم، اتصال قاعدة بيانات، جهاز شبكة، أو ملف أرشيف. الترقية الآلية لمتصفح لا تصل إلى جهاز تحكم صناعي أو تكامل B2B يعتمد خوارزمية ثابتة.
كما أن الانتقال يحتاج توافقًا بين الطرفين. إذا دعم الخادم خوارزمية جديدة ولم يدعمها العميل، يجب وجود تفاوض أو وضع هجين. وقد تزيد أحجام المفاتيح والرسائل فتظهر مشاكل MTU أو زمن handshake أو ذاكرة جهاز صغير. هذه أمور لا تُكتشف من وثيقة سياسة، بل من اختبار على المسار الفعلي.
الانتظار يضغط كل العمل في وقت قصير. الأفضل تحديث المشتريات والعقود الآن، وجرد الاستخدام، ورفع المكتبات، وتجربة بروتوكولات هجينة حيث تدعم. هذه الإجراءات تقلل الديون الأمنية حتى قبل الانتقال الكامل.
الخطوة الأولى: جرد التشفير
تسمي NIST وNCCoE هذا العمل cryptographic discovery أو visibility. الهدف خريطة تجيب: أين توجد خوارزميات المفتاح العام؟ لأي غرض؟ من يملك النظام؟ ما عمر البيانات؟ هل يمكن تحديثه؟ وما الاعتماديات الخارجية؟ الجرد ليس قائمة شهادات فقط، بل علاقة بين أصل وبروتوكول ومكتبة ومفتاح ومورد.
ابدأ بالمصادر المتاحة: ماسحات الشبكة، سجلات TLS، مخزون الشهادات، مستودعات الشيفرة، قوائم مكونات البرمجيات SBOM، إعدادات VPN وSSH، أجهزة HSM، وتوثيق المورد. استخدم الاكتشاف الآلي لكن تحقق يدويًا من الأنظمة الحرجة. المرور الشبكي قد لا يكشف تشفير ملف أو توقيع تحديث، وتحليل الشيفرة قد لا يرى خدمة خارجية.
سجل لكل حالة الخوارزمية وحجم المفتاح والمكتبة والإصدار والمالك وتاريخ الانتهاء وحساسية البيانات. أضف «زمن الهجرة» و«عمر السرية». نظام يحتوي أسرارًا لعشرين سنة ويحتاج خمس سنوات للتغيير يأخذ أولوية أعلى من صفحة عامة يمكن تحديثها غدًا.
لا تحول الجرد إلى ملف Excel يموت بعد أسبوع. اربطه بإدارة الأصول والتغيير، وأضف فحصًا عند شراء منتج أو نشر خدمة. الهدف قدرة مستمرة على معرفة التشفير وتغييره، لا حملة مرة واحدة.
خطة انتقال عملية إلى PQC
1. الحوكمة والملكية
عيّن مسؤولًا تنفيذيًا وفريقًا يجمع الأمن والبنية والتطوير والمشتريات والقانون. التشفير يعبر الحدود التنظيمية، وإذا تركته لفريق الشهادات فلن يصل إلى التطبيقات والأجهزة. حدد نطاقًا وأولويات وتقارير تقدم، ولا تجعل النجاح «عدد المنتجات التي تقول quantum-ready».
2. تصنيف البيانات والأنظمة
حدد البيانات التي تحتاج سرية طويلة والتوقيعات التي يجب أن تبقى موثوقة. أعط الأولوية للهوية وPKI وVPN والنسخ الاحتياطية والأرشيف وتحديثات البرمجيات. افصل الأنظمة التي يمكن تحديثها عن الأجهزة المرتبطة بمورد أو نهاية عمر.
3. تحديث الأساس قبل PQC
أزل الخوارزميات الضعيفة الحالية، وحدّث مكتبات TLS وSSH، ووحّد إدارة الشهادات. مؤسسة ما تزال تستخدم مكونات منتهية لن تنجح في انتقال أكثر تعقيدًا. التحديثات الحديثة غالبًا تضيف دعمًا تدريجيًا للخوارزميات الجديدة وتقلل العمل الخاص.
4. اختبارات هجينة
الوضع الهجين يجمع سرًا كلاسيكيًا وآخر ما بعد كمي، بحيث يبقى الاتصال آمنًا إذا صمد أحدهما وفق التصميم. يفيد خلال مرحلة التوافق، لكنه يزيد الأحجام والتعقيد. اختبر latency واستهلاك CPU والذاكرة والشبكات الوسطية وTLS inspection. لا تفترض أن نجاح المتصفح يعني نجاح كل API وجهاز.
5. إدارة الموردين
اطلب خارطة دعم واضحة: أي معايير؟ أي إصدار؟ هل التحديث ضمن العقد؟ ماذا عن HSM والشهادات والأجهزة؟ تجنب عبارة «quantum-safe» من دون رقم FIPS أو بروتوكول وتاريخ. أضف قابلية التحديث والتصدير إلى شروط الشراء الجديدة.
6. خطة rollback ومراقبة
أي تغيير تشفير قد يقطع عميلًا قديمًا. انشر تدريجيًا، راقب معدلات handshake والأخطاء، واحتفظ بتراجع آمن ومحدد الزمن. لا تجعل التراجع الدائم مبررًا لإبقاء خوارزمية قديمة مفتوحة للجميع.
الأثر في TLS وSSH والبريد وPKI
TLS: يعمل IETF والصناعة على دمج الخوارزميات في البروتوكولات. ستظهر مجموعات هجينة وتحديثات في المتصفحات وCDN. راقب ما يقدمه الطرف العام وما يستخدمه الاتصال الداخلي. يمكنك حاليًا فحص HTTPS والترويسات عبر أداة فحص الأمان، لكن نتيجة قوية اليوم لا تعني اكتمال جاهزية PQC؛ تحتاج الأداة والبروتوكول دعمًا صريحًا.
SSH: الاتصالات الإدارية حساسة وعمرها طويل. إصدارات حديثة بدأت دعم تبادل مفاتيح هجين. اختبر الخادم والعميل وjump hosts وأدوات الأتمتة. لا تغيّر إعدادًا مركزيًا قبل معرفة العملاء القديمة التي ستنقطع.
البريد: TLS يحمي النقل، بينما S/MIME أو PGP يحمي الرسالة ويوقعها. الأرشيف طويل العمر أكثر حساسية لـ«اجمع الآن». لكن منظومة البريد تعتمد على عدة مزودين وعملاء، لذلك يحتاج الانتقال توافقًا وسياسة مفاتيح لا مجرد سجل DNS. تبقى SPF وDKIM وDMARC مهمة لمنع الانتحال الحالي، وهي منفصلة عن مقاومة الكم.
PKI والتوقيع: شهادات الجذر والأجهزة التي تتحقق من firmware قد تعيش سنوات. خطط لسلسلة ثقة جديدة، أحجام توقيع، تخزين مفاتيح، وإجراءات rollover. تأكد أن bootloader أو الجهاز يمكن تحديث خوارزمية التحقق بطريقة موثوقة؛ وإلا يصبح المنتج دينًا طويل الأجل.
النسخ والأرشيف: إعادة تشفير بيتابايتات ليست عملية بسيطة. قد تحتاج حماية مفاتيح التغليف بدل كل كتلة، أو نقلًا تدريجيًا عند القراءة. اختبر الاستعادة؛ نسخة مشفرة بخوارزمية حديثة لكن بلا مسار مفاتيح موثق ليست حماية بل فقدان مؤجل.
Crypto agility: الهدف الأكبر من خوارزمية واحدة
المرونة التشفيرية هي قدرة النظام على استبدال خوارزمية أو مفتاح أو مزود من دون إعادة بناء كاملة. تتحقق عبر عدم تثبيت أسماء الخوارزميات في الشيفرة، استخدام مكتبات مدعومة، فصل السياسة عن التطبيق، جرد الإصدارات، وأتمتة دورة الشهادات. حادثة HAWK تذكير بأن البحث يستمر؛ يجب أن نفترض أن بعض الخيارات ستتغير.
لا تعني المرونة السماح بأي خوارزمية يرسلها الطرف الآخر. يجب وجود سياسة مركزية وقائمة معتمدة واختبار. المرونة المنضبطة تختلف عن التفاوض المفتوح الذي قد يسمح downgrade. صمم قدرة التغيير مع حدود آمنة.
أخطاء شائعة في مشاريع PQC
شراء منتج قبل الجرد: قد يحمي بوابة واحدة ويترك قاعدة بيانات وجهازًا وتوقيع تحديث بلا خطة.
اعتبار الموضوع مشكلة TLS فقط: التوقيعات وSSH وVPN والأرشيف والهوية قد تكون أهم.
تطبيق خوارزمية من ورقة بحثية مباشرة: استخدم معيارًا وتنفيذًا مراجعًا؛ أخطاء القنوات الجانبية والعشوائية قد تهزم رياضيات صحيحة.
إهمال الأداء والحجم: الرسائل الأكبر قد تؤثر في الأجهزة والشبكات والأنظمة الوسيطة.
حذف الخوارزمية الكلاسيكية فورًا: الانتقال يحتاج توافقًا ووضعًا هجينًا وخطة تراجع، وفق المخاطر والبروتوكول.
نسيان دورة الحياة: لا يكفي إصدار شهادة. يجب إدارة الإنشاء والتوزيع والدوران والإبطال والاستعادة والتدقيق.
قائمة تحقق لأول 90 يومًا
- تشكيل فريق ومالك للمخاطر وخطة تقرير للإدارة.
- تحديد البيانات ذات السرية الأطول والأنظمة عالية القيمة.
- جمع مخزون الشهادات وTLS وSSH وVPN وPKI والمكتبات.
- سؤال أهم عشرة موردين عن دعم FIPS 203 و204 و205 وخارطة التحديث.
- اختيار مختبر غير إنتاجي لتجربة تبادل هجين وقياس الأداء.
- إضافة متطلبات المرونة التشفيرية إلى المشتريات والتطوير.
- وضع عملية مستمرة لتحديث الجرد بعد كل نشر أو شراء.
هذه الخطة لا تدعي إنهاء الهجرة خلال ثلاثة أشهر. هدفها تحويل الموضوع من قلق بعيد إلى برنامج معلوم الأصول والمالكين والأولويات. يمكن لفريق تقوية المواقع والأنظمة المساعدة في الجرد والسياسات وخطة التحديث ضمن نطاق واضح، لكن اختيار الخوارزمية والتنفيذ في الأنظمة المنظمة يجب أن يتبع المعايير والجهات المختصة.
كيف تقدم المشروع للإدارة؟
لا تبدأ بشرح فيزياء الكم. اربط المشروع بمخاطر مفهومة: بيانات يجب أن تبقى سرية بعد 2035، أجهزة يصعب استبدالها، وعقود موردين تحتاج تحديثًا. اعرض الزمن اللازم للجرد والتجربة والتوافق، وميّز بين كلفة الاستعداد الآن وكلفة التغيير الطارئ لاحقًا. اقترح مراحل بقرارات واضحة بدل طلب ميزانية مفتوحة لـ«حل كمي» غير محدد.
اجعل التقرير يقيس نسبة الأصول التي جرى جردها، والأنظمة التي تملك خطة مورد، والاتصالات التي اختُبرت، والعوائق ذات المالك والموعد. هذه مؤشرات أفضل من عدد الشهادات التي تحمل عبارة quantum-safe.
أسئلة شائعة
هل كُسر RSA اليوم بواسطة حاسوب كمي؟
لا توجد واقعة عامة موثوقة لحاسوب كمي ذي صلة قادر على كسر مفاتيح RSA العملية المستخدمة على الإنترنت. الخطة استباقية لأن عمر البيانات وزمن الهجرة طويلان.
هل نستخدم ML-KEM لتشفير الملفات مباشرة؟
ML-KEM آلية لتأسيس أو تغليف مفتاح مشترك، وليس تشفير محتوى ضخم مباشرة. عادة يستخدم المفتاح الناتج مع تشفير متماثل معتمد ضمن بروتوكول صحيح.
هل المعايير الجديدة نهائية؟
FIPS 203 و204 و205 معايير نهائية منشورة. يستمر البحث وإضافة خوارزميات احتياطية، وهذا طبيعي في منظومة تشفير طويلة العمر.
هل Cloudflare أو المتصفح يحلان المشكلة عن مؤسستي؟
قد يحميان الحافة العامة، لكنهما لا يغيران تلقائيًا VPN وSSH والبريد والأجهزة والتوقيعات والاتصالات الداخلية. تحتاج جردًا خاصًا بك.
الخلاصة
الانتقال إلى التشفير ما بعد الكمي مشروع إدارة مخاطر وأصول قبل أن يكون اختيار خوارزمية. ابدأ بمعرفة أين تستخدم المفتاح العام، وأي بيانات يجب أن تبقى سرية، وما الأنظمة التي يصعب تحديثها. طبّق المعايير عبر منتجات وبروتوكولات مراجعة، اختبر الوضع الهجين، وابنِ مرونة تسمح بالتغيير لاحقًا. الانتظار حتى ظهور حاسوب قادر يعني بدء مشروع متعدد السنوات بعد أن يصبح الوقت نفسه جزءًا من الخطر.
المصدر الأساسي: المعهد الوطني الأمريكي للمعايير والتقنية NIST، صفحة Post-Quantum Cryptography ومعايير FIPS المرتبطة، تمت مراجعتها في 15 أكتوبر 2026. هذا المقال توعوي ولا يحدد متطلبات امتثال لمؤسسة بعينها.
