اگر همین امروز داده‌های حساس خود را رمزنگاری می‌کنید، احتمالاً در حال ساختن یک بمب ساعتی برای سال ۲۰۲۹ هستید. در راهنمای مفصلی که در ۱۲ اکتبر ۲۰۲۶ منتشر شد، فیلیپ والسوردا (Filippo Valsorda) اشاره می‌کند که بازه زمانی انتقال به امنیت پساکوانتومی (Post-Quantum یا PQ) در اوایل سال ۲۰۲۶ به‌شدت تغییر کرد و توسعه‌دهندگان را تنها سه سال فرصت داد تا سامانه‌های خود را در برابر تهدیدات کوانتومی ایمن کنند. این سنت انتشار «پاسخ‌های درست رمزنگاری» (Cryptographic Right Answers) در واقع دنباله‌رو مسیری است که از کالین پرسیوال در سال ۲۰۰۹ آغاز شد، سپس توماس پتاک در سال ۲۰۱۵ و لاتاکورا در سال‌های ۲۰۱۸ و ۲۰۲۴ آن را ادامه دادند.
این فوریت زمانی از آنجا ناشی می‌شود که صنعت اکنون درک کرده است که حملات «اکنون ذخیره کن، بعداً رمزگشایی کن» (Harvest-now-decrypt-later) یک ریسک فعال و جدی هستند. مهاجمان در حال حاضر داده‌های رمزنگاری‌شده را با این قصد جمع‌آوری می‌کنند که به محض عملیاتی شدن کامپیوترهای کوانتومی، آن‌ها را رمزگشایی کنند. برای یک توسعه‌دهنده، این بدان معناست که هر تبادل کلید غیر-PQ که امروز استفاده می‌شود، در واقع همین حالا یک حفره امنیتی است.
تصور کنید زیرساخت امنیتی شما مثل یک قفل است. برای یک دهه، صنعت از نوع خاصی از کلید استفاده می‌کرد که احساس می‌شد هرگز نشکستنی است. حالا، ابزار جدیدی کشف شده است که می‌تواند این قفل‌ها را در لحظه باز کند. اگر تا سال ۲۰۲۹ قفل‌ها را عوض نکنید، تمام اسراری که ذخیره کرده‌اید تبدیل به اطلاعات عمومی می‌شوند.
استانداردهای جدید متقارن
خبر خوب در به‌روزرسانی ۲۰۲۶، وضعیت رمزنگاری متقارن است. والسوردا اشاره می‌کند که الگوریتم گروور (Grover's algorithm) تهدید عملی برای این سامانه‌ها ایجاد نمی‌کند، به این معنی که رمزنگاری متقارن در وضعیت خوبی خواهد بود. اگر داده‌ها را در ابر رمزنگاری می‌کنید، توصیه همچنان بر استفاده از سرویس مدیریت کلید (KMS) است.
برای رمزنگاری محلی، این راهنما XAES-256-GCM یا XChaCha20Poly1305 را با نانس‌های (nonce) تصادفی حداقل ۱۲۸ بیتی پیشنهاد می‌کند. این گزینه‌ها بر secretbox در کتابخانه NaCl/libsodium ترجیح داده می‌شوند، زیرا secretbox در واقع یک پوشش (wrapper) برای XSalsa20+Poly1305 است که کمتر رایج است. XAES-256-GCM ترکیبی بهینه از یک KDF استاندارد و AES-GCM است که به عنوان یک AEAD با نانس گسترش‌یافته بسته‌بندی شده است. حتی اگر کتابخانه‌ای این نام را مستقیماً ارائه ندهد، می‌توان آن را از طریق APIهای KDF و AES-GCM سرهم کرد.
اگر با فایل‌های حجیم‌تر از چند مگابایت سروکار دارید، باید به Cobblestone-128 مهاجرت کنید. این یک گونه از STREAM است که از TLS مشتق شده و از خطر پردازش یا ذخیره متن ساده (plaintext) پیش از احراز اصالت جلوگیری می‌کند. Cobblestone-128 در کتابخانه pyca/cryptography موجود است و در حال اضافه شدن به کتابخانه استاندارد Go است (در حال حاضر در filippo.io/cobblestone در دسترس است).
در مورد طول کلیدها، فشار کمتری نسبت به قبل وجود دارد. در حالی که کلیدهای ۲۵۶ بیتی برای حذف حملات چند-هدفه (multi-target attacks) توصیه می‌شوند، کلیدهای ۱۲۸ بیتی (مانند آنچه در Cobblestone است) به‌دلیل تحلیل‌های دقیق، همچنان پذیرفته شده‌اند. توسعه‌دهندگان هشدار یافته‌اند که از حالت‌های بدون احراز اصالت مانند CBC، CTR یا رمزهای جریانی خام (raw stream ciphers) دوری کنند. استفاده از AES-GCM و ChaCha20Poly1305 معمولی تنها زمانی پذیرفتنی است که مطمئن باشید بیش از یک میلیارد پیام را با یک کلید رمزنگاری نمی‌کنید. همچنین AES-GCM-SIV اگر در همه جا در دسترس باشد، انتخاب خوبی است، هرچند احتمال در دسترس بودن کلی آن کم است.
جزئیات و مکانیزم‌های متقارن
- بستر AEAD: از فیلد «داده‌های اضافی» (additional data) در AEAD خود برای ذخیره بستر غیرمحرمانه، مانند شناسه کاربر یا نسخه پروتکل استفاده کنید. این کار تضمین می‌کند که داده‌ها به بستر مورد نظرشان گره بخورند.
- مدیریت جریان: یک پیام بسیار بزرگ را مستقیماً به AEAD ندهید. به‌جای آن از یک ساختار STREAM استفاده کنید. در حالی که گزینه‌هایی مانند Tink، libsodium، AWS Encryption SDK، FLOE و age وجود دارند، Cobblestone-128 انتخاب توصیه شده است.
- محدودیت کلید: هرگز از رمز عبور یا رشته‌های هگز ASCII مستقیماً به‌عنوان کلید استفاده نکنید؛ کلیدها باید یکنواخت (uniform) باشند.
- کارایی: توجه داشته باشید که AES-256 کندتر از AES-128 است زیرا در الگوریتم Rijndael، تعداد دورها به اندازه کلید وابسته است، هرچند این موضوع به‌ندرت در عمل اهمیت می‌یابد.
چرخش در رمزنگاری نامتقارن
رمزنگاری نامتقارن جایی است که چشم‌انداز از سال ۲۰۱۸ و ۲۰۲۴ به‌طور کامل تغییر کرده است. «پاسخ‌های درست» جدید برای سال ۲۰۲۶، ساختارهای ترکیبی (Hybrid) را در اولویت قرار می‌دهند که الگوریتم‌های کلاسیک و پساکوانتومی را با هم ادغام می‌کنند.
برای تبادل کلید، استاندارد طلایی اکنون X25519+ML-KEM-768 است. این رویکرد ترکیبی تضمین می‌کند که اگر یکی از الگوریتم‌ها شکست بخورد، دیگری همچنان محافظت را فراهم کند. اگر پیاده‌سازی یک مدل ترکیبی بیش از حد کند است، راهنما پیشنهاد می‌کند مستقیماً به ML-KEM-768 خالص مهاجرت کنید. گزینه P-256+ML-KEM-768 نیز معتبر است، هرچند کمتر رایج است. اکثر حملات علیه ECDH روی منحنی‌های NIST P برای تبادلات کلید موقت (ephemeral) اهمیتی ندارند.
رمزنگاری نامتقارن اکنون باید از HPKE (رمزنگاری کلید عمومی ترکیبی) با ترکیب‌کننده X-Wing (شامل MLKEM768-X25519, HKDF-SHA256 و AES-128-GCM) استفاده کند. برای کسانی که به ابزار خط فرمان (CLI) یا پشتیبانی از چندین گیرنده نیاز دارند، ابزار age با کلیدهای PQ (به‌طور خاص کلیدهایی با پیشوند age1pq) توصیه می‌شود. استفاده از ML-KEM-768 خالص در صورتی که تنها گزینه موجود باشد، پذیرفتنی است. همچنین MLKEM768-P256 یک انتخاب مناسب برای KEM است اما دسترسی به آن کمتر است.
جزئیات پیاده‌سازی نامتقارن
- وضعیت HPKE: KEMهای مربوط به PQ HPKE در حال حاضر در قالب پیش‌نویس هستند و در چهار پیش‌نویس مختلف پراکنده شده‌اند. با این حال، فرمت انتقال داده (wire format) تثبیت شده و در کتابخانه‌های اصلی عرضه شده است.
- رمزنگاری پیام‌های بزرگ: برای پیام‌های حجیم در HPKE، از همان روش تکه‌بندی (chunking) Cobblestone استفاده کنید و به‌جای یک AEAD واحد، از چندین فراخوانی متوالی Seal/Open در HPKE بهره ببرید.
- جایگزین‌های PQ: از HQC-KEM و FrodoKEM (به‌دلیل غیرعملی بودن) یا Classic McEliece (غیرعملی و شکسته شده) دوری کنید.
- پشتیبانی سخت‌افزاری: پشتیبانی از PQ در حال حاضر برای پلاگین‌هایی مانند Secure Enclave و YubiKey در حال گسترش است.
امضاهای دیجیتال و احراز هویت
احراز هویت مرز بعدی است. این راهنما ML-DSA-44 را برای امضاهای نامتقارن توصیه می‌کند. این الگوریتم بر پیشینیان خود ترجیح داده می‌شود زیرا دارای تصادفی‌سازی پوششی (hedged randomness)، بستر داخلی (built-in context) و ویژگی‌هایی مانند SUF-CMA است. اگر پیامی نیاز به پیش-هش (pre-hashing) دارد، به‌جای HashML-DSA از امضای «external-μ (Mu)» استفاده کنید.
توسعه‌دهندگان تشویق می‌شوند که از امضاهای «ترکیبی» (composite) دوری کنند، با یک استثنای بزرگ: کلیدهای SSH. نسخه OpenSSH 10.6 از ssh-mldsa44-ed25519 پذیرفته است و توسعه‌دهندگان باید برای حفظ سازگاری از این مسیر پیروی کنند. سایر جایگزین‌های PQ مانند SLH-DSA (مبتنی بر هش) در دسترس هستند اما اغلب بیش از حد کند، بیش از حد حجیم و به‌طور گسترده در دسترس نیستند.
همچنین فشار شدیدی برای کاهش کلی استفاده از امضاهای نامتقارن وجود دارد. در هر کجا که ممکن باشد، توسعه‌دهندگان باید JWTهای امضا شده را با توکن‌های نشست تصادفی جایگزین کنند یا از HMAC-SHA-256 برای امضاهای متقارن استفاده کنند. هنگام استفاده از HMAC، حیاتی است که یک رشته بایت دقیق (verbatim) را احراز کنید تا از باگ‌های کانونی‌سازی (canonicalization) و ترازکننده تجزیه‌کننده (parser alignment) جلوگیری شود. برای مثال، خودِ رشته JSON را احراز کنید، نه شیء تجزیه‌شده را.
جزئیات و محدودیت‌های امضا
- ذخیره کلید: کلیدهای ML-DSA را منحصراً به‌صورت بذر (seed) ۳۲ بایتی ذخیره کنید و از «کلیدهای نیمه‌گسترش‌یافته» (semi-expanded keys) دوری کنید.
- احراز هویت ترکیبی: احراز هویت ترکیبی پیچیده‌تر و کمتر مفید از تبادل کلید ترکیبی تلقی می‌شود. در صورت وقوع شکست امنیتی، یک استراتژی قدرتمند چرخش کلید (key rotation) مؤثرتر از یک امضای ترکیبی است.
- انتخاب پارامتر: ML-DSA-44 توصیه می‌شود زیرا در دسته‌بندی ۲ NIST قرار دارد و حاشیه امنیتی بالای ۱۲۸ بیت فراهم می‌کند.
- جایگزین‌ها: الگوریتم FN-DSA در حال حاضر در وزارت بازرگانی ایالات متحده متوقف شده است.
زیرساخت و ابزارها
در مورد امنیت وب، توصیه می‌شود تا حد امکان از OpenSSL دوری کنید. راهنما به مسیر نزولی OpenSSL اشاره می‌کند و خاطرنشان می‌کند که نویسندگان pyca/cryptography، تیم HAProxy و curl همگی از تصمیمات اخیر آن انتقاد کرده‌اند.
جایگزین‌های پیشنهادی عبارت‌اند از:
- rustls یا Go's crypto/tls: به‌دلیل ایمنی حافظه (memory-safe) ترجیح داده می‌شوند.
- BoringSSL یا AWS-LC: فورک‌های مدیریت‌شده از OpenSSL برای کسانی که مجبور به استفاده از زبان C هستند (AWS-LC به‌دلیل داشتن نسخه‌های شماره‌گذاری شده مورد توجه است).
- s2n-tls یا rustls-ffi: گزینه‌هایی برای کسانی که نیازی به سازگاری با libssl ندارند.
تمام پشته‌های TLS باید تبادل کلید X25519MLKEM768 را در اولویت قرار دهند که نیازمند TLS 1.3 است. کاربرانی که از RHEL 9 و مشتقات آن استفاده می‌کنند، باید به‌طور صریح این گزینه را فعال کنند. برای وب‌سایت‌ها، توسعه‌دهندگان باید از یک کلاینت ACME محبوب استفاده کنند و برای عرضه گواهینامه‌های درخت مرکل (Merkle Tree Certificates) در سال ۲۰۲۷ آماده شوند. در همین راستا، کلودفلر با بهره‌گیری از درخت‌های مرکل گام‌های عملی برای بیمه کردن امنیت وب در برابر تهدیدات کوانتومی برداشته است.
برای بک‌آپ‌های آنلاین، restic بر Tarsnap توصیه می‌شود. در حالی که Tarsnap یک ابزار کلاسیک است، اتکای آن به RSA آن را در مواجهه با محاسبات کوانتومی به یک «تله» (footgun) تبدیل می‌کند. Restic کاملاً متقارن و بنابراین در برابر کوانتوم مقاوم است. برای ذخیره‌سازی ابری، rsync.net به‌دلیل طرح «secret» و حالت append-only برای کاربران restic پیشنهاد می‌شود.
جزئیات زیرساخت
- نسخه‌های TLS: از TLS 1.0 و 1.1 به‌طور کامل دوری کنید. در صورت امکان از TLS 1.2 نیز اجتناب کنید.
- نسخه‌بندی OpenSSL: اگر استفاده از OpenSSL اجباری است، باید نسخه ۳.۵ یا بالاتر باشد، زیرا این اولین نسخه‌ای است که از X25519MLKEM768 پشتیبانی می‌کند.
- PKI برای اپلیکیشن‌ها: برای برنامه‌های داخلی که هر دو سر آن تحت کنترل شماست، استفاده از گواهینامه‌های X.509 خود-امضا شده ML-DSA-44 یا یک ریشه خصوصی (private root) را در نظر بگیرید.
- کتابخانه‌های مردود: راهنما نسبت به استفاده از GnuTLS، Mbed TLS، wolfSSL و Botan به‌دلیل شکست‌های هسته‌ای در گذشته هشدار می‌دهد.
نقش هوش مصنوعی در امنیت
یکی از تغییرات بزرگ سال ۲۰۲۶، کاربرد مدل‌های زبانی بزرگ (LLM) در چرخه توسعه است. والسوردا تأکید می‌کند که LLMها اکنون در یافتن باگ‌های رمزنگاری استثنایی عمل می‌کنند.
دریافت بازبینی کد (code review) از برترین مدل‌های موجود، اکنون در کنار توصیه قدیمی استفاده از زبان‌های ایمن حافظه، یک «پاسخ درست رمزنگاری» محسوب می‌شود. این یعنی هوش مصنوعی نه به‌عنوان یک کدنویس، بلکه به‌عنوان یک حسابرس امنیتی حیاتی ادغام شده است.
تکامل رمزهای عبور
مدیریت رمز عبور همچنان به نفع Argon2id یا scrypt است. برای Argon2id، پارامترهای توصیه شده m=64 MiB، t=2، p=1 (تنظیم پیش‌فرض INTERACTIVE در libsodium) است. برای scrypt، از N=2^16، r=8، p=1 استفاده کنید. Argon2id ترجیح داده می‌شود زیرا از همان مقدار حافظه scrypt استفاده می‌کند اما به زمان CPU کمتر و زمان GPU به‌مراتب کمتری نیاز دارد.
با این حال، پیشنهاد می‌شود توسعه‌دهندگان تمرکز خود را از هش کردن رمز عبور بردارند و به سمت passkeys (کلیدهای عبور) ضد-فیشینگ حرکت کنند. اگرچه passkeyها هنوز پساکوانتومی نیستند، اما در برابر رایج‌ترین تهدیدات فعلی یعنی فیشینگ و پر کردن اعتبارنامه‌ها (credential stuffing) محافظت می‌کنند. یک مهاجم کوانتومی همچنان برای شکستن آن‌ها نیاز به رهگیری ورود یا دسترسی به پایگاه داده دارد. برای کسانی که به جایگزین نیاز دارند، لینک‌های جادویی ایمیل یا SSO مبتنی بر OIDC بر SAML توصیه می‌شود.
جدول سریع استانداردهای ۲۰۲۶
- رمزنگاری داده: Cloud KMS؛ در غیر این صورت XAES-256-GCM یا XChaCha20Poly1305. برای پیام‌های بیش از چند مگابایت: Cobblestone-128.
- کلیدهای متقارن: کلیدهای ۲۵۶ بیتی در صورت نیاز به انتخاب.
- امضاهای متقارن: HMAC-SHA-256 (مقایسه تگ‌ها با توابع constant-time).
- هشینگ: SHA-512/256 بهترین است (بدون length-extension). SHA-256 و SHA-512 مناسب هستند. برای چند-هش از SequenceHash استفاده کنید. از SHA-1 و MD5 دوری کنید.
- شناسه‌های تصادفی: ۳۲ بایت تصادفی (۲۵۶ بیت). از CSPRNGهای سیستم‌عامل استفاده کنید (getrandom در لینوکس، ProcessPrng در ویندوز، arc4random_buf در macOS/BSD یا getRandomValues در وب).
- مدیریت رمز عبور: Argon2id یا scrypt؛ در حالت ایده‌آل، انتقال به passkeys.
- تبادل کلید: X25519+ML-KEM-768.
- رمزنگاری نامتقارن: HPKE با X-Wing (MLKEM768-X25519, HKDF-SHA256, AES-128-GCM) یا age با کلیدهای PQ.
- امضاهای نامتقارن: ML-DSA-44.
تحلیل: بدهی مهندسی سال ۲۰۲۶
این به‌روزرسانی سیگنالی است مبنی بر اینکه دوره «صبر و مشاهده» برای رمزنگاری پساکوانتومی به پایان رسیده است. تغییر از احتیاط سال ۲۰۲۴ به فوریت سال ۲۰۲۶ نشان می‌دهد که جامعه تحلیل‌گران رمزنگاری به اجماعی درباره سرعت پیشرفت کوانتومی رسیده‌اند.
برای یک توسعه‌دهنده معمولی، این بدان معناست که حجم عظیمی از بدهی فنی (technical debt) در حال سررسید شدن است. به‌روزرسانی یک کتابخانه آسان است، اما مهاجرت داده‌های رمزنگاری‌شده قدیمی و چرخش گواهینامه‌های ریشه در یک زیرساخت جهانی، کاری هرکوله‌ای است.
کسانی که ضرب‌الاجل ۲۰۲۹ را نادیده می‌گیرند، تنها ریسک یک نفوذ در آینده را نمی‌پذیرند، بلکه در حال ایجاد یک آسیب‌پذیری دائمی برای هر داده‌ای هستند که امروز ذخیره می‌کنند. برندگان این انتقال کسانی خواهند بود که با رمزنگاری به‌عنوان یک سیستم زنده برخورد کنند، نه یک پیکربندی «تنظیم کن و فراموش کن».
برای شروع این انتقال، توسعه‌دهندگان باید استفاده‌های فعلی خود از RSA و ECC را ممیزی کرده و پیاده‌سازی ML-KEM را در پروتکل‌های تبادل کلید خود در اولویت قرار دهند.
گفتگو