رمزنگاری پساکوانتومی چیست؟ استانداردها، TLS و مهاجرت

رمزنگاری پساکوانتومی چیست؟

PQC نرم‌افزار و الگوریتم کلاسیک است؛ برای اجرا به کامپیوتر کوانتومی نیاز ندارد. صفت «پساکوانتومی» به Threat model اشاره می‌کند: مهاجم می‌تواند در آینده یک کامپیوتر کوانتومیِ مرتبط با شکستن رمزنگاری (CRQC) داشته باشد. استانداردها بر مسائل ریاضی‌ای تکیه می‌کنند که با دانش امروز در برابر حملات کلاسیک و کوانتومی سخت باور می‌شوند؛ اثبات ابدی امنیت نیستند.

تهدید کوانتومی دقیقاً کدام بخش‌ها را هدف می‌گیرد؟

Shor و رمزنگاری کلید عمومی

یک CRQC به‌اندازه کافی بزرگ می‌تواند با الگوریتم Shor مسائل زیربنایی RSA، Diffie–Hellman، ECDH و امضاهای ECDSA/EdDSA را تهدید کند. این یعنی Key establishment و Digital signatureهای رایج باید در پروتکل‌ها و محصولات جایگزین یا ترکیب شوند. «هر کامپیوتر کوانتومی موجود» چنین توانایی ندارد و زمان رسیدن به CRQC معلوم نیست.

Grover و الگوریتم‌های متقارن

اثر بر AES و Hashها با کلید عمومی یکسان نیست. FAQ رسمی پروژه PQC در NIST توضیح می‌دهد که کاربردهای فعلی می‌توانند طبق راهنمای موجود از AES-۱۲۸/۱۹۲/۲۵۶ استفاده کنند و NIST در صورت نیاز راهنمای انتقال جدا منتشر می‌کند. پس «کوانتوم همه رمزنگاری امروز را می‌شکند» گزاره درستی نیست.

Harvest now, decrypt later

مهاجم می‌تواند ترافیک رمز‌شده را امروز ذخیره و پس از دسترسی به CRQC برای بازیابی Secret کلید عمومی تلاش کند. فوریت به سه متغیر بستگی دارد:

X = چند سال داده باید محرمانه بماند؟
Y = کشف، خرید، مهاجرت و حذف Legacy چند سال طول می‌کشد؟
Z = تا دسترسی مهاجم به CRQC چند سال مانده است؟

اگر X + Y > Z باشد، ریسک قبل از تکمیل مهاجرت شروع می‌شود.

Z ناشناخته است؛ به همین دلیل تصمیم را با سناریو و حاشیه اطمینان می‌گیرید، نه تاریخ پیش‌گویی‌شده. سوابق درمانی، اسرار تحقیق‌وتوسعه، قراردادهای بلندمدت یا داده هویتی ممکن است X بالاتری از محتوای عمومی سایت داشته باشند. Data map و طول عمر محرمانگی را با برنامه و بودجه حریم خصوصی پیوند دهید.

Key establishment، امضا و رمزگذاری متقارن را جدا کنید

Snapshot استانداردها در ۱۰ اوت ۲۰۲۶

وضعیت‌ها را با برچسب Final، Draft، Selected و Protocol integration جدا کنید. نام Algorithm بدون وضعیت سند برای Procurement کافی نیست.

صفحات رسمی FIPS 203، FIPS 204 و FIPS 205 منبع مرجع نام و وضعیت هستند. NIST در IR 8545، HQC را برای استانداردشدن انتخاب کرده اما FIPS مربوط هنوز «coming» است. خود NIST نیز IR 8547 را Draft برچسب می‌زند.

استانداردهای اصلی NIST چه می‌کنند؟

ML-KEM؛ ساخت Shared secret

ML-KEM در FIPS ۲۰۳ یک KEM مبتنی بر Module-LWE است و Parameter setهای ۵۱۲، ۷۶۸ و ۱۰۲۴ دارد. عدد بزرگ‌تر به‌معنی «برای همه بهتر» نیست؛ امنیت، Bandwidth، CPU، Library/Protocol profile و Policy تعیین‌کننده‌اند. انتخاب Parameter را از پروتکل یا محصول معتبر بگیرید، نه Dropdown سفارشی.

ML-DSA؛ امضای عمومی

