GPG وOpenPGP: شرح التشفير والتوقيع بالمفتاح العام

كل يوم تنزل ملفات وحزماً لم تكتبها أنت، وتنقل ملفات حساسة عبر قنوات لا تملكها: تحديثات النظام تأتي من سيرفر مرآة Mirror لا تعرف من يديره، وملف ISO تنزله من رابط وصلك في رسالة، وتقرير مالي ترسله لزميلك عبر البريد الذي يمر على أكثر من سيرفر قبل أن يصل. وفي كل هذه الحالات هناك سؤالان لا يجيب عنهما HTTPS وحده: هل هذا الملف هو نفسه الذي نشره صاحبه، أم غيره أحد في الطريق أو على السيرفر نفسه؟ وهل يستطيع أحد غير المستلم أن يقرأ ما أرسلته بعد أن يصل إلى سيرفر البريد ويبقى فيه سنوات؟ والأداة التي تجيب عن السؤالين منذ أكثر من ثلاثين سنة، وما زالت تعمل في الخلفية عند كل apt update تقوم به، هي GPG والمعيار الذي تطبقه OpenPGP.

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

• ما هو GPG، وما الفرق بين PGP وOpenPGP وGnuPG.
• المفتاح العام والمفتاح الخاص، والفرق بين التشفير Encryption والتوقيع Signature.
• التشفير الهجين Hybrid Encryption: لماذا لا يشفر GPG رسالتك بالمفتاح العام مباشرة.
• ما يوجد داخل المفتاح: المفتاح الرئيسي Primary Key والمفاتيح الفرعية Subkeys، والبصمة Fingerprint ومعرف المفتاح Key ID.
• كيف تعرف أن المفتاح لصاحبه: شبكة الثقة Web of Trust وسيرفرات المفاتيح Keyservers ودليل المفاتيح على الويب WKD.
• تاريخ الانتهاء Expiry وشهادة الإلغاء Revocation Certificate.
• ما يحميه GPG وما لا يحميه، وأين تقابله اليوم، ومقارنته مع S/MIME وage وSignal.
• انقسام المعيار بين RFC 9580 وLibrePGP، وحدود GPG ونقاط ضعفه.

وكل المخرجات في هذا المقال حقيقية، من تجربة شغلناها في Container من Debian 13.7 فيه GnuPG 2.4.7، بمفاتيح تجريبية لشخصيتين وهميتين هما Alice وBob بعناوين example.test، وتفاصيل التجربة كاملة في المقال العملي.

ما هو GPG، وما علاقته بـ PGP وOpenPGP؟

القصة تبدأ في عام 1991 عندما كتب Phil Zimmermann برنامج PGP، واختصاره Pretty Good Privacy، ليشفر به الناس رسائلهم ويوقعوها دون أن يحتاجوا إلى جهة مركزية، كما يذكر توثيق مكتبة Sequoia. ثم تحولت صيغة رسائله ومفاتيحه إلى معيار مفتوح من IETF اسمه OpenPGP، وكانت نسخته المعتمدة لسنوات طويلة RFC 4880 الصادر في عام 2007، إلى أن حل محله RFC 9580 في يوليو 2024 كما سيأتي.

وأما GnuPG، واختصاراً GPG، فهو التطبيق الحر الأشهر لهذا المعيار، وبحسب إعلانات المشروع فهو تطبيق كامل لمعياري OpenPGP وS/MIME، يعمل من سطر الأوامر، ويستخدمه غيره من البرامج عبر مكتبة GPGME، ويوزع برخصة GNU GPL. فالعلاقة بين الأسماء الثلاثة مثل العلاقة بين HTTP والمتصفح: OpenPGP هو المعيار، وGnuPG أحد البرامج التي تطبقه، ومعه برامج أخرى مثل Sequoia PGP وRNP الذي يعمل داخل Thunderbird.

وعلى مستوى الإصدارات، أعلن المشروع في 30 ديسمبر 2025 أن السلسلة 2.5 صارت الإصدار المستقر، وأن السلسلة 2.4 تنتهي في 30 يونيو 2026 كما في جدول نهاية الدعم، وآخر إصدار عند كتابة المقال هو 2.5.24 بتاريخ 23 سبتمبر 2026. ولاحظ أن التوزيعات لا تلحق بهذا مباشرة، ففي Debian 13 الذي استخدمناه في التجربة ما زال الإصدار المثبت هو 2.4.7:

$ gpg --version | head -3
gpg (GnuPG) 2.4.7
libgcrypt 1.11.0
Copyright (C) 2024 g10 Code GmbH

وهذا لا يغير شيئاً مما في هذا المقال، فكل المفاهيم والأوامر هنا تعمل في السلسلتين.

المفتاح العام والمفتاح الخاص في دقيقة

