Chrome 151 يضيف خوارزميات تشفير مقاومة للحوسبة الكمية إلى Web Cryptography API
التشفير داخل تطبيقات الويب ظل عالقًا على الخوارزميات الكلاسيكية لأن JavaScript لم تكن تملك بديلًا، والبيانات التي يجب أن تبقى سرية لعشرين عامًا هي أول ما يتأثر بهذا الفراغ.
صدر Chrome 151 في 28 يوليو 2026، ومن أبرز ما فيه للمطورين إضافة خوارزميات تشفير مقاومة للحوسبة الكمية إلى Web Cryptography API، في مرحلة origin trial، أي للتجربة لا للإنتاج. وتشمل الإضافة ML-KEM لتبادل المفاتيح (معيار NIST رقم FIPS 203)، وML-DSA للتوقيع الرقمي (FIPS 204)، وX-Wing لتبادل المفاتيح بطريقة هجينة، وChaCha20-Poly1305 للتشفير المتماثل. كما أزال الإصدار آخر ما تبقى من كود Manifest V2، وأصبح يتطلب macOS 13 أو أحدث.
وتتضح أهمية الخطوة بالتمييز بين طبقتين. فالاتصال بالموقع نفسه، أي TLS، يدعم منذ فترة تبادل مفاتيح مقاومًا للحوسبة الكمية. أما التشفير الذي يجري داخل التطبيق فكان متوقفًا، لأن JavaScript لم تكن تملك هذه الخوارزميات أصلًا. فكان أي تطبيق ويب يعتمد التشفير من طرف إلى طرف مضطرًا لاستخدام الخوارزميات الكلاسيكية.
ويُعدّ تبادل المفاتيح الجزء الأكثر إلحاحًا. فالخطر ليس حاسوبًا كميًا موجودًا اليوم، بل ما يُعرف بـ “سجّل الآن وفك التشفير لاحقًا”: أن يسجل طرف ما حركة البيانات المشفرة ويحتفظ بها حتى تتوفر القدرة على فكها. ومفتاح الجلسة هو ما تحتاجه الجلسة المسجلة، وتبادل المفاتيح هو ما يحدده. أما التوقيع فأقل إلحاحًا، لأنه يحتاج أن يكون موثوقًا لحظة التحقق فقط.
وتعني كلمة “هجين” في X-Wing الجمع بين تبادل مفاتيح كلاسيكي وML-KEM، بحيث تبقى الجلسة آمنة ما دام أحدهما صامدًا. وهو احتياط من احتمال ظهور عيب في الخوارزمية الجديدة نفسها، لا من الحوسبة الكمية وحدها.
وبالنسبة للتطبيقات في المنطقة، يتعلق السؤال بعمر سرية البيانات: الهوية الرقمية والملفات الطبية والعقود بيانات تعيش 20 أو 30 عامًا، وهي تحديدًا ما يستهدفه التسجيل اليوم.
المصادر
من عدد الثلاثاء 14 صفر - 28 يوليو