ML-DSA در FIPS ۲۰۴ برای تولید و Verify امضای دیجیتال است. امضا و Public key آن نسبت به برخی الگوریتم‌های کلاسیک بزرگ‌تر است؛ بنابراین Certificate chain، Code signature، Firmware و Artifact format باید End-to-end تست شوند.

SLH-DSA؛ امضای Hash-based و Stateless

SLH-DSA در FIPS ۲۰۵ بر SPHINCS+ بنا شده و Stateless است. آن را با Schemeهای Stateful یا One-time hash signature که شمار امضا را باید دنبال کنند خلط نکنید. Trade-off اصلی می‌تواند اندازه Signature و Performance باشد.

«مقاوم» به معنی مصون از خطا نیست

Side-channel، Fault injection، RNG ضعیف، Key leakage، Algorithm confusion، API misuse و Supply-chain compromise همچنان ممکن‌اند. NIST SP ۸۰۰-۲۲۷ نهایی را برای طراحی و استفاده امن KEMها منتشر کرده است. پیاده‌سازی استانداردشده بدون استفاده صحیح امن نیست.

PQC در TLS: دو مسئله مستقل در یک Handshake

ClientHello
  supported groups → key agreement / confidentiality
  signature algorithms → authentication capability

ServerHello
  selects key agreement → derives handshake secrets

Certificate + CertificateVerify
  authenticates server with certificate/signature chain

Application traffic
  protected by symmetric AEAD keys derived from handshake

Hybrid ECDHE+ML-KEM می‌تواند Key agreement را در برابر شکست یکی از مؤلفه‌ها مقاوم کند، اما اگر Certificate/Handshake signature هنوز RSA/ECDSA باشد، Authentication پساکوانتومی نشده است. برعکس، ML-DSA certificate بدون Key agreement مناسب، HNDL محرمانگی را حل نمی‌کند. گزارش باید این دو را جدا نشان دهد.

وضعیت IETF در ۱۰ اوت ۲۰۲۶

• ECDHE-MLKEM برای TLS ۱.۳، نسخه ۰۵ یک Internet-Draft است؛ IESG آن را تأیید کرده و در صف RFC Editor قرار دارد، اما در این تاریخ هنوز RFC منتشرشده نیست. سه گروه Hybrid تعریف می‌کند.
• ML-DSA در TLS ۱.۳، نسخه ۰۵ نیز Internet-Draft فعال است و در مسیر انتشار قرار دارد؛ Status آن را RFC ننامید.

Internet-Draft ممکن است تغییر کند. برای Production، Provider باید دقیقاً Implementation، Codepoint، Draft/RFC version و Interoperability را اعلام کند؛ عبارت «TLS کوانتومی» Evidence نیست.

TLS شما کجا پایان می‌یابد؟

Browser
  ── TLS A ──> CDN / WAF / Edge
  ── TLS B ──> Load balancer / Ingress
  ── TLS C ──> Application / WordPress origin
  ── TLS D ──> Internal API / Database / Queue

هر Hop ممکن است Provider، Certificate، Key store، Library، Algorithm و SLO متفاوت داشته باشد. فعال‌سازی روی OpenSSL Origin، TLS A را تغییر نمی‌دهد اگر CDN Termination انجام دهد. همچنین Edge PQC نمی‌گوید TLS B یا Backup/KMS آماده است. Inventory باید Hop-by-hop باشد.

برای مرز TLS، Certificate chain، HSTS، Origin و Renewal، راهنمای انتخاب و نصب گواهی SSL/TLS را نیز مبنا قرار دهید.

Crypto inventory؛ دارایی را به کاربرد رمزنگاری وصل کنید

فهرست Port ۴۴۳ کافی نیست. یک Dependency ممکن است RSA را داخل JWT، Firmware verifier یا Backup envelope پنهان کند. Schema حداقلی:

asset_id, environment, owner, business_service
protocol_or_format, crypto_purpose, algorithm, parameter
implementation, version, provider, termination_point
key_location, certificate_chain, dependency, client_population
data_class, secrecy_lifetime, signature_validity_lifetime
exposure, criticality, replacement_lead_time
PQC_support_status, evidence_date, migration_path, last_test

چه منابعی را Discovery کنیم؟