كل مستخدم في OpenPGP يملك زوجاً من المفاتيح Key Pair: مفتاح خاص Private Key يبقى عنده ولا يغادر جهازه، ومفتاح عام Public Key ينشره لكل من يريد أن يراسله. وأقرب تشبيه له صندوق البريد الحديدي أمام البيت: الفتحة العلوية مفتوحة لأي شخص يمر ويضع رسالة، وهذا هو المفتاح العام، ولكن الباب الذي تخرج منه الرسائل لا يفتح إلا بمفتاح صاحب البيت، وهذا هو المفتاح الخاص. وقد شرحنا الرياضيات التي تجعل هذا ممكناً، وأطوال المفاتيح الآمنة لكل خوارزمية، في قسم التشفير غير المتماثل.

والمهم هنا أن الزوج نفسه يستخدم لوظيفتين مختلفتين تماماً، والفرق بينهما هو أول ما يختلط على من يبدأ مع GPG:

• التشفير Encryption: يستخدم Bob المفتاح العام لAlice ليشفر لها ملفاً، فلا يستطيع فتحه إلا من يملك مفتاحها الخاص، أي Alice وحدها. والهدف هنا السرية Confidentiality.
• التوقيع Signature: تستخدم Alice مفتاحها الخاص لتوقع على ملف، فيستطيع أي شخص يملك مفتاحها العام أن يتحقق أن التوقيع منها وأن الملف لم يتغير بعد توقيعه. والهدف هنا إثبات المصدر Authenticity وسلامة المحتوى Integrity، والملف نفسه يبقى مقروءاً للجميع.

الصورة التالية تبين الوظيفتين جنباً إلى جنب، ولاحظ أن اتجاه المفاتيح فيهما معكوس:

وقد يتساءل البعض: إذا كان التوقيع لا يخفي شيئاً فما فائدته؟ والإجابة أن أغلب استخدام OpenPGP اليوم هو التوقيع وليس التشفير، فكل حزمة تثبتها من مستودع Debian أو Ubuntu، وكل ملف ISO رسمي، وكثير من إصدارات البرامج مفتوحة المصدر، كلها ملفات عامة يقرؤها الجميع، والسؤال الوحيد فيها هو: هل هي من أصحابها فعلاً؟ وقد فصلنا الفرق بين الوظيفتين في قسم التوقيع ليس تشفيراً، وفيما يلي ما يحدث عندما يتغير حرف واحد في ملف موقع، وهو من تجربتنا حيث غير Bob رقم الإصدار في ملف وقعته Alice:

$ gpg --verify release-notes.txt.asc release-notes.txt
gpg: Signature made Fri Oct  9 13:11:53 2026 UTC
gpg:                using EDDSA key F8E558CDCE839C89D465E692C285B11B1C262E80
gpg: Good signature from "Alice Example <[email protected]>" [full]

$ sed -i "s/v1.4.0/v1.4.1/" release-notes.txt
$ gpg --verify release-notes.txt.asc release-notes.txt
gpg: Signature made Fri Oct  9 13:11:53 2026 UTC
gpg:                using EDDSA key F8E558CDCE839C89D465E692C285B11B1C262E80
gpg: BAD signature from "Alice Example <[email protected]>" [full]

ولاحظ أن GPG لا يقول أين تغير الملف، وإنما يقول إن التوقيع لم يعد يطابقه، وهذا كاف تماماً، فالملف الذي فشل توقيعه لا تستخدمه.

لماذا لا يشفر GPG الرسالة بالمفتاح العام مباشرة؟

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

لذلك يستخدم OpenPGP ما يسمى التشفير الهجين Hybrid Encryption، والفكرة كما تبين الصورة التالية: يولد GPG مفتاحاً عشوائياً جديداً لهذه الرسالة وحدها اسمه مفتاح الجلسة Session Key، ويشفر به الرسالة كلها مرة واحدة بالتشفير المتماثل السريع، ثم يشفر مفتاح الجلسة فقط، وهو بضعة بايتات، بالمفتاح العام لكل مستلم، ويضع كل ذلك في ملف واحد.

ونستطيع أن نرى هذا البناء بأعيننا، فالأمر gpg --list-packets يعرض الحزم Packets التي يتكون منها الملف المشفر. وفي تجربتنا شفر Bob ملفاً لAlice ولنفسه معاً، والمخرج سوف يكون كما يلي (اختصرنا كل حزمة إلى سطرها الأول):

$ gpg --encrypt --recipient [email protected] --recipient [email protected] --output both.gpg report.txt
$ gpg --list-packets both.gpg
:pubkey enc packet: version 3, algo 18, keyid 7220124A948A4F79
:pubkey enc packet: version 3, algo 18, keyid 380BCF94EF97A3CC
:encrypted data packet:
:compressed packet: algo=2
:literal data packet:

في المخرج أعلاه لاحظ التالي:

• هناك حزمتان من نوع pubkey enc packet، واحدة لكل مستلم، وفي كل منها نسخة من مفتاح الجلسة مشفرة بمفتاح ذلك المستلم، ومعرف مفتاحه ظاهر فيها.
• هناك حزمة بيانات مشفرة واحدة فقط، فيها الملف مضغوطاً ثم مشفراً، ولو أضفنا عشرة مستلمين لزادت الحزم الصغيرة فقط ولم يتكرر الملف.
• القيمة algo 18 هي ECDH، أي أن مفتاح التشفير هنا من نوع Curve25519، وهو الافتراضي في الإصدارات الحديثة.

وإذا أردت أن ترى مفتاح الجلسة نفسه فالأمر --show-session-key يطبعه عند فك التشفير، والرقم 9 في أوله يعني أن الخوارزمية AES-256:

$ gpg --show-session-key --decrypt report.txt.asc >/dev/null
gpg: encrypted with cv25519 key, ID 7220124A948A4F79, created 2026-10-09
      "Alice Example <[email protected]>"
gpg: session key: '9:2F29D5C53F9A3F1293B9A84BAF7DB04131CFAC61FC05B724AD5C5DB32CF5C00C'

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

ماذا يوجد داخل المفتاح؟ المفتاح الرئيسي والمفاتيح الفرعية

عندما تسمع «مفتاح GPG» فأنت في الحقيقة تتحدث عن حزمة من عدة أجزاء مرتبطة ببعضها بتوقيعات، والأفضل أن نبدأ بمفتاح حقيقي. فيما يلي مفتاح Alice من التجربة بعد إنشائه، والمخرج سوف يكون كما يلي:

$ gpg --list-secret-keys --keyid-format long --with-subkey-fingerprints
/lab/alice/pubring.kbx
----------------------
sec   ed25519/C285B11B1C262E80 2026-10-09 [SC] [expires: 2028-10-08]
      F8E558CDCE839C89D465E692C285B11B1C262E80
uid                 [ultimate] Alice Example <[email protected]>
ssb   cv25519/7220124A948A4F79 2026-10-09 [E] [expires: 2028-10-08]
      099269D99FFC137AB5C7B9077220124A948A4F79

في المخرج أعلاه لاحظ التالي:

• المفتاح الرئيسي Primary Key في السطر sec، من نوع ed25519، وصلاحياته [SC]: التوقيع Sign وشهادة المفاتيح Certify، أي أنه هو الذي يوقع على بقية أجزاء المفتاح ليثبت أنها له، وعلى مفاتيح الآخرين إذا تحقق منها. وهذا هو هوية Alice الحقيقية، وأي شيء يرتبط به يرتبط بها.
• هوية المستخدم User ID في السطر uid: الاسم والبريد، مربوطة بالمفتاح الرئيسي بتوقيع ذاتي Self-signature. ويمكن أن يكون للمفتاح أكثر من هوية، مثل بريد العمل والبريد الشخصي.
• المفتاح الفرعي Subkey في السطر ssb، من نوع cv25519 وصلاحيته [E] للتشفير فقط. وعندما يشفر لك أحد رسالة فهو يستخدم هذا المفتاح الفرعي وليس الرئيسي، ولهذا ظهر معرفه 7220124A948A4F79 في حزم الرسالة المشفرة في القسم السابق.
• لكل جزء تاريخ إنشاء وتاريخ انتهاء خاص به، وسوف نعود إليه.

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

ولاحظ في الصورة أن «المفتاح العام» الذي ترسله للناس ليس مفتاحاً واحداً، وإنما الأجزاء العامة كلها مع التوقيعات التي تربطها، ولذلك يسميه المعيار والبرامج الحديثة شهادة Certificate، وهي شهادة بلا جهة إصدار مركزية، بخلاف شهادات TLS التي شرحناها في مقال الشهادات الرقمية.

البصمة Fingerprint ومعرف المفتاح Key ID

كل مفتاح له اسم رقمي فريد هو البصمة Fingerprint، وهي في مفاتيح الإصدار الرابع v4 المنتشرة اليوم هاش SHA-1 من 160 بت لبيانات المفتاح العام، وتكتب في 40 خانة ست عشرية مثل F8E5 58CD CE83 9C89 D465 E692 C285 B11B 1C26 2E80. ومعرف المفتاح Key ID هو آخر 64 بت من البصمة، أي آخر 16 خانة C285B11B1C262E80، كما يعرفه القسم 5.5.4.2 من RFC 9580، وفي مفاتيح الإصدار السادس v6 الجديدة صارت البصمة SHA-256 من 256 بت ويؤخذ المعرف من أولها.

وهناك أيضاً المعرف القصير Short Key ID من 8 خانات فقط 1C262E80، وكان شائعاً في الأدلة القديمة وبطاقات العمل، ولا تعتمد عليه أبداً، والسبب أن 32 بت مساحة صغيرة يمكن البحث فيها بالقوة، وقد أثبت مشروع Evil 32 ذلك عملياً، فولد مفاتيح مزيفة تطابق المعرف القصير لكل المفاتيح في شبكة الثقة، وذكر أن توليد مفتاح بمعرف قصير مطابق يستغرق 4 ثوان على بطاقة GPU. فمن يعطيك معرفاً قصيراً ويقول «حمل مفتاحي من سيرفر المفاتيح بهذا المعرف» قد يحصل منه على مفتاح شخص آخر تماماً بالمعرف نفسه.

