RSA و ECC، الگوریتم‌های رمزنگاری که سال‌ها بهشون تکیه کرده‌ایم، در برابر حملهٔ کامپیوترهای کوانتومی پیشرفته آسیب‌پذیر هستند. این کامپیوترها هنوز به شکل عملی در دسترس نیستند، اما رسیدنشون زودتر از انتظار محتمل شده. خوشبختانه راه‌حل در دسترس است: مهاجرت به ML-KEM برای رمزنگاری و ML-DSA برای امضا که به‌صورت Post‑Quantum طراحی شده‌اند و در 2024 توسط NIST پس از یک رقابت بین‌المللی هشت‌ساله استاندارد شدند 🔒⚛️.

فرایند مهاجرت به Post‑Quantum cryptography الان به‌سرعت در جریان است. در زمان نگارش، بخش عمدهٔ ترافیکی که Cloudflare هندل می‌کند، با ML-KEM رمزنگاری شده و بنابراین در برابر حملات «harvest‑now‑decrypt‑later» محافظت می‌شود. اما رمزنگاری فقط یک قسمت از معادله است: برای ایمنی کامل در برابر کوانتوم‌هایی که می‌توانند کریپتو کلاسیک را بشکنند، باید امضاهای post‑quantum را هم برای محافظت از سیستم‌های احراز هویت پیاده‌سازی کنیم تا دسترسی غیرمجاز کاهش یابد. هدف Cloudflare رسیدن به وضعیت کاملاً post‑quantum تا 2029 است 🚀.

ML-DSA، که امروز بهترین گزینهٔ عمومیِ امضای post‑quantum استانداردشده است، نقاط ضعف خودش را دارد: امضاها و کلیدها روی سیم بزرگ‌تر هستند و بسیاری از تکنیک‌هایی که با RSA و ECC ممکن بود، اینجا قابل اجرا نیست. با این حال، گزینه‌های بهتر امضا در افق هستند: NIST ماه گذشته اعلام کرد که ۹ الگوریتم امضای post‑quantum را به دور سوم «signatures on‑ramp» پیش‌برده و پیش‌نویس استاندارد FN‑DSA (پیش‌تر Falcon) که از رقابت قبلی انتخاب شده، به‌زودی منتشر می‌شود ✍️.

ما از پیشرفت‌های الگوریتم‌های امضای post‑quantum خیلی پیگیر بوده‌ایم و در سال‌های 2021، 2022، 2024 و 2025 دربارهٔ این پیشرفت‌ها نوشتیم. در این مطلب جدید می‌خواهیم آخرین تحولات را با جزئیات فنی بیشتر مرور کنیم و توضیح دهیم که چرا هرکدوم برای تیم‌های DevOps / SRE اهمیت دارد.

قبل از هر چیز باید با یک واقعیت روبرو شویم: الگوریتم‌های جدید امضا احتمالاً تا زمان انتقال کامل PQ آماده نخواهند بود — حتی نزدیک هم نیستند. مشکل این است که تهدید دارد زودتر از آنچه انتظار داشتیم می‌رسد؛ بنابراین نمی‌توانیم منتظر بمانیم. ML-DSA امروز قابل استفاده است و برای مرحلهٔ اول مهاجرت باید ازش استفاده کنیم. همون‌طور که Eric Rescorla در 2024 گفت: “You go to war with the algorithms you have, not the ones you wish you had.” ⚔️

با این حال، جستجو برای الگوریتم‌های امضای بهتر باز هم حیاتی است: هم برای کاهش هزینه‌های عملیاتی و هم برای داشتن گزینه‌های متنوع در سناریوهای مختلف. بیایید اول الگوریتم‌ها را مرور کنیم و بعد به جدول زمانی در دسترس شدن‌شان و دلایلی که هنوز به‌شان نیاز داریم بپردازیم.