• Certificate inventory و Network observation برای TLS/VPN/SSH
• Source، config، IaC، container image و SBOM برای Libraryها
• KMS/HSM/Secret manager و Key wrapping
• PKI، CA، S/MIME، PDF/Document signing و Long-term archive
• Code signing، package registry، CI/CD و Firmware/update channel
• Database encryption، Object storage، Backup و Export media
• API/JWT/OAuth/Webhook و Service mesh
• Vendor questionnaire برای SaaS، CDN، PSP، SMS و Managed service

Discovery خودکار False positive/negative دارد؛ خروجی را با Owner و Transaction واقعی اعتبارسنجی کنید. NIST در پروژه Migration خود نیز Cryptographic discovery و Interoperability را دو Workstream جدا می‌داند. Inventory را Continuous کنید، نه فایل Excel یک‌باره.

همه‌چیز را هم‌زمان مهاجرت ندهید؛ Risk tier بسازید

برای امضا، سؤال فقط محرمانگی نیست: Artifact تا چه زمان باید قابل اعتماد باشد و Verifier چه عمر دارد؟ Firmware یا سندی که ده سال Verify می‌شود ممکن است زودتر از TLS یک Landing عمومی نیازمند برنامه باشد.

Crypto agility؛ قابلیت تغییر امن، نه Dropdown الگوریتم

راهنمای نهایی NIST CSWP 39upd1 Crypto agility را توان جایگزینی و سازگاری الگوریتم‌ها در Protocol، Software، Hardware، Firmware و Infrastructure با حفظ امنیت و عملیات تعریف می‌کند.

اجزای یک طراحی چابک

• Cryptographic policy مرکزی با Owner، Approved set و تاریخ
• API/abstraction محدود به Use case؛ نه فراخوانی پراکنده Primitive
• Algorithm/parameter ID و Version در Ciphertext/Signature envelope
• Key metadata، provenance، creation/expiry/rotation و usage binding
• Negotiation با Downgrade protection و Fail-closed برای Tier بالا
• Test vector، Interop matrix، known-answer و negative tests
• Feature flag/Canary/Rollback با Guardrail امنیتی
• Telemetry بدون Key/Secret/PII و با الگوریتم Negotiated
• Deprecation/EOL، rewrap/resign/re-encrypt و Evidence حذف Legacy

Crypto agility چه نیست؟

اجازه Remote برای انتخاب هر Algorithm، Fallback خاموش‌نشده، ذخیره Ciphertext بدون Version، اجرای دو Algorithm بدون Combiner تحلیل‌شده یا «آپدیت Library در زمان لازم» Crypto agility نیست. Flexibility بی‌Policy سطح حمله است.

Hybrid را خودتان اختراع نکنید

هدف Hybrid این است که تا وقتی حداقل یکی از مؤلفه‌ها امن است، Secret نهایی امن بماند؛ اما این ویژگی به Combiner، Transcript binding، Validation، Error handling و Protocol proof وابسته است. خود IETF هشدار می‌دهد تحلیل Hybrid TLS را نمی‌توان خودکار به پروتکل دیگری تعمیم داد.

اثر عملکردی؛ با Byte، Flight و Failure اندازه بگیرید

در Draft فعلی IETF، سهم Client برای X25519MLKEM768 برابر ۱۲۱۶ بایت و سهم Server برابر ۱۱۲۰ بایت است؛ درحالی‌که مؤلفه X25519 هر طرف ۳۲ بایت است. این اعداد فقط Key share هستند، نه کل Handshake. نتیجه واقعی به Certificate، Packetization، MTU، RTT، Loss، Resumption، CPU، Device و Middlebox بستگی دارد.

Baseline کلاسیک، Hybrid و Rollback را در شرایط برابر مقایسه کنید. Median دفتر تهران جای Mobile user با Packet loss را نمی‌گیرد. Observability، SLO و Alert design را از راهنمای مانیتورینگ و Observability بگیرید.

صاحب WordPress یا فروشگاه چه کاری انجام دهد؟

