SSH وTLS بعد الكم

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

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

أين تقف تقنيات ما بعد الكم فعلياً في 2026

تبادل المفاتيح انتهى. ليس مخططاً ولا تجريبياً، بل صادراً ومفعّلاً افتراضياً وقيد التشغيل. يوفّر OpenSSH تبادل مفاتيح مقاوماً للحوسبة الكمية منذ الإصدار 9.0 في أبريل 2022، ومنذ OpenSSH 10.0 في أبريل 2025 صار الهجين mlkem768x25519-sha256 هو الخوارزمية الافتراضية. أما OpenSSL 3.5.0، الصادر قبله بيوم واحد، فقد غيّر قائمة مجموعات TLS الافتراضية لتضم المجموعات الهجينة المقاومة للكم وتفضّلها، ويقدّم الآن X25519MLKEM768 كـ keyshare افتراضي. من حدّث أياً من الحزمتين خلال العام الماضي فقد فعّل كل هذا دون أن يفعل شيئاً.^{[ssh100][ossl35]}

القياسات تؤكد الصورة. تنشر Cloudflare منذ 2023 أرقام تبنّي تبادل المفاتيح المقاوم للكم، وقد ارتفع المنحنى خلال عامين تقريباً من خطأ تقريب إلى غالبية حركة الويب البشرية. راجع الرقم الحيّ بدل الوثوق بأي مقال، بما في ذلك هذا المقال: المهم ليس النسبة الدقيقة بل شكل المنحنى، فهو ما يخبرك بأن المتأخرين صاروا مجموعة محدودة قابلة للحصر لا الإنترنت بأكمله.^{[cfpq][cfradar]}

أما التواقيع فالقصة معكوسة تماماً. اعتمد NIST معياري ML-DSA وSLH-DSA في 2024، والتطبيقات موجودة، ولا شيء من ذلك قابل للنشر على الويب العام، لأن الشهادة لا تنفع إلا إذا كان الطرف المتحقق يثق أصلاً بالجذر الذي وقّعها، ولا يوجد أي جذر مقاوم للكم في مخازن الثقة داخل المتصفحات. هذه ليست مشكلة تغليف مؤقتة يمكن الالتفاف عليها هندسياً، بل مسألة ترتيب داخل المنظومة، ومداها سنوات.

اجمع الآن وفك التشفير لاحقاً — وما لا يشمله هذا الهجوم

سبب كون تبادل المفاتيح عاجلاً والتواقيع غير عاجلة يعود إلى عدم تماثل واحد، ويصوغه OpenSSH بوضوح يفوق أغلب مواد الشركات:^[pq]

خصوصية اتصال SSH بأكملها تعتمد على تبادل المفاتيح التشفيري. فإن استطاع مهاجم كسره، أمكنه فك تشفير الجلسة كاملة والاطلاع عليها. وليس عليه تنفيذ الهجوم في الوقت الحقيقي: يمكنه جمع جلسات SSH المشفّرة الآن ثم فك تشفيرها لاحقاً حين يحصل على حاسوب كمي.^[pq]

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

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

تتراوح التقديرات لموعد ظهور حاسوب كمي ذي دلالة تشفيرية بين خمس وعشرين سنة، ويرجّح كثير من المراقبين منتصف الثلاثينيات. لست بحاجة إلى رأي في هذا الرقم، بل إلى معرفة ما إذا كانت البيانات التي تنقلها اليوم ستظل حساسة عند حلول ذلك الموعد، والإجابة الصادقة لمعظم البنى التحتية هي: نعم.^[pq]

إصلاح SSH

SSH هو المكسب السهل ونقطة البداية الصحيحة، لأن OpenSSH أنجز الجزء الصعب نيابة عنك. لا إضافة ولا مزوّد يُثبَّت ولا فرع تجريبي؛ هناك رقم إصدار وسطر إعداد فقط، وكلاهما موثّق من المشروع نفسه.^{[ssh100][pq][ssh105][sshrel]}

في هذا الجدول فخّان. الأول هو الاسم: الصيغة القصيرة sntrup761x25519-sha512 لم تظهر إلا من 9.9، فما قبلها يتطلب كتابة صيغة @openssh.com، وsshd يرفض الإقلاع أمام اسم لا يعرفه. والثاني أشد مكراً: الوجود في القائمة الافتراضية ليس كالاختيار منها. ففي OpenSSH 8.9 تأتي الخوارزمية المقاومة للكم ضمن KexAlgorithms الافتراضية لكنها في الترتيب السادس، أسفل curve25519-sha256، فيتفاوض كل عميل حديث مع ذلك الخادم على تبادل تقليدي بينما يعلن الخادم بصدق أنه يدعم ما بعد الكم. وهذا بعينه سبب إلحاح المقال على قراءة النتيجة المتفاوَض عليها لا قائمة الإمكانات.^{[ssh85][ssh99][ntru]}

