💡 مثال کامل کارآمد در گیت‌هاب موجود است:
sign-word-with-ml-dsa-certificates-dotnet
راه قدیمی یک برنامه پروژه بود
از اینکه چه چیزهایی برای تبدیل امضای اسناد به پس‑کوانتوم لازم است بپرسید و یک نقشه راه دریافت می‌کنید: ارزیابی الگوریتم‌ها، انتخاب یک کتابخانه، نوشتن لایهٔ انتزاعی بر روی کد امضا، برنامه‌ریزی دورهٔ دو‑امضایی، تخصیص بودجه یک سه‌ماهه.
بخش عمدهٔ این موارد برای نیمهٔ سازمانی همچنان صادق است - تهیه گواهی، سیاست‌ها، پشتیبانی اعتبارسنج. نیمهٔ کد نسبت به نقشه راه کوچکتر بود و دانستن این موضوع پیش از تخصیص بودجهٔ یک سه‌ماهه مهم است.
امضای ML-DSA یک قابلیت GroupDocs.Signature برای .NET است که اسناد Word را با گواهی‌های مبتنی بر FIPS 204، استاندارد امضای پس‑کوانتوم NIST، امضا می‌کند. این قابلیت در نسخه ۲۶.۹ اضافه شد و از دید کد فراخوانی‌کننده یک فایل 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 ۲، ۳ و ۵ نگاشت می‌شوند. قوی‌تر بودن به معنای بزرگتر بودن است — هم کلید و هم امضا — و روش معقول برای تصمیم‌گیری این است که سند خود را سه بار امضا کنید و بررسی کنید:
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 امضاکننده نیاز دارد و چیز دیگری لازم نیست. نتیجه تنها زمانی معتبر است که امضا با محتوا مطابقت داشته باشد و گواهی با شماره سریال و اثر انگشت هم‌خوانی داشته باشد، بنابراین سندی که توسط طرف دیگری امضا شده است، بررسی را رد می‌کند — که نمونه با اجرای دو بار تأیید، یک بار با گواهی صحیح و یک بار با گواهی شخص دیگری، این موضوع را ثابت می‌کند.
در کنار هم: مورد انتظار در مقابل واقعی
| آنچه یک برنامه مهاجرت فرض می‌کند | آنچه نسخه ۲۶.۹ واقعاً نیاز دارد | |
|---|---|---|
| تغییر کد | لایهٔ انتزاعی بر روی امضا | مسیر PFX متفاوت |
| سطح API | روش‌های جدید پس‑کوانتوم | DigitalSignOptions، بدون تغییر |
| انتخاب سطح | پیکربندی کتابخانه | کدام گواهی را بارگذاری می‌کنید |
| تأیید | ابزار جدید برای گیرندگان | فایل .cer عمومی امضاکننده |
| کارهای پلتفرم | مدیریت کلید بر حسب سیستم‌عامل | هیچ‌کدام — کتابخانه به‌صورت داخلی به‌پشت‌صحنه می‌رود |
| پوشش فرمت‌ها | تمام فرمت‌ها | فقط فرمت‌های Word، فعلاً |
سطر آخر همان موردی است که برنامه‌ریزی را محدود می‌کند و به بخش صادقانهٔ این مقاله می‌رسد.
آنچه هنوز کار نمی‌کند
دو محدودیت وجود دارد که هر دو پیش از هر وعده‌ای باید بدانید.
پوشش فرمت‌ها در نسخه ۲۶.۹ فقط Word است — DOCX، DOC، ODT و سایر فرمت‌های خانواده Word. PDF، صفحات گسترده و ارائه‌ها نمی‌توانند با ML‑DSA امضا شوند. برای خط لوله‌ای که ابتدا PDF را استفاده می‌کند، این نسخه برای نمونه‌سازی و اندازه‌گیری است نه برای مهاجرت.
پشتیبانی اعتبارسنج مورد دیگر است. هنوز شناسهٔ استاندارد XML‑DSig برای ML‑DSA وجود ندارد، بنابراین ممکن است Microsoft Word امضا را به‌عنوان معتبر گزارش ندهد حتی اگر از نظر رمزنگاری صحیح باشد و از طریق API به‌درستی تأیید شود. این یک خلأ استانداردی است نه نقص، و به این معنی است که تأیید باید در کد شما انجام شود نه در مرورگری که فایل را باز می‌کند و به بنر نگاه می‌کند.
همچنین جزئیات پلتفرمی وجود دارد که نیازی به اقدام ندارد: .NET نمی‌تواند کلیدهای ML‑DSA را در همه جا بخواند، از جمله در لینوکس با .NET 8. در جاهایی که نمی‌تواند، GroupDocs.Signature گواهی را از طریق موتور Word می‌خواند، بنابراین همان ساختار می‌تواند بر روی لپ‌تاپ توسعه‌دهنده و یک کانتینر لینوکس بدون کد شرطی اجرا شود.
آیا با توجه به این محدودیت‌ها، اکنون انجامش ارزش دارد؟
بله، به دو دلیل که ربطی به کد ندارند. تهیه گواهی زمان‌بر است — مرجع‌های عمومی هنوز در حال انتشار گواهی‌های ML‑DSA هستند — بنابراین کارهای سمت سازمانی از شروع زودهنگام سود می‌برند. و سؤال «آیا می‌توانیم امروز یک امضای پس‑کوانتوم تولید کنیم؟» سوالی است که تیم‌های انطباق به‌تدریج می‌پرسند؛ توانایی پاسخ با یک سند امضاشده به‌جای یک برنامه، ارزش نیم‌روز صرف‌شده را دارد.
نمونه واقعاً چه چیزی را ثابت می‌کند
چهار روش، به ترتیب اجرا می‌شوند و کد خروجی به نتیجه مرتبط است. این نمونه قرارداد را با ML‑DSA‑65 امضا می‌کند و موضوع گواهی استفاده‌شده را چاپ می‌کند. همان قرارداد را در هر سه سطح امضا می‌کند و اندازه‌های حاصل را چاپ می‌کند. فایل امضاشده را دو بار تأیید می‌کند — یک بار با گواهی عمومی امضاکننده، انتظار موفقیت، و یک بار با گواهی امضاکنندهٔ دیگری، انتظار شکست. سپس امضاهای دیجیتالی موجود در خروجی را فهرست می‌کند.
تأیید دوم همان موردی است که ارزش کپی شدن را دارد. روال‌هایی که فقط ورودی معتبر دیده‌اند، دربارهٔ این که آیا ورودی نامعتبر را رد می‌کند یا نه چیزی نمی‌گویند و برای امضاها این کل سؤال است.
مثال واقعی: قرارداد سی‌ساله
آرشیوهای با نگهداری طولانی جایی هستند که این موضوع نظری نمی‌ماند. قراردادی که امروز امضا می‌شود و به مدت سی سال نگهداری می‌شود باید در طول هر تغییری که در رمزنگاری در این بازه زمانی رخ می‌دهد، قابل تأیید بماند و «اکنون برداشت، بعداً رمزگشایی» یک مدل تهدید مستند برای دقیقاً این نوع محتوا است.
برای آرشیوی از این دست، اقدام عملی امروز دو مسیر است: RSA را برای فرمت‌هایی که ML‑DSA هنوز پوشش نمی‌دهد نگه دارید، خروجی Word را با ML‑DSA‑65 یا 87 امضا کنید و برای هر سند الگوریتم استفاده‌شده را ثبت کنید تا در حسابرسی آینده بدون باز کردن فایل‌ها بتوان آنها را تشخیص داد.
یک نکته برای اصلاح در نمونه قبل از کپی کردن آن
مخزن گواهی‌های خودامضای ML‑DSA را به همراه دارد تا نمایش به‌صورت آماده اجرا شود، به این معنی که چهار فایل PFX و یک رمز عبور ثابت در documents/ قرار دارند. برای یک گواهی تستی که فقط در داخل این نمونه معتبر است، این مناسب است.
این الگو برای مخزن خود شما مناسب نیست. به‌جای آن گواهی‌های تستی را در زمان اجرا تولید کنید، همان‌طور که نمونهٔ certificate‑validity گروه GroupDocs انجام می‌دهد، یا آنها را کاملاً از کنترل نسخه خارج نگه دارید. یک کلید کامیت‌شده لغو آن دشوار است و تمایل دارد از مدت زمان نمایش برای که نوشته شده فراتر رود.
نتیجه‌گیری
هزینه‌های سنگین مهاجرت پس‑کوانتوم شامل گواهی‌ها، سیاست‌ها و اعتبارسنج‌ها هستند. کد، حداقل برای اسناد Word در .NET، فقط یک PFX متفاوت و همان فراخوانی DigitalSignOptions است. نمونه را کلون کنید، به یکی از قراردادهای خود اشاره دهید و در چند دقیقه سه فایل امضاشده، دو نتیجهٔ تأیید و مقایسهٔ اندازه‌ها خواهید داشت — که پایهٔ بهتری برای برنامهٔ مهاجرت نسبت به یک برآورد است.