التشفير الكمي: ما يحتاج المطور معرفته فعلاً

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

يأتي هذا التكريم في توقيت لافت. فالحواسيب الكمية القادرة على كسر تشفير RSA لم تُبنَ بعد، وقد لا تُبنى قبل عقد آخر، لكن مجتمع التشفير دخل بالفعل في وضع الترحيل الكامل. فقد أقر NIST أولى معايير التشفير ما بعد الكمي، وتختبر المتصفحات الكبرى تبادل المفاتيح ما بعد الكمي، وطبّقت Signal ذلك في الإنتاج فعلاً. الفجوة بين «ستكسر الحواسيب الكمية التشفير يوماً ما» و«يجب أن نغيّر أنظمتنا الآن» قد أُغلقت.

ما الذي تهدده الحواسيب الكمية فعلاً

معظم التغطية الشائعة للحوسبة الكمية والتشفير إما مثيرة للذعر بشكل مبالغ فيه («كل التشفير انكسر!») أو متشككة بازدراء («لن ينجح أبداً»). الواقع أكثر تحديداً وأكثر إثارة للاهتمام.

تهدد الحواسيب الكمية التشفير غير المتماثل — الأنظمة القائمة على صعوبة التحليل الرياضي للأعداد الكبيرة إلى عوامل أولية (RSA) أو حساب اللوغاريتمات المتقطعة (Diffie-Hellman وECC). إذ تستطيع خوارزمية شور، عند تشغيلها على حاسوب كمي كبير بما يكفي، حل هذه المسائل في زمن كثير الحدود. وهذا يعني أن RSA-2048، الذي يحتاج كسره على الحواسيب التقليدية مليارات السنين، يمكن نظرياً أن يُكسر بحاسوب كمي في غضون ساعات.

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