الخطوة الأولى: اعرف ما تتفاوض عليه فعلاً

قبل تغيير أي شيء، قِس. التمييز الذي يعثر عنده أغلب الناس هو بين المدعوم والمتفاوَض عليه: قد يدعم الخادم ML-KEM ومع ذلك ينهي تبادلاً تقليدياً، لأن عميلاً قديماً طلب ذلك وقائمة تفضيلات الخادم سمحت به. الخوارزمية المتفاوَض عليها وحدها تخبرك إن كان اتصال بعينه محمياً فعلاً.

# 1. Your client. Anything older than 8.5 has no post-quantum key agreement
#    at all; 8.5 through 9.8 have it only under the @openssh.com vendor name.
ssh -V
# OpenSSH_10.5p1, OpenSSL 3.5.7 9 Jun 2026

# 2. The remote server's software version, straight from the protocol banner.
ssh -v server.example.com exit 2>&1 | grep 'remote software version'
# debug1: Remote protocol version 2.0, remote software version OpenSSH_10.3

# 3. Which key agreement algorithms your local build even supports.
ssh -Q kex | grep -E 'mlkem|sntrup'
# mlkem768x25519-sha256
# sntrup761x25519-sha512

# 4. Supported is not preferred. On OpenSSH 8.9, for example, the PQ algorithm
#    is in the default list but sixth in it, so it is offered and never chosen:
ssh -G server.example.com | grep -i '^kexalgorithms'
# kexalgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,
# ecdh-sha2-nistp384,ecdh-sha2-nistp521,sntrup761x25519-sha512@openssh.com,...
#                                       ^ present, but nothing will ever pick it

# 5. The only answer that matters: what did THIS connection actually agree on?
#    Everything above is capability; this line is the negotiated result.
ssh -v server.example.com exit 2>&1 | sed -n 's/.*kex: algorithm: /negotiated: /p'
# negotiated: mlkem768x25519-sha256

ما إن تتقن قراءة هذا السطر على مضيف واحد حتى تتقنه على الجميع. أضاف OpenSSH 10.1 تحذيراً في جهة العميل عند التفاوض على تبادل غير مقاوم للكم، وهو ممتاز للبشر وعديم الفائدة للوصلات المؤتمتة التي تشكّل معظم أي أسطول حقيقي. لذا امسح بنفسك:^[ssh101]

#!/usr/bin/env bash
# pq-ssh-sweep.sh - classify every host in hosts.txt by negotiated key agreement.
# Read-only: it opens a connection, runs `exit`, and reads the debug output.
set -uo pipefail

while read -r host; do
  [ -z "$host" ] && continue
  # </dev/null matters: without it ssh swallows the rest of hosts.txt from the
  # loop's stdin and you silently audit only the first host.
  alg=$(ssh -o BatchMode=yes -o ConnectTimeout=5 -o StrictHostKeyChecking=accept-new \
        -v "$host" exit </dev/null 2>&1 | sed -n 's/.*kex: algorithm: //p' | head -1)
  case "$alg" in
    mlkem*)   printf '%-38s PQ-ML-KEM  %s\n' "$host" "$alg" ;;
    sntrup*)  printf '%-38s PQ-LEGACY  %s\n' "$host" "$alg" ;;
    "")       printf '%-38s UNREACHED  (auth, firewall or timeout)\n' "$host" ;;
    *)        printf '%-38s CLASSICAL  %s\n' "$host" "$alg" ;;
  esac
done < hosts.txt

# PQ-ML-KEM  -> done, nothing to do.
# PQ-LEGACY  -> safe today (sntrup761 is quantum-resistant) but not the NIST
#               standard; schedule the upgrade to OpenSSH 9.9+ anyway.
# CLASSICAL  -> this is your harvest-now-decrypt-later exposure. Fix first.

الخطوة الثانية: غيّر الإعدادات بحذر

بعد إتمام المسح يصبح التعديل نفسه صغيراً. ضعه في ملف drop-in بدل تحرير الإعداد الرئيسي، ليبقى قابلاً للبحث والتراجع وواضحاً أنه من صنعك:^{[sshdcfg][ssh99]}

# /etc/ssh/sshd_config.d/50-post-quantum.conf
# Requires `Include /etc/ssh/sshd_config.d/*.conf` in the main sshd_config,
# which Debian, Ubuntu, RHEL and Fedora already ship. Check with:
#   grep -r '^Include' /etc/ssh/sshd_config

