استانداردهای NIST برای رمزنگاری پس‌کوانتومی نهایی شدند — ساعت مهاجرت شما به کار افتاد

در اوت ۲۰۲۴، NIST سه استاندارد رمزنگاری پست-کوانتومی را نهایی کرد: ML-KEM (FIPS 203، مبتنی بر CRYSTALS-Kyber)، ML-DSA (FIPS 204، مبتنی بر CRYSTALS-Dilithium) و SLH-DSA (FIPS 205، مبتنی بر SPHINCS+). این استانداردها پس از یک دهه ارزیابی و چندین دور بررسی الگوریتم‌ها، اکنون آماده استفاده در محیط‌های تولیدی هستند. ساعت مهاجرت از همان روزی که این استانداردها منتشر شدند شروع به تیک‌تاک کرد — نه از روزی که کامپیوترهای کوانتومی ظهور می‌کنند.

این بازه زمانی چندان انتزاعی نیست. دولت ایالات متحده از سازمان‌های فدرال خواسته تا بیشتر سیستم‌هایشان را تا سال ۲۰۳۰ به PQC مهاجرت دهند و زیرساخت‌های طبقه‌بندی‌شده زودتر از این تاریخ جابه‌جا خواهند شد. بخش خصوصی نیز از این موج عقب نمانده: Google Chrome از سال ۲۰۲۳ پشتیبانی ترکیبی از ML-KEM را در TLS ارائه داده و اکنون به نسخه نهایی FIPS 203 ارتقا یافته است. Apple با iOS 17.4 پشتیبانی از PQC را به iMessage افزود و Signal نیز پروتکل خود را در سال ۲۰۲۴ به‌روزرسانی کرد. اگر زیرساختی دارید که انتظار دارید ۱۰ سال یا بیشتر امن بماند — به‌ویژه هر چیزی که با تبادل کلید نامتقارن سروکار دارد — مهاجرت یک انتخاب نیست، یک الزام است.

حملات Harvest-Now-Decrypt-Later یک تهدید واقعی است

دلیل اینکه همین حالا باید جدی باشیم — حتی با وجود اینکه کامپیوترهای کوانتومی مؤثر بر رمزنگاری هنوز وجود ندارند — پدیده‌ای به نام HNDL یا «الان جمع‌آوری کن، بعداً رمزگشایی کن» است. دولت‌های متخاصم در حال ضبط ترافیک رمزشده امروز هستند تا پس از رسیدن توانایی کوانتومی، آن را رمزگشایی کنند. برآوردهای NIST، NSA و CISA حاکی از آن است که کامپیوترهای کوانتومی مؤثر بر رمزنگاری (CRQC) بین ۱۰ تا ۱۵ سال دیگر در دسترس خواهند بود — دقیقاً همان بازه‌ای که داده‌های ضبط‌شده در سال ۲۰۲۶ می‌توانند در آن رمزگشایی شوند و هنوز ارزش اطلاعاتی داشته باشند.

اگر اپلیکیشن شما با داده‌هایی سروکار دارد که باید برای یک دهه محرمانه بمانند — سوابق مالی، پرونده‌های پزشکی، ارتباطات، مالکیت فکری، قراردادهای دولتی — دشمن برای امروز به کامپیوتر کوانتومی نیاز ندارد. او فقط باید آن را داشته باشد در زمانی که اهمیت محرمانه ماندن آن داده‌ها برای شما هنوز پا برجاست. جمع‌آوری داده‌ها هم‌اکنون در جریان است.

اولویت‌بندی: چه چیزی و چه زمانی مهاجرت کند

همه چیز نباید همزمان جابه‌جا شود. ترتیب درست اولویت‌بندی این است: تبادل کلید اول، امضاها دوم، رمزنگاری متقارن آخر (یا اصلاً نیازی نیست).

۱. تبادل کلید — بالاترین اولویت

RSA و ECDH اولین چیزهایی هستند که کامپیوترهای کوانتومی می‌شکنند. آن‌ها را با ML-KEM (Kyber) جایگزین کنید. مسیر امن و توصیه‌شده، حالت ترکیبی است: اجرای همزمان الگوریتم کلاسیک و PQC. اگر ML-KEM ضعفی ناشناخته داشته باشد، الگوریتم کلاسیک همچنان محافظت می‌کند. اگر یک CRQC ظهور کند، لایه PQC شما را پوشش می‌دهد.