What's threatened by quantum computers:
BROKEN (by Shor's algorithm):
├── RSA (all key sizes)
├── Diffie-Hellman key exchange
├── Elliptic Curve Cryptography (ECDSA, ECDH)
└── DSA
WEAKENED (by Grover's algorithm):
├── AES-128 → effectively 64-bit security (upgrade to AES-256)
├── AES-256 → effectively 128-bit security (still secure)
└── SHA-256 → effectively 128-bit preimage resistance (still secure)
NOT AFFECTED:
├── One-time pads
├── Hash-based signatures (SPHINCS+)
└── Symmetric encryption with sufficiently large keys

الخلاصة العملية: أي شيء يستخدم التشفير بالمفتاح العام، كمصافحات TLS واتصالات SSH وتوقيع الشيفرة والعملات المشفرة والتواقيع الرقمية، سيحتاج إلى الانتقال إلى خوارزميات مقاومة للحوسبة الكمية. أما التشفير المتماثل فيحتاج في الغالب فقط إلى مفاتيح أطول.

مشكلة «احصد الآن، فك التشفير لاحقاً»

هذا هو السبب الذي يجعل الترحيل عاجلاً رغم أن الحواسيب الكمية لا تستطيع كسر أي شيء حتى الآن. فالخصوم، وفي المقام الأول الدول، يسجّلون على الأرجح حركة المرور المشفرة الآن بنية فك تشفيرها حين تصبح الحواسيب الكمية متاحة.

فكّر في البيانات التي يجب أن تبقى سرية لأكثر من 20 عاماً: المراسلات الدبلوماسية، وتقارير الاستخبارات، والأسرار التجارية، والسجلات الطبية. إذا شُفّرت هذه البيانات بـ RSA أو ECDH اليوم، ووصل حاسوب كمي قادر بعد 15 عاماً، فإن التشفير ينهار بأثر رجعي. كانت البيانات مكشوفة منذ البداية، لكنك لم تكن تعلم بذلك بعد.

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

التشفير ما بعد الكمي: ما الذي اختاره NIST

أجرى NIST مسابقة متعددة السنوات لتوحيد خوارزميات التشفير ما بعد الكمي، على غرار الطريقة التي اختير بها AES. وبعد تقييم عشرات المرشحين، اعتمد ثلاث خوارزميات أساسية:

ML-KEM (Kyber) — آلية تغليف مفاتيح لتبادل المفاتيح، مبنية على مسألة Module Learning With Errors (MLWE) من تشفير الشبكات (lattice). تحل محل Diffie-Hellman وECDH في مصافحات TLS وما شابهها من البروتوكولات. وهي سريعة، وتنتج مفاتيح صغيرة نسبياً، وهي التوصية الأولى لتبادل المفاتيح للاستخدام العام.
ML-DSA (Dilithium) — خوارزمية توقيع رقمي، مبنية أيضاً على تشفير الشبكات. تحل محل RSA وECDSA في التوقيع. التواقيع أكبر من ECDSA (نحو 2.5 كيلوبايت مقابل 64 بايت)، وهذا يؤثر على سلاسل الشهادات والبروتوكولات التي تنقل توقيعات كثيرة.
SLH-DSA (SPHINCS+) — مخطط توقيع رقمي قائم على الدوال التجزيئية (hash). يعتمد أمانه على خصائص دوال التجزئة بدلاً من مسائل الشبكات. وهو أبطأ وينتج تواقيع أكبر من ML-DSA، لكن أمانه يستند إلى افتراضات دوال التجزئة المفهومة جيداً بدلاً من افتراضات الشبكات الأحدث. وهو الخيار الاحتياطي المحافظ.

خوارزميات الشبكات (ML-KEM وML-DSA) مفضلة لأسباب تتعلق بالأداء، لكنها تستند إلى مسائل رياضية حديثة نسبياً مقارنة بعقود التحليل التي خضع لها RSA وAES. هناك احتمال صغير لكنه غير معدوم أن يؤدي اختراق في تحليل الشبكات إلى إضعافها. ويوجد SPHINCS+ كتأمين، فأمانه يقوم على دوال تجزئة درسناها لأكثر من 30 عاماً.

ما هو منشور بالفعل

لم يعد التشفير ما بعد الكمي نظرياً. إنه موجود في أنظمة الإنتاج التي تستخدمها اليوم.

Chrome وFirefox يستخدمان تبادل مفاتيح هجيناً (X25519 + ML-KEM-768) في اتصالات TLS. ومعنى «الهجين» أنهما يجمعان بين تبادل مفاتيح تقليدي وآخر ما بعد الكمي، فإذا كُسر أحدهما بقي الاتصال آمناً. وهذا يضيف نحو 1 كيلوبايت إلى مصافحة TLS.
Signal طبّقت PQXDH، وهو بروتوكول اتفاق مفاتيح ما بعد الكمي، لتبادل المفاتيح الأولي. وكل محادثة جديدة في Signal تتمتع الآن بالسرية التامة للأمام (forward secrecy) ما بعد الكمي.
Apple iMessage قدّمت PQ3، وتستخدم تبادل مفاتيح ما بعد الكمي مع إعادة توليد المفاتيح دورياً. وتزعم Apple أن هذا يوفر أمناً من «المستوى 3»، وهو الأعلى في إطارها.
Cloudflare تدعم تبادل المفاتيح ما بعد الكمي على شبكة توصيل المحتوى الخاصة بها. فإن كنت خلف Cloudflare، فقد تكون اتصالاتك تستخدم ML-KEM دون أن تدري.
AWS KMS تدعم TLS هجيناً ما بعد الكمي لعمليات إدارة المفاتيح.

تحدي الترحيل للمطورين

إذا كنت تبني برمجيات تستخدم التشفير (وهذا ينطبق على معظم البرمجيات تقريباً)، فإليك كيف يبدو الترحيل فعلياً في الممارسة.

TLS: معظمه متكفّل به عنك

إذا كان تطبيقك يستخدم TLS عبر مكتبة قياسية (OpenSSL أو BoringSSL أو crypto/tls في Go)، فإن دعم ما بعد الكمي يُضاف على مستوى المكتبة. ستحصل عليه عبر تحديثات الاعتماديات. أهم ما يجب فعله هو التأكد من عدم تثبيت إصدارات قديمة من مكتبات TLS، وأن أنظمتك تتعامل مع أحجام المصافحة الأكبر قليلاً.

زيادة الحجم أهم مما تظن. فـ ML-KEM-768 يضيف نحو 1,100 بايت إلى رسالة ClientHello في TLS. وبعض الوسطاء (middleboxes) وجدران الحماية وتطبيقات TLS سيئة التنفيذ لا تتعامل مع رسائل ClientHello التي تتجاوز نحو 512 بايت. وقد وجدت تجربة Google في طرح تبادل المفاتيح ما بعد الكمي أن نحو 0.5% من الاتصالات فشلت بسبب عدم توافق الوسطاء. فإذا كان مستخدموك خلف جدران حماية مؤسسية، فاختبر ذلك.

التوقيعات الرقمية: أشد إزعاجاً

التواقيع ما بعد الكمي أكبر بشكل ملحوظ من التقليدية. فتوقيع ECDSA يبلغ 64 بايت، بينما يبلغ توقيع ML-DSA-65 نحو 3,300 بايت، ويمكن أن يتجاوز توقيع SLH-DSA 17,000 بايت. ولهذا آثار متتالية:

تصبح سلاسل شهادات X.509 أكبر بكثير. فسلسلة نموذجية من 3 شهادات بتواقيع ML-DSA أكبر بنحو 10 كيلوبايت من نظيرتها بـ ECDSA. وهذا مهم في الاتصالات المحدودة النطاق.
أنظمة البلوكتشين والعملات المشفرة التي تعتمد على تواقيع مضغوطة تواجه تحديات في قابلية التوسع. فكل معاملة بتوقيع ما بعد الكمي تأخذ مساحة أكبر بـ 50 مرة.
توقيع الشيفرة وتوقيع الحزم والتحقق من تحديثات البرمجيات تحتاج إلى التعامل مع تواقيع أكبر دون كسر افتراضات الحجم في الأدوات الموجودة.
سجلات الشفافية للشهادات، وردود OCSP، وتوزيع CRL، كلها تنمو في الحجم.

التشفير على مستوى التطبيق: مشكلتك أنت

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

جرد اعتماديات التشفير لديك. ابحث عن كل موضع تستخدم فيه شيفرتك RSA أو ECDSA أو ECDH أو Diffie-Hellman. ويشمل ذلك المكتبات وأنظمة إدارة المفاتيح وجهات إصدار الشهادات ووحدات الأمان المادية (HSM).
اعتمد المخططات الهجينة أولاً. اجمع بين الخوارزميات التقليدية وما بعد الكمي. فإذا تبين أن الخوارزمية ما بعد الكمي تحمل ضعفاً، تعود إلى الأمان التقليدي. وإذا وصلت الحواسيب الكمية، تكون لديك حماية ما بعد الكمي.
استخدم مكتبات راسخة. لا تنفذ الخوارزميات ما بعد الكمي بنفسك. استخدم liboqs (Open Quantum Safe)، التي تتكامل مع OpenSSL وتوفر تنفيذات مختبرة لـ ML-KEM وML-DSA وSPHINCS+.
اختبر أثر الأداء. عمليات ما بعد الكمي سريعة عموماً (توليد مفاتيح ML-KEM قريب من ECDH)، لكن التحقق من التواقيع أبطأ، وأحجام المفاتيح والتواقيع تؤثر على عرض النطاق والتخزين.
خطط للمرونة التشفيرية (crypto agility). صمّم بروتوكولاتك بحيث يمكن استبدال الخوارزميات دون كسر البروتوكول. هذا صعب الإضافة لاحقاً، ومن الأسهل بكثير بناؤه من البداية.

ماذا عن توزيع المفاتيح الكمي؟

BB84 لبينيت وبراسار، وهو العمل الذي نالا عنه جائزة تورينغ، هو توزيع المفاتيح الكمي (QKD)، وهو نهج مختلف تماماً. فبدلاً من الاعتماد على مسائل رياضية لا تستطيع الحواسيب الكمية حلها، يستخدم QKD الخواص الفيزيائية لميكانيكا الكم لتوزيع مفاتيح التشفير. وأي محاولة للتنصت على تبادل المفاتيح تُفسد الحالات الكمية وتكون قابلة للكشف.

QKD جميل نظرياً وآمن بشكل مثبت استناداً إلى الفيزياء لا إلى افتراضات حسابية. لكنه عملياً له قيود جدية: يتطلب وصلات ألياف ضوئية مخصصة (لا يمكن تشغيله عبر الإنترنت)، والمسافة القصوى بضع مئات من الكيلومترات دون مكررات كمية (وهي غير موجودة على نطاق واسع بعد)، وهو مكلف للغاية. وقد نشرت الصين شبكة QKD بين بكين وشانغهاي، لكنها تعتمد على عقد تتابع موثوقة تُفقد الغاية منه جزءاً كبيراً من معناه.

على المدى المنظور، يكون التشفير ما بعد الكمي (خوارزميات رياضية على حواسيب تقليدية) هو المسار العملي. أما QKD فيهم وصلات الحكومات والجيوش عالية الأمان، لكنه لن يحل محل TLS في تطبيق الويب الخاص بك.

متى يصبح هذا مهماً فعلاً؟

لا أحد يعرف متى سيوجد حاسوب كمي ذو صلة تشفيرية (CRQC) قادر على كسر RSA-2048. وتتراوح التقديرات بين عام 2030 و«أبداً»، ويتركز معظم الخبراء حول 2035-2040. وأكبر الحواسيب الكمية الحالية تحوي نحو 1,000 كيوبت فيزيائي، بينما يُقدَّر أن كسر RSA-2048 يتطلب ملايين الكيوبتات المنطقية المصححة للأخطاء.

لكن الأمر هو: لا يهم تحديداً متى. فالترحيل نفسه يستغرق سنوات. تحتاج المؤسسات الكبيرة إلى جرد استخدامها للتشفير، وتحديث المكتبات، واختبار التوافق، وتدوير المفاتيح والشهادات، وتحديث البروتوكولات. وينصح NIST بإكمال الانتقال بحلول 2035. وبما أن ترحيلات البرمجيات المؤسسية تستغرق عادةً من 5 إلى 10 سنوات، فإن البدء الآن متأخر بالفعل بحسب كثيرين.

النصيحة العملية مملة لكنها صحيحة: حدّث مكتبات TLS لديك، وخطط لترحيل التواقيع، واعتمد المخططات الهجينة حيثما أمكن، وابنِ المرونة التشفيرية في الأنظمة الجديدة. لست بحاجة إلى الذعر، لكنك بحاجة إلى البدء. أكثر المؤسسات التي ستعاني هي تلك التي تتعامل مع الترحيل ما بعد الكمي كمشكلة مستقبلية، حتى يصبح طارئاً.