# --- OpenSSH 9.9 and newer ---
# Post-quantum first, classical last. The list is ordered by preference, and
# the two hybrids are the only entries here that resist a quantum adversary.
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256,curve25519-sha256@libssh.org

# --- OpenSSH 9.0 to 9.8: NEITHER name above exists on those builds. ---
# ML-KEM only arrived in 9.9, and until 9.9 the NTRU Prime hybrid existed
# solely under its vendor extension name. sshd refuses to start on an
# unknown algorithm name, so on those versions use exactly this line and
# nothing from the one above:
#   KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256
# Confirm which names your build accepts before editing:  ssh -Q kex

# Signatures are NOT the urgent problem (see the article), but this is a good
# moment to drop the algorithms that are weak for classical reasons too.
HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256
PubkeyAcceptedAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,rsa-sha2-512,rsa-sha2-256

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

# --- Validate BEFORE reloading, and keep your current session open. ---
#   sudo sshd -t && sudo systemctl reload ssh   # or sshd, depending on the distro
# Then open a SECOND session and confirm it works before closing the first.

لا تتخطَّ طقس التحقق. نفّذ sshd -t قبل إعادة التحميل، وأبقِ جلستك الحالية مفتوحة، وافتح جلسة ثانية للتأكيد قبل إغلاق الأولى. خطأ مطبعي واحد في KexAlgorithms يقفل عليك المضيف، وعلى جهاز بلا وصول إلى وحدة تحكم فهذا ليس حادثاً بل إعادة تثبيت.

في جهة العميل يمكنك أن تكون أكثر صرامة، لأن الفشل الصاخب على حاسوبك الشخصي محتمل بينما لا يُحتمل على مضيف وسيط مشترك. النمط الذي يصمد أمام الواقع هو إعداد افتراضي صارم مع استثناءات صريحة ومؤرَّخة:^[sshcfg]

# ~/.ssh/config - client side
#
# ssh_config is FIRST-OBTAINED-VALUE-WINS, not last. The specific block must
# come BEFORE `Host *`, otherwise the general block wins and the exception
# below is silently dead. This is the single most common mistake in hardened
# client configs, and it fails in the direction you will not notice.

# Exceptions first: the boxes you have not fixed yet. Make each one explicit
# and dated, so it shows up in review instead of quietly becoming permanent.
Host legacy-nas.internal jump-2019.example.com
    # TODO(2026-11-30): appliance firmware pending, ticket OPS-4471
    # Note this REPLACES the list rather than using `+`, which would append to
    # the full compiled-in default and quietly re-enable every modp group.
    KexAlgorithms curve25519-sha256,diffie-hellman-group-exchange-sha256
    WarnWeakCrypto no-pq-kex

# ...and the hard default for everything else.
Host *
    KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512
    WarnWeakCrypto yes

# Verify the result rather than trusting the file. `ssh -G` prints the
# effective configuration for a given destination, after all matching:
#   ssh -G legacy-nas.internal | grep -i '^kexalgorithms'
#   ssh -G anything-else.example.com | grep -i '^kexalgorithms'

تفصيلان يستحقان الترسيخ. أولاً، كل خوارزميات ما بعد الكم التي ينفّذها OpenSSH هجينة: فـmlkem768x25519-sha256 يشغّل ML-KEM إلى جانب X25519 ويدمج الاثنين، فحتى لو كسر تحليل تشفيري مستقبلي خوارزمية ML-KEM لن تكون النتيجة أضعف من التبادل التقليدي الذي كنت تستعمله. لا يوجد سيناريو خاسر. ثانياً، إن كنت على OpenSSH 9.x ولا تستطيع الترقية فإن هجين NTRU Prime مقاوم للكم ومتاح منذ 9.0، لكن انتبه إلى الاسم: قبل الإصدار 9.9 لا يوجد إلا بالصيغة sntrup761x25519-sha512@openssh.com، وستُرفض الصيغة القصيرة. ليس معيار NIST، لكنه يوقف هجوم الجمع اليوم، وهذا هو المقصود.^[pq]

إصلاح TLS

TLS له الشكل نفسه برافعة مختلفة. البدائيات موجودة في OpenSSL لا في خادم الويب: مع OpenSSL 3.5 أو أحدث لا تحتاج إلى تصحيحات ولا إلى oqs-provider ولا إلى nginx متفرّع. تحقق من المكتبة أولاً، فهنا تكمن أغلب المفاجآت: قد توزّع إحدى التوزيعات nginx حديثاً مرتبطاً بـ OpenSSL لا يعرف ML-KEM إطلاقاً.^{[ossl35][tlsdraft][mlkemkex]}

# 1. ML-KEM needs OpenSSL 3.5.0 or newer. No 3.x before 3.5 can do it at all,
#    however recent the rest of the stack looks.
openssl version
# OpenSSL 3.5.7 9 Jun 2026

