معايير التشفير ما بعد الكم من NIST نهائية — ساعة الهجرة تدق

قامت NIST في أغسطس 2024 بتوحيد ثلاثة معايير تشفير ما بعد الكم: ML-KEM (FIPS 203، المستند إلى CRYSTALS-Kyber)، وML-DSA (FIPS 204، المستند إلى CRYSTALS-Dilithium)، وSLH-DSA (FIPS 205، المستند إلى SPHINCS+). بعد عقد من التقييم وجولات متعددة من الخوارزميات، أصبحت هذه المعايير جاهزة للإنتاج. بدأت ساعة الهجرة من يوم إصدار المعايير — وليس من يوم وصول أجهزة الكمبيوتر الكمومية.

الجدول الزمني العملي ليس نظرياً. فرضت الحكومة الأمريكية على الوكالات الفيدرالية البدء في هجرة PQC بحلول عام 2030 لمعظم الأنظمة، مع نقل البنية التحتية المصنفة في وقت أقرب. الصناعة متقدمة بالفعل: قام Google Chrome بشحن ML-KEM المهجن في TLS في عام 2023 وتم تحديثه منذ ذلك الحين إلى نسخة FIPS 203 النهائية. أضافت Apple PQC إلى iMessage مع iOS 17.4. قامت Signal بترقية بروتوكولها في عام 2024. إذا كنت تدير بنية تحتية يُتوقع أن تبقى آمنة لمدة 10 سنوات أو أكثر — خاصة أي شيء يتضمن تبادل المفاتيح غير المتماثل — فإن الهجرة ليست اختيارية.

"اجمع الآن وافكّر لاحقاً" هو تهديد نشط

السبب في أهمية الاستعجال الآن، على الرغم من عدم وجود أجهزة كمبيوتر كمومية ذات صلة بالتشفير بعد، هو هجمات "اجمع الآن وافكّر لاحقاً" (HNDL). يقوم خصوم على مستوى الدول بالتقاط حركة المرور المشفرة اليوم بهدف فك تشفيرها بمجرد ظهور القدرة الكمومية. تقديرات NIST وNSA وCISA تضع أجهزة الكمبيوتر الكمومية ذات الصلة بالتشفير (CRQC) على بعد 10-15 سنة — بالضبط النافذة التي يمكن فيها فك تشفير البيانات التي تم التقاطها في عام 2026 عندما لا تزال ذات قيمة استخباراتية.

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

الفرز: ماذا نهاجر ومتى

ليس كل شيء يحتاج إلى النقل في وقت واحد. الترتيب الصحيح للفرز هو: تبادل المفاتيح أولاً، التوقيعات ثانياً، التشفير المتماثل أخيراً (أو أبداً).

1. تبادل المفاتيح — أعلى أولوية

تبادل المفاتيح RSA وECDH هما أول ما تكسره أجهزة الكمبيوتر الكمومية. استبدلهما بـ ML-KEM (Kyber). المنحدر الآمن القياسي هو الوضع المهجن: تشغيل الكلاسيكي وPQC في وقت واحد. إذا كان لدى ML-KEM ضعف غير مكتشف، فلا يزال الخوارزم الكلاسيكي يحميك. إذا ظهر CRQC، فإن طبقة PQC تغطيك.

X25519MLKEM768 هو المهجن المحدد المستخدم من قبل Chrome وCloudflare وAWS في TLS الإنتاجي اليوم. قد تدعم مجموعتك على الويب ذلك بالفعل: OpenSSL 3.5 (الذي صدر في أبريل 2025) يتضمن دعماً كاملاً لـ ML-KEM وML-DSA. عادةً ما يكون تمكينه علامة تهيئة، وليس تغييراً في الكود.

2. التوقيعات الرقمية — أولوية متوسطة

ML-DSA (Dilithium) يحل محل RSA-PSS وECDSA للتوقيع. الاستعجال هنا أقل لأن التوقيعات لا تعاني من مشكلة HNDL — التوقيع يحتاج فقط إلى أن يكون صالحاً في وقت التحقق، وليس بعد عقد من الزمن. ضع شهادات توقيع الكود، توقيعات المستندات طويلة الأجل، والتسلسلات الهرمية لـ CA الداخلية على خريطة الطريق 2027-2028، وليس على سباق 2026.

3. التشفير المتماثل — أولوية منخفضة

AES-256 وSHA-256 لا تكسرهما أجهزة الكمبيوتر الكمومية. خوارزمية Grover تقلل طول المفتاح الفعال إلى النصف، ولهذا السبب كان AES-256 هو التوصية القياسية لسنوات. إذا كنت تستخدم بالفعل مفاتيح متماثلة بطول 256 بت، فإن التشفير المتماثل لا يتطلب هجرة. إذا كنت لا تزال تستخدم AES-128 للأداء، قم بالترقية إلى AES-256 — هذا هو مدى العمل هنا.

جاهزية المكتبات في منتصف 2026

تقاربت المنظومة على معايير FIPS النهائية عبر جميع اللغات الرئيسية:

Go