وقد يتساءل البعض: وماذا عن البصمة الكاملة، أليست SHA-1 مكسورة؟ والإجابة أن الهجمات المعروفة على SHA-1 هي هجمات تصادم Collision يصنع فيها المهاجم ملفين جديدين لهما الهاش نفسه، وليست هجمات تمكنه من صنع مفتاح يطابق بصمة مفتاح موجود لا يتحكم فيه، وهذا ما يحتاجه لينتحل شخصيتك، ولكنه أحد أسباب انتقال RFC 9580 إلى SHA-256 في مفاتيح v6. والقاعدة العملية بسيطة: قارن البصمة الكاملة دائماً، ولا تكتف بالمعرف، ولا بالاسم والبريد، لأن أي أحد يستطيع أن ينشئ مفتاحاً بأي اسم وأي بريد. فنحن في التجربة أنشأنا مفتاحاً باسم Alice وبريد [email protected] دون أن يسألنا GPG أي سؤال عن ملكية هذا البريد.

من أين تعرف أن المفتاح لصاحبه؟

هذه هي المشكلة الحقيقية في OpenPGP، وكل ما سبق سهل مقارنة بها. لنفرض أن Bob يريد أن يرسل لAlice ملفاً سرياً، فالحل البسيط أن يبحث عن «Alice» في أي مكان ويأخذ أول مفتاح يجده، وهذه أسوأ الطرق على الإطلاق، لأن المهاجم يستطيع أن ينشر مفتاحاً باسمها وبريدها، فيشفر Bob الملف لمفتاح المهاجم وهو يظن أنه يشفره لAlice، والتشفير هنا قوي جداً ولكن للشخص الخطأ، وهذا هو هجوم الوسيط Man-in-the-Middle بشكله الأوضح.

ولهذا لا يقبل GPG أن يشفر في الوضع الآلي لمفتاح لم يتحقق منه أحد. ففي تجربتنا استورد Bob مفتاح Alice ثم حاول أن يشفر لها مباشرة، والمخرج سوف يكون كما يلي:

$ gpg --batch --armor --encrypt --recipient [email protected] report.txt
gpg: 7220124A948A4F79: There is no assurance this key belongs to the named user
gpg: report.txt: encryption failed: Unusable public key

وبعد أن قارن Bob البصمة مع Alice عبر قناة أخرى ووقع على مفتاحها توقيعاً محلياً، تغيرت صلاحية المفتاح Validity من unknown إلى full ونجح التشفير. وأما الشخص الثالث في التجربة، Carol، فقد استوردت مفتاح Alice دون أي تحقق، فحصلت على هذا التحذير عند فحص توقيعها:

$ gpg --verify release-notes.txt.asc release-notes.txt
gpg: Signature made Fri Oct  9 13:11:53 2026 UTC
gpg:                using EDDSA key F8E558CDCE839C89D465E692C285B11B1C262E80
gpg: Good signature from "Alice Example <[email protected]>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: F8E5 58CD CE83 9C89 D465  E692 C285 B11B 1C26 2E80

ولاحظ أن التوقيع نفسه سليم Good signature، أي أن الملف موقع بهذا المفتاح ولم يتغير، ولكن GPG يقول بوضوح إنه لا يعرف إن كان هذا المفتاح لAlice فعلاً، ويطبع البصمة الكاملة لتقارنها أنت. وهذا التحذير هو أكثر ما يتجاهله الناس، وهو بالضبط الجزء المهم.

وهناك ثلاث طرق شائعة للحصول على المفتاح العام، والصورة التالية تبينها:

1. شبكة الثقة Web of Trust: فكرة PGP الأصلية، فبدلاً من جهة مركزية تصدر الشهادات، يوقع الناس على مفاتيح بعضهم بعد أن يتحققوا منها شخصياً، فإذا وقعت Carol التي تثق بها على مفتاح Alice، اعتبر GPG مفتاح Alice موثوقاً عندك. وقد كانت حفلات توقيع المفاتيح Key Signing Parties تقام في المؤتمرات لهذا الغرض. ولكن هذه الطريقة لم تنتشر خارج دوائر المطورين، لأنها تحتاج من كل مستخدم أن يفهم الفرق بين صلاحية المفتاح Validity والثقة بصاحبه في التحقق من غيره Owner Trust، وهذا أكثر مما يحتمله أغلب الناس.
2. دليل المفاتيح على الويب Web Key Directory واختصاراً WKD: يضع مالك النطاق مفتاح كل عنوان بريد على سيرفر الويب الخاص بالنطاق في مسار ثابت تحت /.well-known/openpgpkey/، فيجد البرنامج مفتاح [email protected] من العنوان وحده عبر HTTPS، والثقة هنا مبنية على أن من يتحكم في موقع النطاق هو نفسه من يتحكم في بريده. وهي مسودة draft-koch-openpgp-webkey-service وآخر نسخة منها رقم 22 بتاريخ يوليو 2026، وهي ليست معياراً معتمداً من IETF، ولكن GnuPG يستخدمها تلقائياً، حتى إنه في تجربتنا حاول من نفسه أن يبحث عن المفتاح عبر WKD عندما لم يجد مفتاحاً صالحاً للمستلم.