# 2. Confirm the provider actually exposes the primitives.
openssl list -kem-algorithms | grep -i mlkem
openssl list -signature-algorithms | grep -iE 'ML-DSA|SLH-DSA'

# 3. What does a live endpoint negotiate when the client offers the hybrid?
openssl s_client -connect www.example.com:443 -servername www.example.com \
  -groups X25519MLKEM768 -tls1_3 </dev/null 2>/dev/null \
  | grep -E 'Negotiated TLS1.3 group|Protocol  :|Cipher    :'
# Negotiated TLS1.3 group: X25519MLKEM768

# 4. Control test: the same endpoint must still serve a classical-only client,
#    otherwise you have not hardened it, you have broken it.
openssl s_client -connect www.example.com:443 -servername www.example.com \
  -groups X25519 -tls1_3 </dev/null 2>/dev/null \
  | grep 'Negotiated TLS1.3 group'
# Negotiated TLS1.3 group: X25519

انتبه إلى اختبار الضبط في الخطوة الرابعة. تفعيل مجموعة هجينة لا يُفترض أن يكسر العملاء التقليديين، وإن كسرهم فأنت أخطأت في ضبط القائمة لا أنك حصّنت شيئاً. الترتيب مهم والحصرية ليست كذلك: ضع الهجين أولاً واترك المنحنيات التقليدية خلفه.^[osslgroups]

# Pick the ONE stanza that matches your terminator - this is four different
# config syntaxes in one block, not a file you can paste as-is.

### nginx (built against OpenSSL 3.5+; no patches, no oqs-provider needed)
# ssl_ecdh_curve feeds the TLS supported-groups list. Hybrid first, then the
# classical curves that keep older clients working.
ssl_protocols       TLSv1.3 TLSv1.2;
ssl_ecdh_curve      X25519MLKEM768:X25519:secp256r1;
ssl_prefer_server_ciphers off;

### HAProxy 3.x
ssl-default-bind-curves X25519MLKEM768:X25519:secp256r1

### Apache httpd (mod_ssl passes the list straight to OpenSSL)
SSLOpenSSLConfCmd Groups X25519MLKEM768:X25519:P-256

### OpenSSL system-wide default, for everything that reads openssl.cnf
# [openssl_init] -> ssl_conf -> system_default
Groups = X25519MLKEM768:X25519:secp256r1

الإعداد سطر واحد لكل خادم، وهو في كل الحالات يغذّي قائمة المجموعات المدعومة نفسها في OpenSSL:^{[nginxssl][haproxy][osslconf]}

النقطة المعمارية الوحيدة الواجب ضبطها: كل هذا ينطبق حيث يُنهى اتصال TLS. فإن كانت شبكة توصيل محتوى أو موازن أحمال ينهيه بالنيابة عنك، فتلك هي القفزة التي تحتاج إلى المجموعة الهجينة، وإعداد خادم الأصل مسألة منفصلة، وكذلك الوصلة بينهما، وهي بالضبط الجزء الداخلي الذي يُنسى. وإن كنت تنهي الاتصال داخل Kubernetes فمكان ذلك هو البوابة، والانتقال من ingress-nginx لحظة طبيعية لتنفيذه ما دمت ستعيد كتابة تلك الكائنات على أي حال.^[rfc8446]

جرد يمكنك الدفاع عنه أمام المدقق

كل ما سبق يخص مضيفاً واحداً. أما ما سيطلبه المدققون، وما ستطلبه أنت لاحقاً، فهو التغطية: لا «هل أُصلح هذا الطرف؟» بل «كم عددها وأيها لم يُصلح؟». ابنِ القائمة من مصدر الحقيقة الذي تثق به أصلاً لا من مسح للشبكة، حتى يصبح للغياب معنى:

#!/usr/bin/env bash
# pq-inventory.sh - a starting point, not a CBOM. One line per listener, with
# the negotiated group, so the output diffs cleanly between runs.
set -uo pipefail
printf '%-34s %-9s %-22s %s\n' HOST PORT GROUP NOTE

while IFS=: read -r host port; do
  out=$(openssl s_client -connect "$host:$port" -servername "$host" \
        -groups X25519MLKEM768:X25519 -tls1_3 </dev/null 2>/dev/null)
  grp=$(printf '%s' "$out" | sed -n 's/^Negotiated TLS1.3 group: //p')
  sig=$(printf '%s' "$out" | sed -n 's/^Peer signature type: //p')
  case "$grp" in
    *MLKEM*) note="pq-ok" ;;
    "")      note="no-tls1.3-or-unreachable" ;;
    *)       note="classical-only" ;;
  esac
  printf '%-34s %-9s %-22s %s (sig %s)\n' "$host" "$port" "${grp:--}" "$note" "${sig:--}"