یک نکتهٔ مهم: در قلمرو امضاها نه یک «ستارهٔ همه‌فن‌حریف» مثل Ed25519 وجود دارد که در همهٔ معیارها بهترین باشد، بلکه دو دستهٔ کلی مشاهده می‌شود: «specialists» — یعنی الگوریتم‌هایی که در بعضی معیارها نزدیک به امضاهای منحنی بیضوی هستند اما در معیارهای دیگر محدودیت دارند — و «generalists» مانند ML-DSA که متوازن‌تر اما در هر معیار ضعیف‌تر از Ed25519 است.

برای روشن‌تر شدن، چند الگوریتم شاخص را مرور می‌کنیم و نکات عملی برای تیم‌های DevOps / SRE را می‌گوییم:

SQIsign — امضاهای کوچک، زمان امضای کند
امضا و کلید در سیم کوچک‌اند (مثلاً امضا ~148 بایت، کلید ~65 بایت)؛ این یعنی جایگزینی جذاب برای ECC از نظر بایت‌های روی سیم. اما سه مشکل بزرگ دارد: پیچیدگی پیاده‌سازی، زمان امضای نسبتاً طولانی، و دشواری پیاده‌سازی امن در برابر حملات زمان‌بندی (timing side‑channel). اخیراً پیشرفت‌هایی شده و زمان‌ها بهتر شده‌اند، اما احتمالاً برای حالت‌های آنلاین حساس مثل TLS handshake در کوتاه‌مدت مناسب نخواهد بود. برای سناریوهای آفلاین مثل امضای CA یا DNSSEC که زمان بررسی (verification) اهمیت بیشتری دارد، SQIsign می‌تواند کاربردی باشد. تاریخچهٔ SIKE که در رقابت قبلی آسیب‌پذیری مهمی نشان داد، یادآور این است که ریاضیات isogeny پیچیدگی و سطح حملهٔ زیادی دارد؛ اما SQIsign از همان بردار حملهٔ SIKE استفاده نمی‌کند، و در حملات شناخته‌شده بیشتر به brute‑force شبیه است ⚠️.

UOV — امضاهای ریز، کلیدهای عمومی عظیم
UOV امضاهای بسیار کوتاهی (مثلاً ~96 بایت) ارائه می‌دهد اما کلید عمومی بسیار بزرگ (ده‌ها کیلوبایت، مثال: 66KB). این برای سناریوهایی که کلید عمومی از قبل توزیع شده مناسب است (مثل روت‌های WebPKI یا توزیع کلیدهای از پیش نصب‌شده)، اما برای جایی که کلید باید روی سیم فرستاده شود (مثل گواهینامه TLS) مشکل‌ساز است. در مثال WebPKI، اگر ریشه‌ها با UOV ذخیره شوند، مجموع کلیدها می‌تواند چند مگابایت شود که مدیریت و توزیع‌شان پیچیده خواهد بود 📦.

LMS — امضاهای حالت‌دار
LMS امضاهایی با سایز معقول دارد اما نیازمند نگهداری state بین امضاها است؛ یعنی اگر دستگاه یا پراسس state را از دست بدهد، ممکن است خطرات امنیتی پدید آید. علاوه بر این عملکرد سنجش (signing) در فرض وجود کش 32MB گزارش شده — یعنی در پیاده‌سازی‌های واقعی باید دقت زیادی در مدیریت state و حافظه داشت ⚠️.

ML-DSA — گزینهٔ عمومی و متوازن
ML-DSA به‌عنوان گزینهٔ عمومی امروز استاندارد شده، ترکیب قابل‌قبولی از اندازه و زمان اجرا ارائه می‌دهد و برای مهاجرت اولیه منطقی است. اما امضاها و کلیدها بزرگ‌تر از ECC هستند و بسیاری از بهینه‌سازی‌هایی که با RSA/ECC داشتیم، اینجا کار نمی‌کنند. از منظر عملی برای تیم‌های SRE، ML-DSA گزینهٔ کم‌ریسک‌تری برای استقرار تدریجی و اجرای hybrid (ترکیبِ کلاسیک + post‑quantum) است.