X25519MLKEM768 همان پیاده‌سازی ترکیبی است که Chrome، Cloudflare و AWS در TLS تولیدی خود از آن استفاده می‌کنند. ممکن است stack وب شما از قبل از آن پشتیبانی کند: OpenSSL 3.5 (منتشرشده در آوریل ۲۰۲۵) شامل پشتیبانی کامل از ML-KEM و ML-DSA است. فعال‌سازی آن معمولاً یک تغییر پیکربندی است، نه تغییر کد.

۲. امضاهای دیجیتال — اولویت متوسط

ML-DSA (Dilithium) جایگزین RSA-PSS و ECDSA برای امضا می‌شود. فوریت این بخش کمتر است چون امضاها مشکل HNDL ندارند — یک امضا فقط باید در لحظه تأیید معتبر باشد، نه یک دهه بعد. گواهی‌های امضای کد، امضاهای سندی با عمر طولانی و سلسله‌مراتب CA داخلی را در نقشه راه ۲۰۲۷–۲۰۲۸ خود بگذارید، نه در اسپرینت‌های ۲۰۲۶.

۳. رمزنگاری متقارن — اولویت پایین

AES-256 و SHA-256 توسط کامپیوترهای کوانتومی شکسته نمی‌شوند. الگوریتم Grover طول مؤثر کلید آن‌ها را نصف می‌کند و به همین دلیل است که AES-256 سال‌هاست به‌عنوان استاندارد توصیه می‌شود. اگر از کلیدهای متقارن ۲۵۶ بیتی استفاده می‌کنید، رمزنگاری متقارن نیازی به مهاجرت ندارد. اگر هنوز برای کارایی از AES-128 استفاده می‌کنید، به AES-256 ارتقا دهید — کار در این بخش همین است و بس.

وضعیت کتابخانه‌ها در اواسط ۲۰۲۶

اکوسیستم در تمام زبان‌های اصلی روی استانداردهای نهایی FIPS همگرا شده است:

Go

پکیج crypto/tls در کتابخانه استاندارد از Go 1.24 از X25519MLKEM768 پشتیبانی می‌کند. برای عملیات مستقیم ML-KEM خارج از TLS، golang.org/x/crypto شامل پشتیبانی پایدار از ML-KEM 768 و 1024 است. این API الگوی کلیدهای نامتقارن موجود را دنبال می‌کند: GenerateKey، Encapsulate و Decapsulate با byte sliceهای typed.

Python

pyca/cryptography نسخه 44.0.0 (نوامبر ۲۰۲۴) از ML-KEM از طریق backend OpenSSL 3.5 پشتیبانی می‌کند. رابط آن همان الگوی generate_private_key / exchange عملیات EC موجود را دنبال می‌کند. برای محیط‌هایی که کنترل نسخه OpenSSL در آن‌ها ممکن نیست، pqcrypto یک binding مستقیم به پیاده‌سازی‌های مرجع C ارائه می‌دهد.

Rust

کریت ml-kem از پروژه RustCrypto یک پیاده‌سازی خالص Rust و سازگار با no_std است که کاملاً با FIPS 203 مطابقت دارد. از واریانت‌های ML-KEM-512، 768 و 1024 پشتیبانی می‌کند و برای اهداف embedded یا WASM که امکان لینک کردن OpenSSL در آن‌ها وجود ندارد، گزینه مناسبی است. برای اتصال به پیاده‌سازی‌های Kyber پیش از استانداردسازی، pqcrypto-kyber نیز همچنان در دسترس است.

Java / JVM

BouncyCastle نسخه 1.77 و بالاتر از ML-KEM و ML-DSA با API پایدار پشتیبانی می‌کند. OpenJDK 24 نیز ML-KEM را به‌صورت preview API در قالب JEP 496 معرفی کرد و نسخه GA آن در JDK 25 هدف‌گذاری شده است. برای استقرارهای JVM در محیط تولید، BouncyCastle همچنان مطمئن‌ترین مسیر است.