done < endpoints.txt

# endpoints.txt is one host:port per line. Feed it from whatever you already
# trust as the source of truth - the load balancer config, Consul, the CMDB -
# rather than from a network scan, so that absence is meaningful.

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

1. إنهاء TLS الخارجي. كل اسم مضيف عام. أقصر قائمة وأعلى تعرّض، وغالباً يُحل بتغيير واحد عند الحافة.
2. SSH في كل مكان. المضيفات الوسيطة أولاً ثم كل ما يمكن الوصول إليه منها. هنا يظهر الذيل الطويل من الأجهزة ومعدات الشبكة والأجهزة الافتراضية المنسية.
3. TLS الداخلي بين الخدمات. شبكة الخدمات، واتصالات قواعد البيانات، ووسطاء الرسائل. قائمة أطول وأصعب في الحصر، وهي أيضاً الموضع الذي ربما حلّته إعدادات الشبكة الافتراضية نيابة عنك.
4. شبكات VPN والأنفاق بين المواقع. طويلة العمر وعالية القيمة وغالباً تعمل ببرامج ثابتة من المورّد لها جدولها الخاص. ابدأ الحوار مع المورّد مبكراً، فهذه مشكلة مشتريات أكثر منها مشكلة تقنية.
5. كل ما هو مضمَّن. الأجهزة والوكلاء والطابعات والكاميرات ووحدات التحكم الصناعية. وثّقها واقبل المخاطرة صراحةً وضع تاريخاً لهذا القبول.

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

التواقيع والشهادات: لماذا الانتظار هو القرار الصحيح

نصل الآن إلى الجزء الذي تكون فيه النصيحة المفيدة هي أن تفعل أقل. اعتمد NIST في 2024 نظامَي توقيع مقاومين للكم هما ML-DSA وSLH-DSA، وكلاهما منفَّذ في OpenSSL 3.5. تستطيع توليد المفاتيح اليوم، لكن لا ينبغي أن تضعها في سلسلة شهاداتك.^{[fips204][fips205][fips203]}

والسبب هو ذاته الذي يذكره OpenSSH في تفسير أولوية تبادل المفاتيح: لا وجود لهجوم «خزّن الآن وزوّر لاحقاً». يكفي أن يكون التوقيع غير قابل للتزوير في لحظة التحقق منه. إلحاح مسألة التواقيع لا يتعلق بحماية حركة اليوم بل بضمان سحب مفاتيح التوقيع التقليدية من الخدمة قبل وجود حاسوب كمي ذي دلالة تشفيرية، وهو موعد يُقاس بالسنوات لا بالحزم الملتقطة.^[pq]

العوائق العملية ذات طبيعة منظومية، ولا واحد منها ضمن نطاق حلّك:

• لا تثق المتصفحات بأي جذر مقاوم للكم. قيمة سلسلة الشهادات من قيمة الجذر الذي يثق به الطرف المتحقق أصلاً، وهذه المخازن تتحرك على إيقاع سنوات عدة، ولأسباب وجيهة.
• مشكلة الحجم حقيقية. تواقيع ML-DSA ومفاتيحها العامة أكبر بوضوح من نظيراتها في ECDSA. وفي مصافحة تحمل السلسلة كاملة يُقاس ذلك برحلات ذهاب وإياب إضافية على الوصلات ذات الفقد، لا ببايتات مجردة.
• لا يملك OpenSSH سوى نظام توقيع تجريبي مقاوم للكم. أزال المشروع دعم XMSS التجريبي في 10.1، ثم أضاف في 10.4 (يوليو 2026) نظاماً مركّباً باسم mldsa44-ed25519 يجمع ML-DSA-44 مع Ed25519. وهو تجريبي صراحةً وغير مفعّل افتراضياً: عليك إضافته بنفسك إلى HostKeyAlgorithms وPubkeyAcceptedAlgorithms وتوليد المفاتيح بـssh-keygen -t mldsa44-ed25519. جدير بالمعرفة، لكنه ليس جديراً بعد بأن توضع تحته مفاتيح مضيف إنتاجية.^{[ssh104][mldsased][ssh101]}
• يجب أن يوافق كل وسيط في الطريق. يشارك في التحقق من الشهادة خادمك والعميل وكل جهاز وسيط يفحص المرور وأي تثبيت مفاتيح أضافه أحدهم في 2019. التواقيع تفشل بالإغلاق، وتفشل للجميع دفعة واحدة.