سایر نام‌ها که در دور سوم قرار گرفته‌اند — مثل FN-DSA (Falcon)، HAWK، FAEST، SDitH، MQOM، MAYO، SNOVA و غیره — هرکدام ترکیبی از مزایا و محدودیت‌ها دارند: برخی امضاهای کوچک ولی کلید بزرگ، برخی بسیار سریع در بررسی ولی کند در امضا، و برخی پیاده‌سازی‌شان در برابر کانال‌های جانبی مشکل دارد. همچنین بعضی واریانت‌ها محدودیت‌هایی مثل حداکثر تعداد امضا یا نیاز به پارامترهای خاص دارند (مثلاً SLH‑DSA 128‑24 برای کمتر از 2^24 امضا طراحی شده) ⚙️.

نکات مهم عملی برای تیم‌های DevOps / SRE

– آماده‌سازی برای اندازه‌های بزرگ‌تر: پیاده‌سازی post‑quantum ممکن است باعث افزایش حجم گواهی‌ها، افزایش زمان TLS handshake و فشار بیشتر بر شبکه شود. باید ظرفیت شبکه، MTU و caching را مجدداً ارزیابی کنید.
– توجه به کانال‌های جانبی: چند الگوریتم (مثلاً FN‑DSA و SQIsign) اجرای امن از منظر timing side‑channel را دشوار می‌کنند. برای سرویس‌هایی که کلیدها در محیط‌های چندکاربره یا با دسترسی محدود اجرا می‌شوند، این خطر جدی است. پیاده‌سازی‌ها باید constant‑time و مورد بررسی دقیق قرار گیرند 🔒.
– حالت‌دار بودن امضاها: الگوریتم‌هایی مثل LMS نیاز به مدیریت state دارند؛ این موضوع در عملیات توزیع کلید و در مقیاس ممکن است منجر به پیچیدگی‌های عملیاتی شود. باید سیاست‌های backup/replication برای state تدوین شود تا از استفادهٔ دوباره و حملات replay جلوگیری گردد.
– سناریوی آفلاین vs آنلاین: بعضی الگوریتم‌ها برای کارهای آفلاین (CA signing، به‌روزرسانی‌های نرم‌افزاری دیجیتال، DNSSEC) مناسب‌تر هستند، زیرا در آنجا هزینهٔ امضا کردن بالاتر قابل قبول است و سرعت verification اهمیت بیشتری دارد.

جمع‌بندی و راهِ جلو

در عمل باید با الگوریتم‌هایی که امروز در دسترس‌اند (مثل ML‑DSA و ML‑KEM) حرکت کرد و در عین حال به‌صورت فعال الگوریتم‌های جدیدتر را رصد و آزمایش کرد. رویکردی که برای تیم‌های DevOps / SRE منطقی است شامل این موارد است: پیاده‌سازی hybrid (ترکیب کلاسیک + post‑quantum) برای کاهش ریسک، آماده‌سازی زیرساخت برای کلیدها و گواهی‌های بزرگ‌تر، بررسی دقیق پیاده‌سازی‌ها از منظر side‑channel، و تعریف برنامهٔ مهاجرت مرحله‌ای که شامل آزمون‌های performance و ظرفیت شبکه باشد. در کوتاه‌مدت ML‑DSA برای گام اول مناسب است؛ در میان‌مدت و بلندمدت باید منتظر ویرایش‌ها و استانداردهای جدید NIST (مثل FN‑DSA و پیشرفت‌های SQIsign) باشیم و آمادگی تغییر ساختار را داشته باشیم 🔧📈.

اگر بخواهیم خلاصه کنیم: مهاجرت به post‑quantum لازم و فوری است، ولی این مهاجرت پیچیده و چندبعدی خواهد بود — نه فقط انتخاب یک الگوریتم جدید. برنامه‌ریزی، تست امن و آمادگی عملیاتی برای انواع محدودیت‌ها (حافظه، اندازه گواهی، کانال‌های جانبی و مدیریت state) کلید موفقیت است. 🙌