فعال‌سازی PQC ترکیبی در Service Mesh

برای mTLS داخلی بین سرویس‌ها، پیاده‌سازی PQC ترکیبی بدون تغییر در کد اپلیکیشن ممکن است. Envoy Proxy نسخه 1.32 و بالاتر از هیبرید X25519+ML-KEM در صورت کامپایل با OpenSSL 3.5 پشتیبانی می‌کند. این تغییر فقط یک به‌روزرسانی پیکربندی service mesh برای لیست cipher suite در TLSParameters است. هم Istio و هم Linkerd مسیرهای مهاجرت مستندی برای این پیکربندی دارند.

برای TLS لبه، Cloudflare و AWS CloudFront در صورتی که کلاینت پشتیبانی کند، از X25519MLKEM768 مذاکره می‌کنند. اگر TLS را در یک CDN یا load balancer که کنترلی روی آن ندارید خاتمه می‌دهید، changelog ارائه‌دهنده خود را بررسی کنید — ممکن است بدون اطلاع شما، پوشش جزئی PQC داشته باشید.

یک نقشه راه سه‌ساله عملی

۲۰۲۶: تمام تبادل‌های کلید در سرویس‌های رو به بیرون را ممیزی کنید. نسخه‌های OpenSSL را در کل ناوگان شناسایی کنید. X25519MLKEM768 را روی endpoint‌های HTTPS فعال کنید (تغییر پیکربندی). تمام استفاده‌های RSA و ECDH خارج از TLS را مستند کنید: کلیدهای SSH، JWTها، PKI داخلی و هر key derivation سفارشی.

۲۰۲۷: تبادل کلید غیر-TLS را به ML-KEM مهاجرت دهید. طراحی مجدد سلسله‌مراتب CA داخلی را شروع کنید. امضای کد را برای نسخه‌های artifact جدید به ML-DSA منتقل کنید. مهاجرت کلیدهای SSH را ارزیابی کنید (OpenSSH نسخه 9.x از hybrid KEX مبتنی بر ML-KEM پشتیبانی می‌کند).

۲۰۲۸–۲۰۳۰: مهاجرت امضاها را تکمیل کنید. RSA را از تمام زیرساخت‌های جدید حذف کنید. با NIST SP 800-131C و الزامات نظارتی مرتبط (راهنمای HIPAA، مقررات PQC در PCI-DSS 5.0، استانداردهای فنی EU Cyber Resilience Act) همسو شوید.

نکات عملی و اقدامات فوری

• همین امروز X25519MLKEM768 را در TLS 1.3 روی endpoint‌های عمومی فعال کنید — این یک تغییر پیکربندی است با سربار کارایی ناچیز روی سخت‌افزار مدرن، و در برابر HNDL بلافاصله محافظت می‌کند.
• پیش از نوشتن هر کد رمزنگاری جدید، به OpenSSL 3.5 یا بالاتر یا BouncyCastle 1.77 یا بالاتر ارتقا دهید؛ این نسخه‌ها شامل پیاده‌سازی‌های نهایی FIPS 203، 204 و 205 هستند.
• سطح در معرض بودن RSA و ECDH خود را در TLS، SSH، JWT signing، PKI داخلی و هر تبادل کلید سفارشی ممیزی کنید — تبادل کلید بالاترین اولویت دارد، امضاها متوسط و رمزنگاری متقارن آخرین.
• از حالت ترکیبی (کلاسیک + PQC به‌طور همزمان) به‌عنوان مسیر مهاجرت استفاده کنید، نه یک جابه‌جایی یکباره به pure-PQC؛ این همان رویکردی است که Google، Cloudflare، AWS و Apple پیاده‌سازی کرده‌اند.
• اگر با داده‌هایی سروکار دارید که الزام محرمانگی ۱۰ ساله یا بیشتر دارند، HNDL را یک تهدید جاری و واقعی در نظر بگیرید و مهاجرت PQC برای تبادل کلید را در نقشه راه مهندسی ۲۰۲۶ خود قرار دهید، نه ۲۰۲۸.