1. نقشه Browser→CDN/WAF→Host/Origin→API را بکشید.
2. در هر Hop، Owner و TLS termination را مشخص کنید.
3. از CDN/Host بپرسید دقیقاً ML-KEM/FIPS/Hybrid کدام Draft/RFC را با چه Clientهایی پشتیبانی می‌کند.
4. Domain آزمایشی بسازید؛ Production-wide switch نزنید.
5. Client/OS/Browser/ISP/Mobile/VPN و Corporate proxy را Test کنید.
6. Negotiated group، fallback reason، error و p95 را بدون Secret لاگ کنید.
7. Origin TLS، Admin login، Backup، SSH و API را جدا ارزیابی کنید.
8. Rollback و Stop criteria را قبل از Canary تمرین کنید.

افزونه WordPress که مدعی «Quantum-safe encryption» است نمی‌تواند TLS Edge را کنترل کند مگر واقعاً Termination همان‌جا باشد؛ ضمن آنکه رمزنگاری Application-level قرارداد Key management و Recovery جدا می‌خواهد.

دامنه مهاجرت فراتر از HTTPS است

امنیت API فقط Algorithm نیست؛ Authorization، Schema، replay، rate limit و abuse باقی می‌مانند. مرز کامل در راهنمای امنیت API و OWASP آمده است. برای Build/Dependency/Signing و Gate انتشار نیز DevSecOps مبتنی بر Evidence را به برنامه وصل کنید.

Key management در عصر PQC حذف نمی‌شود؛ سخت‌تر می‌شود

• Key purpose را Bind کنید: KEM key برای Signature استفاده نشود.
• Parameter/Algorithm/version و implementation provenance کنار Key باشد.
• RNG/seed generation، backup، import/export و destruction Policy داشته باشد.
• Side-channel و decapsulation failure handling را از Library معتبر بگیرید.
• HSM/KMS support را با Firmware و validation دقیق راستی‌آزمایی کنید.
• Dual/hybrid key lifecycle و Rotation باید Atomic/Reconciled باشد.
• Certificate expiry، key compromise و Algorithm deprecation جدا Runbook دارند.
• Key، Seed، plaintext و shared secret هرگز در Telemetry ثبت نشوند.

Zero Trust نیز با PQC خودکار نمی‌شود؛ Resource، Identity، Policy، enforcement و session همچنان لازم‌اند. مقاله معماری Zero Trust وب این مرز را توضیح می‌دهد.

پرسش‌نامه Vendor؛ «آماده PQC هستیم» کافی نیست

نسخه ایران؛ Priority بر اساس داده و Dependency واقعی

• داده بلندعمر: سلامت، قرارداد، تحقیق‌وتوسعه، هویت یا اسرار سازمانی را با Retention و Secrecy lifetime واقعی طبقه‌بندی کنید؛ برچسب «محرمانه» کافی نیست.
• Provider: CDN، Cloud، HSM/KMS، CA، VPN و Library ممکن است Eligibility، پرداخت، Support یا Availability متفاوتی داشته باشند. Terms همان روز و Exit را مستند کنید؛ راه دورزدن محدودیت طراحی نکنید.
• شبکه: Handshake بزرگ‌تر یا codepoint تازه می‌تواند با Packet loss، Mobile radio، Proxy و Middlebox رفتار متفاوتی داشته باشد. از چند ISP و اپراتور داخل/خارج ایران Probe کنید.
• دارایی بلندعمر: تجهیزات، Firmware و سیستم‌هایی که سال‌ها تعویض نمی‌شوند Migration lead بالایی دارند؛ در Procurement جدید PQ roadmap و update channel را Gate کنید.
• Policy: Timeline NIST/US را خودکار قانون ایران ننامید. الزامات سازمان، صنعت، قرارداد و مقررات قابل‌اعمال را با متخصص واجدصلاحیت تطبیق دهید.
• تیم: کمبود متخصص دلیل Roll-your-own نیست. از Library/Profile استاندارد، Managed rollout قابل آزمون و Review مستقل استفاده کنید.

برای سرویس حیاتی، ترکیب قطع شبکه، تغییر Provider و شکست Compatibility را در یک Tabletop تمرین کنید. PQC نباید Availability را قربانی کند؛ Security و Reliability هر دو Guardrail هستند.

نقشه مهاجرت ۹۰روزه؛ هدف «کشف و اثبات» است

روز ۱ تا ۱۵: حاکمیت و Scope

Sponsor، Crypto owner، App/Network/PKI/DR/Procurement و Risk را در RACI بیاورید. تعاریف Final/Draft/Selected/Experimental، Risk acceptance و Data classes را تصویب کنید.