فماذا تفعل بالتواقيع في 2026 إذاً؟ أمران، وكلاهما رخيص. تقاعد الخوارزميات الضعيفة أصلاً لأسباب تقليدية: اختفت DSA تماماً في OpenSSH 10.0، وكان ينبغي لتواقيع SHA-1 أن ترحل منذ سنوات. واجعل إصدار الشهادات آلياً وقصير العمر، حتى إذا صار إصدار الشهادات المقاومة للكم ممكناً كان استبدالها تغييراً في الإعداد لا مشروعاً. الرشاقة التشفيرية ليست منتجاً يُشترى بل خاصية القدرة الحالية على التدوير السريع، وهي شيء ينبغي أن ترغب فيه لأسباب أخرى تماماً. وتنطبق هنا الغريزة نفسها الكامنة خلف المعماريات المملة: الخيار الغريب ليس الخيار الآمن.^[ssh103]

الجدول التنظيمي بصياغة دقيقة

المواعيد النهائية هي المكان الذي تصبح فيه المقالات التقنية خاطئة دون أن تنتبه، وإليك الصياغة الدقيقة. وثيقة NIST IR 8547، التي يستشهد بها الجميع لعبارة «RSA سيُهجر في 2030»، هي مسودة عامة أولية نُشرت في نوفمبر 2024. أُغلقت فترة التعليق عليها في يناير 2025، والتعليقات الواردة منشورة. هي تشير إلى النهج المتوقع من NIST وتصلح أساساً للتخطيط، لكن الاستشهاد بها بوصفها معياراً نهائياً ملزماً غير دقيق، وسيعرف ذلك أحدهم في مراجعتك.^[ir8547]

التمييز مهم عملياً: المسودة تخبرك إلى أين تتجه الأرضية، وهذا يكفي للتخطيط. لكنه لا يكفي لتكتب «مطلوب من NIST» في وثيقة تصميم. استشهد بها بوصفها مسودة، وسيصمد برنامجك أمام أول مراجعة جادة.^[ir8547]

تسير أوروبا في مسار موازٍ بآلية مختلفة. اعتمدت الدول الأعضاء عبر مجموعة تعاون NIS خارطة طريق تنفيذ منسّقة، مبنية على بدء الانتقال وتشغيل مشاريع تجريبية قبل نهاية 2026، وإنجاز حالات الاستخدام عالية المخاطر والبنى التحتية الحرجة بحلول 2030، والاكتمال بالقدر الممكن عملياً بحلول 2035. هي أداة تنسيق لا لائحة تنظيمية، لكنها المرجع الذي تُكتب في ضوئه خرائط الطريق الوطنية، فإن كنت تعمل داخل الاتحاد الأوروبي فهذه هي الوثيقة التي قرأها منظّم قطاعك.^[euroadmap]

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

خطة تسعين يوماً

إن أردت كل ذلك في صفحة واحدة فهو هنا. المنطلق أن تبادل المفاتيح مشكلة محلولة تقوم بنشرها فحسب، وكل ما عداه تحضير.

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

خمسة أخطاء تستحق التجنب

أنماط تتكرر في عمليات الترحيل الحقيقية، مرتبة تقريباً بحسب ما تكلّفه من وقت:

1. تدقيق القدرة بدل التفاوض. عبارة «خوادمنا تدعم ML-KEM» ليست نتيجة تدقيق. قد يدعمه الخادم ويظل ينهي مصافحات تقليدية طوال اليوم من أجل عميل قديم واحد. اقرأ الخوارزمية المتفاوَض عليها في الاتصال لا قائمة المدعوم.
2. إزالة الخوارزميات التقليدية. الهجائن موجودة تحديداً كي لا تضطر إلى الاختيار. ضع المجموعة المقاومة للكم أولاً وأبقِ X25519 خلفها، فتكسب الحماية دون حادث توافر.
3. ملاحقة الشهادات. الوقت المبذول في 2026 لمحاولة نشر شهادات ML-DSA هو وقت غير مبذول على التبادل الذي يُجمع فعلاً. أتمت الإصدار بدلاً من ذلك؛ هذا هو العمل الذي سيؤتي ثماره لاحقاً.
4. التوقف عند الحافة. مصافحة شبكة توصيل المحتوى مقاومة للكم والوصلة إلى الأصل ليست كذلك. هذه أكثر الفجوات شيوعاً بفارق كبير، لأن الاختبار الخارجي ينجح ولا يوجد مستخدم يشتكي من الجزء الداخلي.
5. التعامل معه كعمل لمرة واحدة. صورة أساس أُعيد بناؤها، وحزمة مثبّتة على إصدار، وإعداد أُعيد إلى سابقه، فيصبح مضيف كان ممتثلاً في مارس متفاوضاً بالتقليدي في سبتمبر. ضع المسح على مؤقّت وأطلق تنبيهاً عند ارتفاع العدد.

