امروز، کلادفلر ورکرز (Cloudflare Workers) پشتیبانی از الگوریتم‌های مقاوم در برابر کوانتوم را در Web Crypto اضافه می‌کند. این موارد در پیش‌نویس Modern Algorithms in the Web Cryptography API گزارش گروه اجتماعی تعریف شده‌اند و شامل موارد زیر هستند:
- ML-KEM-768 و ML-KEM-1024 برای کپسوله‌سازی کلید
- ML-DSA-44، ML-DSA-65 و ML-DSA-87 برای امضاها
- توابع
encapsulateBits()،decapsulateBits()،encapsulateKey()وdecapsulateKey() - تابع
getPublicKey() - تابع
SubtleCrypto.supports() - واردات و صادرات JWK برای این الگوریتم‌ها
برای توسعه‌دهندگانی که خود را برای گذار به عصر پساکوانتومی آماده می‌کنند، این APIهای اختیاری Web Crypto آزمایش ML-KEM و ML-DSA را بدون نیاز به بسته‌بندی یک پیاده‌سازی رمزنگاری جداگانه آسان‌تر می‌کنند. آن‌ها یک مسیر مهاجرت کامل را ارائه نمی‌دهند، بلکه بلوک‌های سازنده‌ای هستند که می‌توانند برای اعتبارسنجی یکپارچه‌سازی شما استفاده شوند.
این پشتیبانی پشت پرچم سازگاری webcrypto_modern_algorithms در حالی که مشخصات همچنان در حال پیشرفت است، در دسترس قرار دارد.
زمینه
Web Crypto یکی از آن APIهایی است که فقط زمانی متوجه آن می‌شوید که فاقد مؤلفه اولیه مورد نیاز شما باشد. اگر می‌خواهید الگوریتم‌های جدید پساکوانتومی را در یک محیط جاوا اسکریپت (JavaScript) آزمایش کنید، این کار دشوار است. شما یا نمی‌توانید پروتکل را مستقیماً روی Web Crypto بسازید، یا باید پیاده‌سازی رمزنگاری خود را در جاوا اسکریپت یا WebAssembly بیاورید.
هیچ‌کدام از این گزینه‌ها ایده آل نیستند. آن‌ها بار انتخاب و نگهداری پیاده‌سازی‌های رمزنگاری را بر دوش پیاده‌کنندگان می‌گذارند، کسانی که می‌بینند برنامه‌هایشان با بسته‌بندی کد رمزنگاری بزرگ‌تر می‌شود. و این کاری است که باید برای تمام کتابخانه‌های پایین‌دستی بازتولید شود. از آنجایی که اکوسیستم باید زودتر از حد انتظار به الگوریتم‌های مقاوم در برابر کوانتوم منتقل شود، ما نمی‌توانیم منتظر الگوریتم‌های پساکوانتومی بهتری باشیم. توسعه‌دهندگان به این مؤلفه‌های اولیه نیاز دارند تا بتوانند یکپارچه‌سازی‌های پساکوانتومی را تست، ارزیابی و بهبود ببخشند.
در این مقاله، توضیح خواهیم داد که چگونه می‌توانید این مؤلفه‌های اولیه را امروز پیاده‌سازی کنید و برنامه‌های خود را برای عصر پساکوانتومی آماده کنید.
نسخه کوتاه
در اینجا نحوه عملکرد ML-KEM در ورکرز (Workers) آورده شده است. یک طرف دارای یک کلید عمومی است. طرف دیگر یک راز مشترک را برای آن کلید عمومی کپسوله می‌کند. دارنده کلید خصوصی آن را از حالت کپسول خارج کرده و همان راز را دریافت می‌کند.
هنوز هیچ رمزگذاری در آن قطعه کد وجود ندارد. ML-KEM به هر دو طرف متریال کلید مشترک می‌دهد. پروتکل‌هایی مانند رمزنگاری کلید عمومی ترکیبی (HPKE) سپس این متریال را به یک برنامه زمان‌بندی کلید و یک AEAD مانند الگوریتم AES-GCM تغذیه می‌کنند.
ML-DSA به آنچه بیشتر توسعه‌دهندگان قبلاً با Ed25519 یا ECDSA دیده‌اند نزدیک‌تر است: یک جفت کلید تولید کنید، بایت‌ها را امضا کنید، بایت‌ها را تأیید کنید.
این مثال‌ها عمداً کوچک هستند. آن‌ها پروتکل نیستند. آن‌ها قلاب‌های جاوا اسکریپت (JavaScript) برای مؤلفه‌های اولیه رمزنگاری هستند که پروتکل‌ها به آن‌ها نیاز دارند.
چرا این موضوع اهمیت دارد
مهاجرت پساکوانتومی یک کلید ساده نیست. این شامل تعداد زیادی پروتکل، کتابخانه، سرویس و محیط استقرار است که یاد می‌گیرند چگونه از مؤلفه‌های اولیه مختلف استفاده کنند.
بخشی از این کار قبلاً در TLS و SSH قابل مشاهده است. OpenSSH پشتیبانی از mlkem768x25519 را در سال ۲۰۲۴ اضافه کرد. HPKE یک پیش‌نویس برای KEMهای پساکوانتومی و ترکیبی در IETF در حال انجام دارد. IETF استاندارد RFC 9964 را برای ML-DSA در JOSE منتشر کرد، و همچنین یک پیش‌نویس پذیرفته شده برای JWE با استفاده از PQ & PQ/T HPKE ارائه داد. امضاهای پیام HTTP می‌توانند از الگوریتم‌های امضای مختلف استفاده کنند، تا زمانی که امضاکننده و تأییدکننده در مورد نحوه تولید و تأیید امضا توافق داشته باشند.
برای پشتیبانی از همه این‌ها در کلادفلر ورکرز (Cloudflare Workers)، توسعه‌دهندگان به پشتیبانی از مؤلفه‌های اولیه رمزنگاری زیرین در Web Crypto نیاز داشتند.
بدون آن، یک توسعه‌دهنده ورکرز (Workers) همچنان می‌تواند کد پساکوانتومی را آزمایش کند، اما مجبور بود یک پیاده‌سازی جداگانه را بسته‌بندی کند. این برای قابلیت حمل و آزمایش‌های اولیه مفید است، اما چیزی نیست که بخواهیم هر برنامه کاربردی تولیدی به آن ختم شود.
امضای JWTها با ML-DSA
توکن‌های وب JSON امضا شده (JWT) یک مثال آشنا هستند که با استفاده از امضاهای وب JSON (JWS) محافظت می‌شوند. با کتابخانه panva/jose که الگوریتم‌های ML-DSA-* را به Web Crypto نگاشت می‌کند، کد برنامه به شکل زیر است:
JWTها فقط یک مثال هستند. نکته بزرگ‌تر این است که کتابخانه‌ها می‌توانند عملیات ML-DSA را به جای حمل پیاده‌سازی خود برای هر محیط، به زمان اجرا محول کنند. با پشتیبانی بومی ورکرز (Workers) از ML-DSA، کتابخانه‌ها می‌توانند به جای ارسال پیاده‌سازی خود، امضا را به زمان اجرا واگذار کنند.
HPKE و OHTTP
ML-KEM یک مکانیسم کپسوله‌سازی کلید است. به نوبه خود، به دو طرف متریال کلید مشترک می‌دهد. HPKE با اضافه کردن یک برنامه زمانی کلید و یک AEAD، آن را به یک ساختار رمزگذاری کامل تبدیل می‌کند.
کتابخانه‌هایی مانند panva/hpke قبلاً حول Web Crypto و پشتیبانی زمان اجرا ساختار یافته‌اند. با قرار گرفتن ML-KEM در زمان اجرای ورکرز (Workers)، پیاده‌سازی‌های HPKE می‌توانند در صورت وجود از مؤلفه اولیه بومی استفاده کنند.
این شکلی است که ما برای پروتکل‌هایی مانند OHTTP نیز می‌خواهیم (که قبلاً در مورد آن بحث کرده‌ایم). OHTTP از HPKE استفاده می‌کند. اگر HPKE بتواند از یک KEM پساکوانتومی از طریق Web Crypto استفاده کند، آنگاه آن همتا می‌تواند بحث درباره مهاجرت به یک مجموعه رمزنگاری (ciphersuite) که از این مؤلفه‌های اولیه پشتیبانی می‌کند را آغاز کند.
کتابخانه‌ها ممکن است نیازمند تغییرات یکپارچه‌سازی خاص زمان اجرا باشند. در اینجا، HPKE.CipherSuite پیاده‌سازی‌ها را با توجه به الگوریتم‌های موجود در زمان اجرا انتخاب می‌کند.
گرفتن یک کلید عمومی از یک کلید خصوصی
چندین پروتکل نیاز دارند که پس از بارگذاری یک کلید خصوصی، یک کلید عمومی را منتشر یا مشتق کنند. پیش از این، این اغلب به معنای نگه داشتن هر دو یا انجام کار خاص فرمت بود.
تابع کمکی جدید getPublicKey() کار مستقیم را انجام می‌دهد:
برای ML-KEM، نحوه استفاده متفاوت است زیرا کلیدهای عمومی کپسوله‌سازی می‌کنند و کلیدهای خصوصی کپسوله‌سازی را حذف می‌کنند:
این یک API کوچک است که هدف آن حذف کدی است که به طور گسترده در کتابخانه‌های سر و کار با رمزنگاری کلید عمومی استفاده می‌شود.
بررسی پشتیبانی
از آنجایی که این API هنوز در تمام زمان‌های اجرا پشتیبانی نمی‌شود، کتابخانه‌ها باید به جای فرض کردن وجود آن در همه جا، آن را بررسی کنند.
کتابخانه‌هایی که در ورکرز (Workers)، نود جی‌اس (Node.js)، دنو (Deno)، مرورگرها و سایر زمان‌های اجرای سازگار با وب اجرا می‌شوند، به این نوع بررسی نیاز دارند. همچنین زمانی که فقط بخشی از پیشنهاد الگوریتم‌های مدرن پیاده‌سازی شده باشد، کمک می‌کند.
چه چیزی امروز پشتیبانی می‌شود
پیاده‌سازی اولیه ورکرز (Workers) از ML-KEM-768 به عنوان یک KEM و ML-DSA-44 به عنوان یک الگوریتم امضا پشتیبانی می‌کند. همه مستلزم تنظیم شدن پرچم سازگاری webcrypto_modern_algorithms هستند.
برای کامل بودن، ما همچنین از ML-KEM-1024، ML-DSA-65 و ML-DSA-87 پشتیبانی می‌کنیم. ML-KEM-512 پشتیبانی نمی‌شود زیرا نسخه BoringSSL مورد استفاده توسط ورکرز (Workers) آن را نشان نمی‌دهد. به جای اضافه کردن یک پیاده‌سازی جداگانه فقط برای آن نوع، ما با الگوریتم‌های موجود از طریق کتابخانه رمزنگاری بومی شروع می‌کنیم.
آخرین لیست الگوریتم‌های پشتیبانی شده همیشه در مستندات توسعه‌دهنده ما یافت می‌شود.
چگونگی پیاده‌سازی
ورکرز (Workers) روی workerd اجرا می‌شوند. این یک زمان اجرای منبع باز ساخته شده روی V8 است. این پیاده‌سازی، پشتیبانی ML-KEM و ML-DSA را به لایه Web Crypto در workerd اضافه می‌کند که توسط مؤلفه‌های اولیه BoringSSL پشتیبانی می‌شود.
این تغییر همچنین تست‌های پلتفرم وب را برای سطح API الگوریتم‌های مدرن، تست‌های خاص ورکرز (Workers) برای رفتار پرچم سازگاری، و تعاریف تایپ‌اسکریپت (TypeScript) تحت انواع جدید ورکرز اضافه می‌کند.
ما این را از یک پیشنهاد بزرگ‌تر از panva جدا کردیم. تغییری که در این وبلاگ مورد بحث قرار گرفت، که بخش اول مشخصات الگوریتم Web Crypto مدرن است، بر روی ML-KEM، ML-DSA، APIهای کمکی و پشتیبانی JWK تمرکز دارد. سایر الگوریتم‌های پیشنهاد گروه اجتماعی انکوباتور وب W3C (WICG)، مانند تابع هش SHA-3، cSHAKE، TurboSHAKE و ChaCha20-Poly1305، بخشی از این تغییر اولیه نیستند.
این محدوده کوچک‌تر بررسی را آسان‌تر می‌کند. همچنین به نویسندگان کتابخانه چیزی ملموس برای آزمایش قبل از پیاده‌سازی کل پیشنهاد الگوریتم‌های مدرن می‌دهد.
توجه داشته باشید که کلیدهای عمومی و امضاهای ML-DSA به طور قابل توجهی بزرگ‌تر از RSA یا Ed25519 هستند. یکپارچه‌سازی این الگوریتم‌ها در زمان اجرا عملکرد را بهبود می‌بخشد و نیاز به بسته‌بندی را کاهش می‌دهد. با این حال، این واقعیت را تغییر نمی‌دهد که اندازه کلیدها، امضاها یا متن رمزشده، روی سیم یا هنگام ذخیره شدن، در حال افزایش است.
چه چیزی ممکن است در آینده بیاید
پیشنهاد WICG فراتر از ML-KEM و ML-DSA است. ما موارد زیر را از مشارکت اصلی فلیپ اسکوکان در cloudflare/workerd#6403 پیاده‌سازی نکرده‌ایم که نیاز به بررسی بیشتر دارد. این شامل تابع هش SHA-3، ChaCha20-Poly1305 AEAD، cSHAKE، TurboSHAKE و HPKE است. یک پیاده‌سازی قبلاً در برابر مجموعه‌های آزمایشی panva/hpke و panva/jose برای تأیید پیاده‌سازی آزمایش شده است.
همچنین یک سوال عملی در مورد زمان تبدیل شدن این مورد به پیش‌فرض، به جای اختیاری وجود دارد. در حال حاضر، تمام این الگوریتم‌ها پشت یک پرچم سازگاری قرار دارند. این API بر اساس یک پیش‌نویس است و ما می‌خواهیم بازخورد نویسندگان کتابخانه را قبل از اینکه با آن به عنوان پایدار رفتار کنیم، دریافت کنیم.
همین امروز آزمایش را شروع کنید
این تغییر به خودی خود0 همه پروتکل‌ها را پساکوانتومی نمی‌کند. این امر به توسعه‌دهندگان ورکرز (Workers) و نویسندگان کتابخانه مؤلفه‌های اولیه‌ای را که گم کرده بودند می‌دهد: ML-KEM برای کپسوله‌سازی کلید، ML-DSA برای امضاها، و APIهای کمکی که آن مؤلفه‌های اولیه را از طریق Web Crypto قابل استفاده می‌کنند.
اگر کتابخانه‌ای را نگهداری می‌کنید که در حال حاضر پیاده‌سازی پساکوانتومی خود را بسته‌بندی می‌کند، اکنون زمان مناسبی است که API بومی را امتحان کنید و به ما بگویید چه چیزی مناسب نیست. سریع‌ترین راه برای یافتن لبه‌های خشن، قرار دادن کد پروتکل واقعی در بالای آن است. تمام جزئیات در تغییرات ما موجود است.
ما از فلیپ اسکوکان برای مشارکت و تکرارهای اصلی، فلیکس هانائو، جیمز اسنل، باس وستربان و پیتر وو برای بررسی کد، و دانیل هوایگنس برای نویسندگی مشترک کار مشخصاتی که این پیاده‌سازی از آن پیروی می‌کند، تشکر می‌کنیم.
منبع: blog.cloudflare.com