حزمة المكتبة القياسية crypto/tls تدعم X25519MLKEM768 اعتباراً من Go 1.24. لعمليات ML-KEM المباشرة خارج TLS، يتضمن golang.org/x/crypto دعماً ثابتاً لـ ML-KEM 768 و1024. تعكس API أنماط المفاتيح غير المتماثلة الحالية: GenerateKey، Encapsulate، Decapsulate مع شرائح بايت محددة النوع.

Python

أضافت pyca/cryptography 44.0.0 (نوفمبر 2024) ML-KEM عبر خلفية OpenSSL 3.5 الخاصة بها. تتبع الواجهة نفس نمط generate_private_key / exchange مثل عمليات EC الحالية. للبيئات التي لا يمكنك فيها التحكم في إصدار OpenSSL، يوفر pqcrypto ربطاً مباشراً بتطبيقات C المرجعية.

Rust

ـ crate ml-kem من مشروع RustCrypto هو تطبيق Rust نقي ومتوافق مع no_std ومتوافق تماماً مع FIPS 203. يدعم متغيرات ML-KEM-512 و768 و1024 وهو الخيار المناسب لأهداف embedded أو WASM حيث لا يمكنك ربط OpenSSL. للجسور إلى نشر Kyber ما قبل التوحيد، يبقى pqcrypto-kyber متاحاً.

Java / JVM

يدعم BouncyCastle 1.77+ ML-KEM وML-DSA بواجهة برمجة تطبيقات مستقرة. قدم OpenJDK 24 ML-KEM كواجهة برمجة تطبيقات معاينة بموجب JEP 496، مع استهداف GA لـ JDK 25. لنشر JVM الإنتاجي اليوم، يمثل BouncyCastle المسار الموثوق.

تمكين PQC المهجن في Service Mesh الخاص بك

لـ mTLS الداخلي بين الخدمات، يمكن تحقيق PQC المهجن دون تغييرات في كود التطبيق. يدعم Envoy Proxy 1.32+ مهجن X25519+ML-KEM عند تجميعه ضد OpenSSL 3.5. التغيير هو تحديث تكوين service mesh لقائمة suites التشفير TLSParameters الخاصة بك. لدى كل من Istio وLinkerd مسارات هجرة موثقة لهذا التكوين.

لـ TLS الحافة، يقوم Cloudflare وAWS CloudFront بالفعل بتفاوض X25519MLKEM768 عندما يدعمه العميل. إذا كنت تنهي TLS على CDN أو موازن تحميل لا تتحكم فيه، تحقق من changelog المزود الخاص بك — قد تكون بالفعل تحت غطاء PQC جزئي دون أن تدري.

جدول زمني ملموس لثلاث سنوات

2026: قم بتدقيق جميع تبادلات المفاتيح عبر الخدمات المواجهة للخارج. حدد إصدارات OpenSSL عبر الأسطول. فعّل X25519MLKEM768 على نقاط نهاية HTTPS (تغيير تكوين). وثّق جميع استخدامات RSA وECDH في سياقات غير TLS: مفاتيح SSH، JWTs، PKI داخلي، أي اشتقاق مفاتيح مخصص.

2027: قم بهجرة تبادل المفاتيح غير TLS إلى ML-KEM. ابدأ إعادة تصميم التسلسل الهرمي لـ CA الداخلي. انقل توقيع الكود إلى ML-DSA لإصدارات القطع الأثرية الجديدة. قيّم هجرة مفاتيح SSH (يدعم OpenSSH 9.x KEX مهجناً قائماً على ML-KEM).

2028–2030: أكمل هجرة التوقيعات. تقاعد RSA من جميع البنى التحتية الجديدة. حقق التوافق مع NIST SP 800-131C والمتطلبات التنظيمية المطبقة (إرشادات HIPAA، أحكام PQC في PCI-DSS 5.0، المعايير الفنية لقانون المرونة السيبرانية للاتحاد الأوروبي).

نقاط عملية قابلة للتنفيذ

• فعّل X25519MLKEM768 في TLS 1.3 على نقاط النهاية العامة اليوم — هذا تغيير تكوين مع حمل أداء ضئيل على الأجهزة الحديثة، ويحمي من HNDL فوراً.
• قم بالترقية إلى OpenSSL 3.5+ أو BouncyCastle 1.77+ قبل كتابة أي كود تشفير جديد؛ حيث تشمل هذه الإصدارات تطبيقات FIPS 203 و204 و205 النهائية.
• قم بتدقيق مساحة سطح RSA وECDH لديك عبر TLS وSSH وتوقيع JWT وPKI الداخلي وأي تبادل مفاتيح مخصص — تبادل المفاتيح هو أعلى أولوية، التوقيعات متوسطة، المتماثل هو الأخير.
• استخدم الوضع المهجن (كلاسيكي + PQC في وقت واحد) كمسار هجرتك، وليس تحولاً صارماً إلى PQC النقي؛ هذا يتوافق مع ما نشرته Google وCloudflare وAWS وApple.
• إذا كنت تتعامل مع بيانات تتطلب سرية لأكثر من 10 سنوات، تعامل مع HNDL كتهديد نشط حالي وضع هجرة تبادل مفاتيح PQC على خريطة طريق الهندسة 2026 الخاصة بك، وليس 2028.