روز ۱۶ تا ۳۰: Discovery و Data lifetime

Crypto inventory را برای P0/P1 بسازید؛ TLS termination، PKI، KMS/HSM، Code signing، VPN/SSH، Backup و SaaS را پوشش دهید. X/Y/Z را برای داده/Artifactهای مهم تخمین بزنید.

روز ۳۱ تا ۴۵: Vendor و Dependency evidence

پرسش‌نامه را ارسال، Roadmap/Client matrix/EOL را ثبت و Contract/renewal جدید را با Crypto-agility clause Gate کنید. محصول بدون Owner یا Replacement path را Escalate کنید.

روز ۴۶ تا ۶۰: Lab و Interop

یک Use case محدود و Profile معتبر انتخاب کنید. Test vector، known-answer، failure input، side-channel/implementation evidence، packet size، CPU و client matrix را اجرا کنید.

روز ۶۱ تا ۷۵: Canary

Domain/Hop آزمایشی، Cohort کوچک، negotiation telemetry، fallback policy، SLO و rollback فعال شوند. هیچ Secret یا User payload در Log نیاید.

روز ۷۶ تا ۹۰: Gate و Roadmap چندساله

نتیجه را بر اساس Coverage، error، p95، TCO، vendor readiness و residual risk تصمیم دهید. Legacy retirement، rewrap/resign، asset refresh و budget را در Milestoneهای قابل سنجش قرار دهید.

Pilot TLS/PQC با Stop criteria

Scope: one test hostname + one edge provider + TLS 1.3
Baseline: classical ECDHE traffic and client matrix
Treatment: provider-supported standardized hybrid group
Observe: negotiated group, handshake bytes/latency/failure/fallback
Guardrails: no weaker fallback, no secret logging, origin TLS unchanged
Stop: unexplained failure, downgrade, p95/SLO breach, missing rollback
Exit: config off + cache purge + verification + incident note

پنج Runbook پیش از Rollout

۱. Handshake بعد از Canary شکست خورد

1. Cohort و rollout را Freeze کنید.
2. Client/OS/ISP/Middlebox/negotiated group و error را بدون Payload جمع کنید.
3. Edge و Origin را جدا Probe کنید.
4. طبق Policy Rollback یا Cohort exclusion موقت انجام دهید.
5. Interop test و Acceptance را اصلاح کنید.

۲. آسیب‌پذیری در Algorithm یا Implementation اعلام شد

1. Standard، Parameter، Library/version و Exposure را از Inventory بیابید.
2. Algorithm weakness را از Implementation bug تفکیک کنید.
3. Mitigation، disable/canary و replacement را از مرجع معتبر بگیرید.
4. Key/Certificate/Artifactهای اثرپذیرفته را rotate/resign/reissue کنید.
5. Evidence حذف، residual risk و Postmortem ثبت شود.

۳. Downgrade یا Fallback غیرمنتظره دیده شد

1. Transaction/handshake مرتبط و Policy expected را ثبت کنید.
2. Client capability، middlebox و server selection را مقایسه کنید.
3. Fallback خاموش یا ضعیف را برای Tier بحرانی Fail closed کنید.
4. Alert و Reason-code telemetry را اصلاح کنید.
5. تا رفع Root cause، Expansion متوقف بماند.

۴. Certificate/Signature با Verifierها سازگار نیست

1. Issuance را متوقف و chain/profile دقیق را Snapshot کنید.
2. Signer، CA، intermediate، client trust store و Verifier version را Map کنید.
3. Parallel/dual path استاندارد یا classical certificate کنترل‌شده را فعال کنید.
4. تمام Client cohortها و OCSP/CRL/CT وابستگی را Retest کنید.
5. Migration plan را با PKI owner بازنویسی کنید.

۵. Backup یا Artifact قدیمی بعد از تغییر قابل بازیابی/Verify نیست

1. Archive را Write-protect و Format/algorithm/key metadata را حفظ کنید.
2. Known-good legacy verifier/decryptor را در محیط ایزوله آماده کنید.
3. Rewrap/resign/re-encrypt را با Chain of custody و Approval انجام دهید.
4. Restore/Verify کامل و Hash/record reconciliation اجرا کنید.
5. Retention، migration trigger و Recovery drill را اصلاح کنید.