الخلاصة المختصرة

تبادل المفاتيح المقاوم للكم ليس مشروعاً مستقبلياً، بل إعداد افتراضي ورثته على الأرجح بالفعل، وكل العمل هو العثور على الاتصالات التي فاتها. رقِّ إلى OpenSSH 10.x وOpenSSL 3.5+، وضع المجموعة الهجينة أولاً في كليهما، وامسح الأسطول بحثاً عما يُتفاوض عليه فعلاً، ودوّن الاستثناءات مع تواريخها. هذا أسبوع عمل لدى معظم الفرق، وهو يغلق الهجوم الوحيد في هذا المجال الجاري اليوم.

ثم توقّف. لا تُرحّل الشهادات، ولا تشترِ منصة رشاقة تشفيرية، ولا تكتب كلمة «كمي» في وثيقة استراتيجية. اجعل إصدار الشهادات آلياً وقصير العمر، وأبقِ الجرد محدّثاً، وانتظر المنظومة؛ فحين تصبح التواقيع المقاومة للكم قابلة للنشر لن تكون المؤسسات الأنجح هي التي بدأت أبكر، بل التي تستطيع اليوم تدوير شهادة دون نافذة تغيير.

أسئلة شائعة

هل عليّ فعل شيء إن كنت أستخدم OpenSSH 10 بالفعل؟

تحقّق، ثم على الأرجح لا. القيمة الافتراضية هي mlkem768x25519-sha256، لكن خط أساس تحصين أو قالباً مشتقاً من CIS أو وحدة إدارة إعدادات قد تكون كتبت سطر KexAlgorithms خاصاً بها سابقاً لظهور ML-KEM فيستبعده بصمت. نفّذ ssh -v host exit 2>&1 | grep 'kex: algorithm' على مضيف حقيقي واقرأ النتيجة المتفاوَض عليها. وللجلسات الواردة يكون الحاسم هو جهة الخادم.

هل يكسر تفعيل التبادل المقاوم للكم العملاءَ القدامى؟

لا، إن ضبطته تفضيلاً لا تقييداً. كل من KexAlgorithms في SSH وقائمة المجموعات المدعومة في TLS تفضيلات مرتّبة: ضع الهجين أولاً وأبقِ curve25519-sha256 أو X25519 خلفه، فتحصل الأطراف الحديثة على التبادل المقاوم للكم بينما ترتد الأقدم إلى التقليدي. العطل يحدث حين تحذف المدخلات التقليدية كلياً، وهو خيار يمكن الدفاع عنه لأسطول مغلق تسيطر عليه بالكامل، وخيار سيئ لأي شيء عام.

هل يكفي sntrup761x25519-sha512 أم يجب الانتقال إلى ML-KEM؟

هو مقاوم للكم فعلاً ويوقف اليوم هجوم «اجمع الآن وفك لاحقاً»، وهذه هي الخاصية المطلوبة. ضعفه في التقييس لا في التشفير: لم يختر NIST خوارزمية NTRU Prime، فهو لن يفي بنظام امتثال مكتوب حول FIPS 203، ودعم التطبيقات على المدى الطويل أقل يقيناً. إن كنت على OpenSSH 9.0–9.8 ولا تستطيع الترقية هذا الربع فأنت محمي، لكن خطّط للانتقال إلى 9.9+ على أي حال.

لماذا لا أستطيع نشر شهادات مقاومة للكم الآن؟

لأن الشهادة لا تنفع إلا إذا كان الطرف المتحقق يثق أصلاً بالجذر الذي وقّعها، ولا يوجد جذر مقاوم للكم في مخازن ثقة المتصفحات. تستطيع توليد مفاتيح ML-DSA عبر OpenSSL 3.5 وإقامة سلطة تصديق داخلية بها، وهي تجربة معقولة لنظام مغلق. أما كل ما يلمسه متصفح فلن تُقبل سلسلته. هذه مسألة ترتيب في المنظومة لا مسألة إعداد، وحلّها يستغرق سنوات.

كيف أتحقق مما تتفاوض عليه نقطة TLS لديّ فعلاً؟

openssl s_client -connect host:443 -servername host -groups X25519MLKEM768 -tls1_3 </dev/null 2>/dev/null | grep 'Negotiated TLS1.3 group'. تحتاج إلى عميل OpenSSL 3.5+ للاختبار نفسه؛ فالاختبار بعميل أقدم يعطي نتيجة سلبية كاذبة لأن عميلك لم يعرض المجموعة أصلاً. ونفّذ دائماً اختبار الضبط بـ-groups X25519 أيضاً لتتأكد أنك حصّنت النقطة لا أنك كسرتها.

