💡 مثال كامل يعمل متوفر على GitHub:
sign-word-with-ml-dsa-certificates-dotnet

الطريقة القديمة كانت خطة مشروع

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

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

توقيع ML‑DSA هو قدرة GroupDocs.Signature لـ .NET توقّع مستندات Word بشهادات تستند إلى FIPS 204، معيار التوقيع ما بعد الكم من NIST. وصل في الإصدار 26.9، ومن منظور كود الاستدعاء هو ملف PFX مختلف.

هناك طريقة أفضل

إليك كامل التغيير في الكود:

using var signature = new Signature(sourcePath);

var options = new DigitalSignOptions(pfxPath)
{
    Password = certificatePassword
};

SignResult result = signature.Sign(outputPath, options);

هذا هو نفس الاستدعاء المستخدم لشهادة RSA. الخوارزمية هي خاصية من خصائص الشهادة، لذا لا يوجد خيار يحدّدها، ولا تحتاج إلى طبقة تجريد، ولا يظهر مسار كود ثانٍ لفترة الانتقال. وجه DigitalSignOptions إلى ملف PFX لـ ML‑DSA وستكون النتيجة توقيع ML‑DSA.

قراءة الشهادة مرة أخرى من النتيجة تستحق القيام بها بينما هناك عدة شهادات قيد الاستخدام:

var created = result.Succeeded.OfType<DigitalSignature>().FirstOrDefault();
return created?.Certificate?.Subject ?? "(no certificate returned)";

اختيار مستوى، بأرقام بدلًا من الآراء

يأتي ML‑DSA بثلاث مجموعات من المعاملات، تُطابق فئات الأمان NIST 2، 3 و 5. الأقوى يعني أكبر – كل من المفتاح والتوقيع – والطريقة المنطقية لتحديد ذلك هي توقيع مستندك الخاص ثلاث مرات والنظر إلى النتائج:

var levels = new Dictionary<string, string>
{
    ["ML-DSA-44"] = MlDsa44Pfx,
    ["ML-DSA-65"] = MlDsa65Pfx,
    ["ML-DSA-87"] = MlDsa87Pfx
};

العينة تكتب نسخة موقعة واحدة لكل مستوى وتسجل كل حجم، لذا فإن المقايضة هي قياس وليس جدولًا من مواصفات. لعقد واحد الفرق غير ملحوظ؛ لأرشيف يحتوي على عدة ملايين من المستندات الموقعة يصبح سؤال السعة مهمًا قبل الاعتماد على أعلى مستوى.

ML‑DSA‑65 هو الافتراضي المعقول عندما لا تحدد سياسة مستوىً معينًا. ملفات تعريف مثل CNSA 2.0 تسمي صراحةً ML‑DSA‑87، وML‑DSA‑44 يكون منطقيًا فقط عندما يكون الحجم أهم من الهامش.

التحقق يحتاج فقط الشهادة العامة

قصة التوزيع لا تختلف عن RSA، وهذا هو الخبر السار الثاني:

var options = new DigitalVerifyOptions(certificatePath);
if (password != null)
{
    options.Password = password;
}

VerificationResult result = signature.Verify(options);

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

جنبًا إلى جنب: المتوقع مقابل الفعلي

ما تفترضه خطة الهجرة ما يتطلبه الإصدار 26.9 فعليًا
تغيير الكود طبقة تجريد فوق التوقيع مسار PFX مختلف
سطح الـ API طرق ما بعد الكم جديدة DigitalSignOptions، دون تغيير
اختيار المستوى إعدادات المكتبة الشهادة التي تقوم بتحميلها
التحقق أدوات جديدة للمستلمين ملف .cer العام للمرسِل
عمل المنصة معالجة المفاتيح حسب نظام التشغيل لا شيء – المكتبة تتعامل داخليًا
تغطية الصيغ جميع الصيغ صيغ Word فقط، في الوقت الحالي

الصف الأخير هو ما يحدّ من التخطيط، وهو ما يقودنا إلى الجزء الصادق من هذه المقالة.

ما لا يزال لا يعمل

حدّان، كلاهما من المفيد معرفتهما قبل أن تعد بأي شيء.

تغطية الصيغ تقتصر على Word في الإصدار 26.9 – DOCX، DOC، ODT وبقية عائلة Word. لا يمكن توقيع PDF أو جداول البيانات أو العروض التقديمية باستخدام ML‑DSA. بالنسبة لسلسلة معالجة تركز على PDF، هذا الإصدار مخصص للنمذجة والقياس وليس للهجرة.

دعم المدقق هو الآخر. لا يوجد معرف XML‑DSig قياسي لـ ML‑DSA بعد، لذا قد لا تُظهر Microsoft Word التوقيع كصالح رغم أنه صحيح تشفيريًا ويتحقق بشكل صحيح عبر الـ API. هذه فجوة معيارية وليست عيبًا، وتعني أن التحقق يجب أن يكون في كودك وليس في مراجِع يفتح الملف وينظر إلى الشعار.

هناك أيضًا تفصيل منصة لا يتطلب أي إجراء: .NET لا يستطيع قراءة مفاتيح ML‑DSA في كل مكان، بما في ذلك Linux على .NET 8. حيث لا يستطيع، تقوم GroupDocs.Signature بقراءة الشهادة عبر محرك Word بدلاً من ذلك، لذا فإن نفس البناء يعمل على حاسوب مطور وحاوية Linux دون كود شرطي.

هل يستحق التنفيذ الآن، مع هذه القيود؟

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

ما تثبته العينة فعليًا

أربع طرق تُنفّذ بترتيب، مع رمز خروج مرتبط بالنتيجة. تُوقّع العقد بـ ML‑DSA‑65 وتطبع موضوع الشهادة المستخدمة. تُوقّع نفس العقد على المستويات الثلاثة وتطبع الأحجام الناتجة. تتحقق من الملف الموقع مرتين – مرةً بشهادة المرسِل العامة متوقعة النجاح، ومرةً بشهادة مرسِل آخر متوقعة الفشل. ثم تُدرج التواقيع الرقمية الموجودة في الناتج.

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

مثال واقعي: عقد الثلاثين سنة

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

لأرشيف كهذا، الخطوة العملية اليوم هي مسار مزدوج: الاحتفاظ بـ RSA للصيغ التي لا يغطيها ML‑DSA بعد، بدء توقيع مخرجات Word بـ ML‑DSA‑65 أو 87، وتسجيل الخوارزمية المستخدمة لكل مستند حتى يتمكن تدقيق مستقبلي من تمييزها دون فتح الملفات.

شيء واحد لتصحيحه في العينة قبل نسخها

المستودع يوزّع شهادات ML‑DSA موقّعة ذاتيًا حتى يعمل العرض مباشرةً، وهذا يعني وجود أربعة ملفات PFX وكلمة مرور ثابتة في documents/. بالنسبة لشهادة اختبار مؤقت صالحة فقط داخل هذه العينة، فهذا مقبول.

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

الخلاصة

الأجزاء المكلفة في هجرة ما بعد الكم هي الشهادات، السياسات، والمدققين. الكود، على الأقل لمستندات Word في .NET، هو مجرد PFX مختلف واستدعاء DigitalSignOptions نفسه. استنسخ العينة، وجهها إلى أحد عقودك، ستحصل على ثلاثة ملفات موقعة، نتيجتي تحقق، ومقارنة أحجام خلال دقائق قليلة – وهو أساس أفضل لخطة هجرة من مجرد تقدير.

موارد إضافية