بازیابی Key/Backup باید واقعاً تمرین شود؛ اصول RPO/RTO و Restore در راهنمای بازیابی فاجعه آمده است.

PQC فقط یک کنترل است؛ امنیت اپلیکیشن را جایگزین نمی‌کند

حمله BOLA، XSS، SQL injection، سرقت Session، Credential stuffing یا مجوز اشتباه با ML-KEM حل نمی‌شود. PQC محرمانگی/اصالت در Primitive و Protocol مشخص را هدف می‌گیرد. کنترل‌های Access، Secure coding، Patch، Backup، Monitoring و Incident همچنان لازم‌اند.

تست نفوذ نیز باید هدفمند بماند: Negotiation/Downgrade و Key lifecycle می‌توانند Scope تازه باشند، اما اثبات مقاومت ریاضی الگوریتم کار Pentest معمول نیست. طراحی RoE، Evidence و Retest را از راهنمای تست نفوذ وب‌اپلیکیشن بگیرید.

چک‌لیست Go/No-go

• CRQC، Shor، Grover، KEM، Signature و QKD درست تفکیک شده‌اند.
• Current NIST Final با Selected/Draft/Future قاطی نشده است.
• TLS key agreement از certificate/handshake signature جدا گزارش می‌شود.
• تمام TLS terminationها و Owner هر Hop مشخص‌اند.
• Crypto inventory شامل Protocol، Purpose، Algorithm، Key، Data life و Dependency است.
• Risk tier با Secrecy/Validity lifetime و Migration lead ساخته شده است.
• Crypto agility شامل Policy، metadata، tests، telemetry، deprecation و rollback است.
• Hybrid فقط از Protocol/Profile تحلیل‌شده و Library معتبر استفاده می‌کند.
• Vendor Algorithm/Parameter/Protocol/Client/Key/Exit evidence داده است.
• Performance روی ISP/Device واقعی با failure/fallback/packet/latency سنجیده شده است.
• نسخه ایران Eligibility، شبکه، Provider، دستگاه بلندعمر و Policy را پوشش می‌دهد.
• Canary، Stop criteria و پنج Runbook تمرین شده‌اند.

سؤالات متداول رمزنگاری پساکوانتومی

آیا کامپیوتر کوانتومی امروز RSA و ECC سایت را می‌شکند؟

تا ۱۰ اوت ۲۰۲۶ شواهد عمومی از CRQC قادر به شکستن کلیدهای عملی رایج وجود ندارد و زمان آن نامعلوم است. ریسک فوری‌تر برای داده بلندعمر، HNDL و طولانی‌بودن مهاجرت است؛ بنابراین Inventory و برنامه‌ریزی امروز منطقی است.

ML-KEM، Kyber و رمزگذاری فایل یک چیزند؟

خیر. CRYSTALS-Kyber مبنای استاندارد نهایی ML-KEM شد. ML-KEM Shared secret ایجاد می‌کند؛ معمولاً آن Secret کلید الگوریتم متقارن مثل AES-GCM را می‌سازد. برای فایل باید Format، nonce، authentication، KDF و key lifecycle کامل تعریف شود.

آیا فعال‌سازی Hybrid TLS همه اتصال را پساکوانتومی می‌کند؟

نه لزوماً. Hybrid می‌تواند Key agreement را پوشش دهد، درحالی‌که Certificate و Handshake signature هنوز کلاسیک‌اند. Hopهای Edge→Origin و Service داخلی نیز ممکن است متفاوت باشند. گزارش باید هر لایه را جدا کند.

آیا PQC سرعت سایت را کم می‌کند؟

اثر ثابت نیست. Key share و Signature/Certificateها می‌توانند بزرگ‌تر باشند، اما نتیجه به RTT، Packet loss، MTU، Client، Resumption، CPU و CDN بستگی دارد. روی Cohort واقعی p95، failure و fallback را با Baseline مقایسه کنید.

اولین اقدام کسب‌وکار ایرانی چیست؟

Crypto inventory و Data lifetime را بسازید، TLS termination و Vendorها را مشخص کنید و برای دارایی‌های P0/P1 Roadmap بگیرید. سپس فقط یک Profile استاندارد پشتیبانی‌شده را روی Domain/Hop آزمایشی با Rollback و تست شبکه ایران Canary کنید.