سيرفرات المفاتيح Keyservers: سيرفرات عامة ترفع إليها مفتاحك ويبحث فيها الناس بالبريد أو البصمة. وكانت شبكة SKS القديمة تقبل أي شيء من أي أحد ولا تحذف شيئاً أبداً، وهذا ما استغله المهاجمون في عام 2019 بإغراق بعض المفاتيح بتوقيعات مزيفة كثيرة حتى تعطل استيرادها، فأصدر مشروع GnuPG الإصدار 2.2.17 الذي يتجاهل كل توقيعات المفاتيح القادمة من سيرفرات المفاتيح لتخفيف هذا الهجوم. والبديل الحديث keys.openpgp.org، الذي لا ينشر الاسم والبريد إلا بعد أن يؤكد صاحب البريد ملكيته من رابط يصله، وهو السيرفر الافتراضي في نسخة GnuPG التي ثبتناها من Debian 13. وقد رأينا أثر ذلك في التجربة عندما طلبنا مفتاح Debian لتوقيع ملفات ISO من هذا السيرفر، فلم يرجع إلا المفتاح دون هوية، فرفض GPG استيراده:

$ gpg --keyserver hkps://keys.openpgp.org --recv-keys DF9B9C49EAA9298432589D76DA87E80D6294BE9B
gpg: key DA87E80D6294BE9B: new key but contains no user ID - skipped
gpg: Total number processed: 1
gpg:           w/o user IDs: 1

وهذه مشكلة معروفة يذكرها دليل السيرفر نفسه، فإذا لم يؤكد صاحب المفتاح بريده فلن تحصل منه على مفتاح قابل للاستخدام في GnuPG.

وفي الطرق الثلاث القاعدة واحدة: المصدر يجيب عن سؤال «أين المفتاح؟»، والبصمة المطابقة تجيب عن سؤال «هل هو مفتاحه فعلاً؟»، والمقارنة يجب أن تكون عبر قناة مختلفة عن القناة التي وصلك منها المفتاح، مثل مكالمة صوتية مع الشخص، أو لقاء، أو صفحة رسمية تعرفها مثل صفحة التحقق من ملفات Debian التي تكتب بصمات مفاتيحها كاملة.

تاريخ الانتهاء وشهادة الإلغاء

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

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

شهادة الإلغاء Revocation Certificate: ملف صغير موقع بمفتاحك الرئيسي يقول «هذا المفتاح لم يعد صالحاً»، وعندما تنشره يرى كل من يحدث نسخته من مفتاحك أنه ملغى. والفكرة المهمة أنك تصنعها مسبقاً، لأنك إذا فقدت المفتاح الخاص فلن تستطيع أن توقع شهادة إلغاء بعد ذلك. ولذلك ينشئ GnuPG شهادة إلغاء تلقائياً مع كل مفتاح جديد، كما ظهر في تجربتنا:

gpg: revocation certificate stored as '/lab/alice/openpgp-revocs.d/F8E558CDCE839C89D465E692C285B11B1C262E80.rev'

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

وعندما استوردت Carol في تجربتنا شهادة الإلغاء التي أعدتها Alice، صار المفتاح ملغى عندها، وظهر السبب والتعليق الذي كتبته Alice مع أي توقيع قديم لها:

$ gpg --verify release-notes.txt.asc release-notes.txt
gpg: Signature made Fri Oct  9 13:11:53 2026 UTC
gpg:                using EDDSA key F8E558CDCE839C89D465E692C285B11B1C262E80
gpg: Good signature from "Alice Example <[email protected]>" [unknown]
gpg: WARNING: This key has been revoked by its owner!
gpg:          This could mean that the signature is forged.
gpg: reason for revocation: Key has been compromised
gpg: revocation comment: Key stored on the old laptop

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

ما الذي يحميه GPG وما الذي لا يحميه؟

GPG يحمي المحتوى: نص الرسالة والمرفقات واسم الملف الأصلي، فهذه كلها داخل حزمة البيانات المشفرة. ولكنه لا يحمي البيانات الوصفية Metadata، والصورة التالية تبين الفرق في رسالة بريد:

• ترويسات البريد Headers: المرسل والمستلم والتاريخ وسيرفرات البريد التي مرت بها الرسالة وعناوينها تبقى ظاهرة لكل سيرفر في الطريق، لأن البريد لا يصل دونها. وقد شرحنا طريق الرسالة بين السيرفرات في مقال كيف يعمل البريد الإلكتروني.
• العنوان Subject: في الطريقة التقليدية يبقى العنوان ظاهراً، ولذلك تضيف البرامج الحديثة ميزة تشفير العنوان بوضع العنوان الحقيقي داخل الجزء المشفر واستبداله في الخارج بنص عام، وبحسب صفحة حالة OpenPGP في Thunderbird فهذه الميزة مفعلة افتراضياً فيه. فلا تفترض أن برنامج الطرف الآخر يفعل الشيء نفسه.
• الحجم والتوقيت: حجم الملف المشفر قريب من حجم الأصل بعد الضغط، ووقت الإرسال معروف.
• السرية الأمامية Forward Secrecy: لا توجد في OpenPGP، فإذا سرق مفتاحك الخاص بعد سنوات، وكان المهاجم قد احتفظ بنسخ من رسائلك المشفرة القديمة، فسوف يفكها كلها، لأن مفتاح الجلسة لكل رسالة مشفر بالمفتاح نفسه. وهذا بخلاف بروتوكولات المحادثة الحديثة مثل Signal التي تصمم مفاتيحها لتوفر السرية الأمامية.

معرف مفتاح المستلم: رأيناه في القسم السابق داخل الملف المشفر، وأي شخص يملك الملف يستطيع قراءته دون أن يفك شيئاً، ففي تجربتنا فحص Bob ملفاً مشفراً لAlice فقط، وهو لا يملك مفتاحها، فعرف مع ذلك لمن هو:

$ gpg --list-packets report.txt.asc
gpg: encrypted with cv25519 key, ID 7220124A948A4F79, created 2026-10-09
      "Alice Example <[email protected]>"
gpg: public key decryption failed: No secret key
gpg: decryption failed: No secret key
# off=0 ctb=84 tag=1 hlen=2 plen=94
:pubkey enc packet: version 3, algo 18, keyid 7220124A948A4F79

والخيار --throw-keyids يخفي هذا المعرف ويضع مكانه أصفاراً، فيضطر المستلم أن يجرب كل مفاتيحه الخاصة على الرسالة، وهذا مناسب لحالات خاصة فقط.

ونقطة أخيرة مهمة في التوقيع: التوقيع يثبت من نشر الملف، ولا يثبت أن محتواه آمن. ففي حادثة xz في عام 2024 كان الإصداران اللذان يحملان الباب الخلفي موقعين توقيعاً صحيحاً من مفتاح المشرف الذي أضافه، كما تذكر صفحة المشروع، وقد شرحنا القصة في مقال كيف اكتشف Andres Freund الباب الخلفي في xz.

أين يستخدم OpenPGP اليوم؟

قد تظن أن GPG أداة قديمة لا يستخدمها إلا بعض المهتمين بالخصوصية لتشفير البريد، ولكن الحقيقة أنك تعتمد عليه كل يوم، والصورة التالية تجمع أشهر الاستخدامات:

• ملفات الإصدار Release Files: المشاريع تنشر بجانب ملفاتها قائمة الهاش وتوقيعها، مثل SHA256SUMS وSHA256SUMS.sign في Debian، وقد تحققنا منها خطوة بخطوة في المقال العملي.
• توقيع Git Commits والوسوم Tags: اسم الكاتب وبريده في ال Commit مجرد نص يكتبه أي أحد، كما شرحنا في مقال Git للمبتدئين، والتوقيع هو ما يثبت أن الكاتب هو من يدعي، ولذلك تعرض المنصات مثل GitHub علامة «Verified» على ال Commits الموقعة بمفاتيح GPG أو SSH أو S/MIME.
• البريد الإلكتروني: منذ الإصدار 78 في عام 2020 صار دعم OpenPGP مدمجاً في Thunderbird دون الحاجة لتثبيت GnuPG، عبر مكتبة RNP.
• مدير كلمات المرور pass: pass يحفظ كل كلمة مرور في ملف مشفر بـ GPG، ويمكن أن تشترك فيه مجموعة بتشفير الملفات لمفاتيح الجميع، وهو تطبيق مباشر لفكرة التشفير لأكثر من مستلم.
• الأسرار في مستودعات Git: SOPS يشفر قيم ملفات YAML وJSON وENV قبل أن تدخل المستودع، ويدعم مفاتيح PGP بجانب age وخدمات KMS السحابية.

مستودعات الحزم Package Repositories: في Debian وUbuntu يوقع المستودع ملف الفهرس InRelease، وهو ملف موقع بالطريقة المقروءة Clearsign، وفيه هاش ملفات الفهارس مثل main/binary-amd64/Packages، وهذه الفهارس فيها بدورها هاش كل حزمة، ويحدد ملف المصادر المفتاح المسموح له بالتوقيع في السطر Signed-By. وهذا ما وجدناه في Container التجربة:

$ grep Signed-By /etc/apt/sources.list.d/debian.sources
Signed-By: /usr/share/keyrings/debian-archive-keyring.pgp
Signed-By: /usr/share/keyrings/debian-archive-keyring.pgp

$ head -4 /var/lib/apt/lists/deb.debian.org_debian_dists_trixie_InRelease
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Origin: Debian

ولاحظ أن apt في Debian 13 لم يعد يستخدم GnuPG للتحقق، فالحزمة apt بالإصدار 3.0.3 تعتمد على sqv، وهو برنامج التحقق من التوقيعات من مشروع Sequoia، وهذا من مخرج التجربة نفسها:

$ apt-cache show apt | grep -m1 "^Depends"
Depends: base-passwd (>= 3.6.1) | adduser, sqv (>= 1.3.0), libapt-pkg7.0 (>= 3.0.3), debian-archive-keyring, libc6 (>= 2.38), libgcc-s1 (>= 3.0), libseccomp2 (>= 2.4.2), libssl3t64 (>= 3.0.0), libstdc++6 (>= 13.1), libsystemd0

والمعيار واحد، فالتوقيعات نفسها تتحقق منها أي أداة تطبق OpenPGP.

OpenPGP أم S/MIME أم age أم Signal؟

OpenPGP ليس الأداة الوحيدة للتشفير والتوقيع، ولكل بديل مكانه، وفيما يلي مقارنة مختصرة:

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

RFC 9580 وLibrePGP: لماذا انقسم المعيار؟

في يوليو 2024 صدر RFC 9580 بديلاً عن RFC 4880، وجاء بتحديث كبير: مفاتيح بإصدار سادس v6 وبصمات SHA-256، وتشفير موثق AEAD إلزامي التطبيق بوضع OCB، وتوصية باستخدام Argon2 لحماية المفتاح الخاص بكلمة المرور، وجعل Ed25519 وX25519 من الخوارزميات التي يجب أن يطبقها كل برنامج، واعتبار مفاتيح RSA قديمة لا ينبغي توليدها بحسب القسم 9.1 منه.

ولكن مشروع GnuPG لم يقبل هذا الإصدار، وبحسب موقع LibrePGP فقد كان هناك توافق في فريق العمل في عام 2021 على صيغة للإصدار الخامس v5 بدأت البرامج تطبقها، ثم بدأت مجموعة صغيرة في الفريق مراجعة كبيرة غيرت هذا الاتجاه، ولذلك نشر g10 Code، الشركة التي تطور GnuPG، مع Ribose، الشركة التي تطور RNP، مواصفة منفصلة اسمها LibrePGP تكمل من ذلك التوافق، وآخر نسخها draft-koch-librepgp-06 بتاريخ سبتمبر 2026، وهي مسودة فردية وليست معياراً معتمداً من IETF. وفي الجهة الأخرى تطبق مكتبة sequoia-openpgp معيار RFC 9580، ومنها برنامج sqv الذي يتحقق به apt في Debian 13، فقد ظهر في تجربتنا أنه مبني على الإصدار 2.0.0 منها:

$ sqv --version
sqv 1.3.0 (sequoia-openpgp 2.0.0, using Nettle 3.10 (Cv448: true, OCB: true))

وماذا يعني هذا لك عملياً؟ المفاتيح والرسائل من الإصدار الرابع v4، ومنها مفاتيح ed25519 وcv25519 التي ينشئها GnuPG افتراضياً اليوم، يفهمها الطرفان. والمشكلة تظهر فقط عندما يستخدم أحد الطرفين صيغة لا يدعمها الآخر، مثل مفتاح v6 من برنامج يطبق RFC 9580 يحاول أن يستخدمه شخص على GnuPG. لذلك إذا كنت تحتاج أن يعمل مفتاحك مع الجميع، كما في توقيع Git أو مراسلة أشخاص لا تعرف برامجهم، فابق على مفاتيح v4 الحديثة حتى يتضح اتجاه الصناعة، وانتبه عند اختيار أي ميزة جديدة في أي من الطرفين.

حدود GPG ونقاط ضعفه

من الإنصاف أن نقول إن OpenPGP، رغم قوة الخوارزميات التي يستخدمها، له نقاط ضعف حقيقية يعرفها كل من استخدمه، وهي في الغالب في الاستخدام وليس في التشفير نفسه:

• سهولة الاستخدام Usability: المستخدم مسؤول عن كل شيء: إنشاء المفتاح وحمايته ونسخه احتياطياً، وتمديد تاريخه، والتحقق من مفاتيح الآخرين ومقارنة البصمات، وفهم الفرق بين الصلاحية والثقة. وأغلب الأخطاء التي رأيناها في الواقع ليست كسراً للتشفير، وإنما مفتاح لم يتحقق منه أحد، أو رسالة رد أرسلت دون تشفير بالخطأ.
• الإلغاء لا يصل وحده: إذا ألغيت مفتاحك فلن يعرف ذلك إلا من يحدث نسخته منه، ومن لا يفعل سيستمر في التشفير لمفتاح ملغى.
• لا توجد سرية أمامية Forward Secrecy، ولا حماية للبيانات الوصفية، كما شرحنا في القسم السابق.
• البريد بيئة خطرة: برامج البريد تعرض HTML وتحمل محتوى خارجياً، وتجمع الأجزاء المشفرة مع غير المشفرة في رسالة واحدة، وهذا ما استغلته ثغرة EFAIL.

ومع ذلك تبقى هذه الحدود في البريد والمحادثات أساساً، أما في التحقق من الحزم والإصدارات وتوقيع الكود فلا يوجد بديل منتشر بالقدر نفسه حتى الآن، وهذا ما يجعل فهم GPG ضرورياً لكل من يدير سيرفرات أو يكتب كوداً.

أخطاء شائعة

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

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

• OpenPGP معيار مفتوح بدأ من PGP في عام 1991، وGnuPG هو تطبيقه الحر الأشهر، والإصدار المستقر منه اليوم السلسلة 2.5، بينما تشحن التوزيعات المستقرة مثل Debian 13 الإصدار 2.4.7.
• المفتاح العام للمستلم يشفر، ومفتاحه الخاص يفك، والمفتاح الخاص للمرسل يوقع، ومفتاحه العام يتحقق، والتوقيع يثبت المصدر ولا يخفي شيئاً.
• GPG يشفر الرسالة بمفتاح جلسة عشوائي مرة واحدة، ويشفر مفتاح الجلسة وحده لكل مستلم، وهذا هو التشفير الهجين.
• المفتاح حزمة: مفتاح رئيسي يوقع على هويات ومفاتيح فرعية، والبصمة الكاملة هي الاسم الوحيد الذي تعتمد عليه، والمعرف القصير يمكن تزويره في ثوان.
• المشكلة الحقيقية هي معرفة أن المفتاح لصاحبه، وشبكة الثقة وسيرفرات المفاتيح وWKD تجيب عن «أين المفتاح؟»، ومقارنة البصمة عبر قناة ثانية تجيب عن «هل هو مفتاحه؟».
• اجعل لمفتاحك تاريخ انتهاء، واحفظ شهادة الإلغاء بعيداً عنه، فالأول يوقفه وحده والثانية توقفه فوراً.
• GPG يحمي المحتوى ولا يحمي البيانات الوصفية، ولا سرية أمامية فيه، وأقوى استخدام له اليوم هو التحقق من توقيعات الحزم والإصدارات والكود.
• المعيار منقسم بين RFC 9580 الذي تطبقه Sequoia وLibrePGP الذي يطبقه GnuPG وRNP، ومفاتيح v4 الحديثة تعمل مع الطرفين.

وفي المقال العملي استخدام GPG عملياً ننفذ كل ما سبق بالأوامر: إنشاء المفتاح وتبادله والتحقق من بصمته، والتشفير والتوقيع، وتوقيع Git Commits، والتحقق من ملف منزل، ونقل المفاتيح ونسخها احتياطياً، وأشهر الأخطاء وحلولها. وفي مرحلة Git من خارطة الطريق مقال قادم بإذن الله عن توقيع ال Commits بمفاتيح SSH وGPG ومقارنة الطريقتين.

دليلاستخدام GPG عملياً: من إنشاء المفتاح إلى توقيع Gitكيف تنشئ مفتاح GPG وتتحقق من بصمة غيرك، ثم تشفر ملفاتك وتوقعها وتوقع بها Git Commits.دليلالتشفير للمطورين: ماذا تستخدم ولماذا لا تخترع خوارزميتكأي هاش تستخدم لكلمات المرور، ومتى تحتاج التشفير المتماثل أو غير المتماثل، وأين تحفظ المفاتيح بأمان في تطبيقك.دليلالشهادات الرقمية TLS للمبتدئين وصيغ ملفاتهاكيف يعرف المتصفح أنه يتحدث مع الموقع الحقيقي، وماذا يوجد داخل الشهادة، ولماذا تأتي ملفاتها بأكثر من صيغة.دليلأمن سلسلة التوريد البرمجية Software Supply Chain للمبتدئينكل ما بين كود غيرك وسيرفرك قد يحمل كود المهاجم، وهنا تعرف التهديدات الحقيقية بحوادث موثقة والدفاع المناسب لكل حلقة.

سجل التحديثات

• أكتوبر 2026: كتابة المقال، مع مخرجات حقيقية من تجربة على Debian 13.7 وGnuPG 2.4.7 بمفاتيح تجريبية، ومراجعة حالة GnuPG 2.5 وRFC 9580 وLibrePGP من مصادرها.