هل يجب أن أقلق بشأن AES وSHA-256؟

لا. تمنح خوارزمية جروفر تسريعاً تربيعياً ضد البدائيات المتماثلة، ما ينصّف عملياً طول المفتاح: يحتفظ AES-256 بهامش أمان 128 بت، ويبقى SHA-256 كافياً. أما AES-128 فمحل نقاش أوسع لكنه ليس الشاغل العملي. الخوارزميات غير المتماثلة — RSA وECDH وECDSA — هي ما تكسره خوارزمية شور من أساسه، وهي موضوع هذا المقال بالكامل.

وماذا عن شبكات VPN وقواعد البيانات وطوابير الرسائل؟

القاعدة نفسها والتنفيذ أصعب. لا يتضمن بروتوكول WireGuard الأساسي تبادل مفاتيح مقاوماً للكم، ويعتمد على آلية المفتاح المشترك مسبقاً لتكوين ترتيب هجين. ودعم IPsec يعتمد كلياً على البرنامج الثابت لدى مورّدك. أما TLS في قواعد البيانات والوسطاء فيتبع عادةً مكدّس TLS الخاص ببيئة التشغيل لا OpenSSL النظام، فتحقق من كل واحد على حدة بدل افتراض أن إعداداً على مستوى النظام قد وصل إليه. وهذه الوصلات هي أيضاً أعلى الأهداف قيمة، لأن حمولتها هي بالضبط البيانات السرية طويلة العمر التي صُمم هجوم الجمع لالتقاطها.

هل هذا استعراض امتثال أم تهديد حقيقي؟

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

كل ما سبق يفترض أن النظام الأساسي ثابت، وهو ليس كذلك: راجع ترقية Ubuntu 24.04 إلى 26.04 على الخوادم للاطلاع على ترقية الإصدار التي تستبدل ستة من هذه الإعدادات الافتراضية.

المصادر

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

1. OpenSSH — Post-Quantum Cryptography (project page, FAQ and warning text)
2. OpenSSH 9.9 release notes (19 September 2024) — ML-KEM hybrid added; sntrup761x25519-sha512 gains its IANA name
3. OpenSSH 10.0 release notes (9 April 2025) — mlkem768x25519-sha256 becomes the default key agreement
4. OpenSSH 10.1 release notes (6 October 2025) — warning on non-post-quantum key agreement, WarnWeakCrypto
5. OpenSSH 8.5 release notes (3 March 2021) — sntrup761x25519-sha512@openssh.com replaces the older NTRU Prime hybrid, disabled by default
6. OpenSSH 10.3 release notes (2 April 2026)
7. OpenSSH 10.4 release notes (6 July 2026) — experimental mldsa44-ed25519 composite post-quantum signature scheme, not enabled by default
8. OpenSSH 10.5 release notes (11 August 2026) — current release at the time of writing
9. OpenSSH — full release notes index
10. ssh_config(5) — KexAlgorithms, WarnWeakCrypto, Match
11. sshd_config(5) — KexAlgorithms, HostKeyAlgorithms, Include
12. IETF draft-ietf-sshm-mlkem-hybrid-kex — hybrid ML-KEM key exchange for SSH
13. IETF draft-ietf-sshm-ntruprime-ssh — sntrup761x25519-sha512 for SSH (successor to the expired draft-josefsson document)
14. IETF draft-miller-sshm-mldsa44-ed25519-composite-sigs — the composite signature scheme OpenSSH 10.4 implements
15. OpenSSL 3.5 series release notes — PQC support and hybrid groups preferred by default (3.5.0, 8 April 2025)
16. OpenSSL documentation — SSL_CTX_set1_groups_list(3), the TLS supported-groups list
17. OpenSSL documentation — SSL_CONF_cmd(3), the Groups command Apache passes through
18. nginx documentation — ssl_ecdh_curve in ngx_http_ssl_module
19. HAProxy configuration manual — ssl-default-bind-curves
20. IETF draft-ietf-tls-ecdhe-mlkem — hybrid ECDHE + ML-KEM groups for TLS 1.3
21. RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3
22. NIST FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)
23. NIST FIPS 204 — Module-Lattice-Based Digital Signature Standard (ML-DSA)
24. NIST FIPS 205 — Stateless Hash-Based Digital Signature Standard (SLH-DSA)
25. NIST IR 8547 (Initial Public Draft, 12 November 2024) — Transition to Post-Quantum Cryptography Standards
26. European Commission / NIS Cooperation Group — Coordinated Implementation Roadmap for the Transition to PQC
27. Cloudflare — State of the post-quantum Internet in 2025
28. Cloudflare Radar — post-quantum encryption adoption (live figures)