مقدمه: چرا حریم خصوصی وب به مرحلهٔ پساکوانتومی می‌رسد؟
گزارش Cloudflare با عنوان «آیندهٔ پساکوانتومی حریم خصوصی وب» در ۶ نوامبر ۲۰۲۶، مسئله‌ای را جدا از تعویض الگوریتم‌های رمزنگاری در TLS بررسی می‌کند. پایه‌های توافق کلید و احراز هویت در TLS برای ارتباط امن حیاتی‌اند، اما وب از رمزنگاریِ آسیب‌پذیر در برابر رایانش کوانتومی در لایه‌های دیگری هم استفاده می‌کند. یکی از این لایه‌ها Privacy Pass است؛ پروتکلی در سطح کاربرد که به اپراتور اجازه می‌دهد بدون تحمیل اصطکاک دائمی یا شناسایی‌پذیری بیشتر، برای دسترسی به خدمت توکن صادر و بعداً آن را بازخرید و بررسی کند.
ایده ساده، ولی از نظر مهندسی مهم است: کلاینت تعدادی توکن می‌گیرد و هر توکن را در برابر دسترسی ارائه می‌کند؛ توکنِ ارائه‌شده نباید به جلسهٔ صدورش وصل شود. چنین خاصیتی برای محدودسازی نرخ درخواست، کاهش سوءاستفاده و مدیریت ترافیک ماشینی مفید است، بی‌آنکه راه‌حل پیش‌فرض الزاماً CAPTCHA، حساب کاربری یا اثرانگشت‌گیری باشد. مشکل اینجاست که Privacy Pass کلاسیک به رمزنگاری‌هایی مانند RSA و منحنی‌های بیضوی تکیه دارد؛ در روایت Cloudflare، مهاجم کوانتومی در نهایت می‌تواند توکن‌ها را جعل کند. در مقابل، حریم خصوصیِ unlinkability یا «ناپیوندپذیری» آن از جنس تضمینی توصیف شده و با کوانتومی یا غیرکوانتومی بودن مهاجم از بین نمی‌رود.
این گزارش بر پایهٔ دو منبع رسمی توضیح می‌دهد Vole چیست، MOLE کجای معماری است و چه بخش‌هایی هنوز پژوهشی‌اند. اعداد گزارش‌شده‌اند و توصیه‌های اجرایی با «تحلیل تحریریه» از واقعیت منبع جدا شده‌اند.
خلاصهٔ اجرایی
- VOLE-in-the-Head یا VOLEitH سامانهٔ اثبات دانش صفر است، نه محصول وب یا جایگزین TLS؛ برای ساخت اثبات‌های پساکوانتومی روی روابط میدان‌های دودویی کوچک به کار می‌رود.
- MOLE مخفف «Moderation Of unLinkable Endorsements» و چارچوبی برای پنهان‌کردن هویت لنگر صادرکننده از ناظر است.
- VOLE-IHAT و VOLE-ACT به‌ترتیب نامزد تأییدیه و اعتبارنامهٔ MOLE هستند؛ هر دو هنوز پژوهشی‌اند.
- TLS کانال و توافق کلید را ایمن می‌کند؛ Privacy Pass در سطح کاربرد توکن صادر و بازخرید می‌کند. Private Access Token در دو منبع مجاز تشریح نشده و نباید خودکار معادل MOLE یا مهاجرت کامل TLS دانسته شود.
Privacy Pass در معماری وب: از صدور تا بازخرید
طبق منشور کارگروه Privacy Pass در IETF، این پروتکل سازوکاری در لایهٔ کاربرد برای ایجاد توکن و بازخرید ناشناس است. صادرکننده توکن می‌سازد و بعداً آن را بررسی می‌کند؛ کلاینت‌ها در یک اکوسیستم آن را مصرف می‌کنند. اهداف صریح شامل این‌هاست: صادرکننده نتواند بازخرید را با یکی از N توکن قبلی، با احتمالی به‌طور غیرقابل‌چشم‌پوشی بیشتر از ۱/N، پیوند دهد؛ کلاینت بتواند ارتباط توکن با جفت‌کلید متعهد را بررسی کند؛ توکن جعل‌ناپذیر باشد؛ و صدور و بازخرید کارآمد بماند.
در توضیح Cloudflare، جزء اصلی امضای کور است: کلاینت پیام را پنهان به صادرکننده می‌دهد، امضا می‌گیرد و بعداً مدرکی ارائه می‌کند که با جلسهٔ صدور قابل پیوند نیست. گیرنده کلید عمومی صادرکننده را می‌شناسد، پس هویت صادرکننده آشکار می‌ماند؛ این برای برخی مجوزها مفید، اما برای تصمیم «یکی از موجودیت‌های مورد اعتماد تأیید کرده» اطلاعاتی اضافه است.
اینجا MOLE وارد می‌شود. کلاینت و ناظر ابتدا روی مجموعهٔ لنگرها یا anchor set، یعنی کلیدهای عمومی لنگرهای مورد اعتماد، توافق می‌کنند. کلاینت هنگام بازخرید ثابت می‌کند تأییدیه‌ای از یکی از آن لنگرها دارد، بدون افشای نام لنگر. سپس ناظر یک اعتبارنامهٔ MOLE صادر می‌کند که برای مدیریت تعامل بعدی با سایت استفاده می‌شود. اعتبارنامه الزاماً عمومی‌قابل‌بررسی یا حتی پنهان‌کنندهٔ لنگر نیست، چون مخاطب آن ناظر مشخص است؛ همین انعطاف اجازه می‌دهد از امضای کور، توکن اعتباری ناشناس یا اعتبارنامهٔ نرخ‌محدود ناشناس استفاده شود.
Vole دقیقاً چیست و کجا پیاده می‌شود؟
VOLE نام یک تکنیک تعاملی برای تولید مقادیر تصادفیِ مرتبط میان دو طرف است. این هم‌بستگی‌ها مانند برچسب‌های اصالت عمل می‌کنند و به بررسی‌کننده اجازه می‌دهند درستی محاسبه‌ای را که روی شاهد پنهان انجام شده کنترل کند. در VOLEitH، اثبات‌کننده آنچه دو طرف در حالت عادی با هم تولید می‌کردند، محلی آماده می‌کند؛ به آن مقادیر تعهد می‌دهد؛ سپس تبدیل Fiat–Shamir بخش‌هایی را که بررسی‌کننده باید کنترل کند انتخاب می‌کند. نتیجه، اثبات دانش صفرِ غیرتعاملی است.
«شاهد» دادهٔ محرمانی است که دانستن آن باید ثابت شود، نه افشا. VOLEitH از نظر اندازهٔ اثبات فشردهٔ مجانبی نیست و با شاهد و پیچیدگی محاسبه رشد می‌کند، اما برای معادلات میدان‌های دودویی کوچک مناسب است. در مدار آن، XOR به جمع، AND به ضرب و چرخش‌های Keccak به جابه‌جایی مقدارها تبدیل می‌شوند.
پس Vole «در وب» به معنای یک endpoint عمومی یا گزینه‌ای در تنظیمات مرورگر پیاده نمی‌شود. در مقاله، VOLEitH لایهٔ اثباتی و سازندهٔ رمزنگاری برای طرح‌های نامزد است. PoMFRIT از VOLEitH و امضای چندمتغیرهٔ MAYO ساخته شده و با جایگزینی MAYO با UOV، اندازهٔ امضای کورِ مورد بحث به ۴٫۳ کیلوبایت می‌رسد؛ کلید عمومی UOV حدود ۴۶٫۶ کیلوبایت است. این‌ها مشخصات یک ساختار پژوهشی و نقطهٔ طراحی‌اند، نه وعدهٔ اندازهٔ نهایی شبکه یا نسخهٔ استاندارد.
از امضای چندمتغیره تا PoMFRIT و MOLE
در امضای چندمتغیره، نگاشتی درجه‌دوم روی میدان‌های کوچک داریم و امضا برداری است که معادلات را برآورده می‌کند. در UOV، trapdoor ساختار متغیرها را به بخش‌های «روغنی» و «سرکه‌ای» تقسیم می‌کند؛ با ثابت‌کردن بخش دوم، امضاکننده دستگاه بخش اول را حل می‌کند. همین شباهت محاسباتی، UOV را برای VOLEitH مناسب می‌سازد.
PoMFRIT امضای کور پساکوانتومی معرفی‌شده در مقاله است: ۶٫۷ کیلوبایت برای امضای کور و چندصد بایت برای صدور. الگو چنین است: کلاینت r تصادفی می‌سازد و c=H(m,r) را می‌فرستد؛ صادرکننده روی c امضا می‌کند؛ کلاینت بعداً اثبات π دانستن امضا و r را برای m ارائه می‌دهد. پیام در صدور پنهان است و ارائه، شیئی متفاوت از تعهد است؛ این پایهٔ ناپیوندپذیری است.
برای تأییدیهٔ MOLE، گزاره می‌گوید رابطه برای یکی از کلیدهای P1 تا PN برقرار است، اما شاخص i در شاهد پنهان می‌ماند. ناظر بنابراین عضویت در مجموعهٔ مورد اعتماد را می‌سنجد، نه هویت لنگر را. اعتبارنامه می‌تواند برای نرخ‌محدودسازی، اعتبار اعتباری ناشناس یا کنترل دسترسی تنظیم شود.
هزینه‌ها، بهینه‌سازی‌ها و وضعیت آزمایشی
Cloudflare برای پارامترهای فعلی UOV، با کلید عمومی ۴۶٫۶ کیلوبایتی و پارامترهای VOLEitH هم‌تراز FAEST-EM-128s، جدول زیر را گزارش می‌کند. اعداد «مشروط به تغییر» هستند: PoMFRIT با UOV برای صدور کمتر از ۱ کیلوبایت و بازخرید ۴٫۳ کیلوبایت، VOLE-IHAT برای صدور ۵٫۶ و بازخرید ۶٫۵ کیلوبایت، و VOLE-ACT برای صدور ۵٫۴ و خرج‌کردن ۱۲٫۰ کیلوبایت برآورد شده است. مقاله می‌گوید هر عملیات در پیاده‌سازی اشاره‌شده چند میلی‌ثانیه طول کشیده، اما کاهش زمان می‌تواند ارتباط بیشتری بخواهد.
هزینهٔ اصلی بسیاری از طرح‌ها ارزیابی Keccak و شمار دفعات آن است. کم‌کردن هش‌های داخل مدار اندازه را پایین می‌آورد، اما مدل امنیتی را به فرض one-more-UOV نزدیک می‌کند؛ خود مقاله این فرض را شاید خوش‌بینانه می‌داند و مثال جعل RSA با Privacy Pass issuer را یادآور می‌شود. Privacy Pass از RSA ۲۰۴۸ بیتی و دفاع‌های دیگر استفاده می‌کند؛ این مثال هشدار دربارهٔ بهینه‌سازی است.
بهینه‌سازی دیگر، TurboSHAKE با ۱۲ دور به‌جای ۲۴ دور SHAKE و کوچک‌کردن حالت Keccak است. تعهد چندمتغیره می‌تواند مدار را ساده کند، اما امنیت پارامترها و خطر آن برای حریم خصوصی روشن نیست. مولد شبه‌تصادفی کم‌درجه نیز هزینهٔ اثبات را جابه‌جا می‌کند و هنوز مطالعهٔ کافی ندارد.
بنابراین قابلیت آزمایشی را باید دقیق نام‌گذاری کرد: VOLE-IHAT و VOLE-ACT نامزدهای فعلی‌اند؛ برآوردها نهایی نیستند؛ برای اثبات استواری، نشان‌دادن امنیت بر مبنای UOV و رسیدن تحلیل رمزنگاری چندمتغیره به بلوغ، کار باقی مانده است. مقاله می‌گوید گذار می‌تواند از طراحی رمزنگاری به مهندسی پروتکل حرکت کند، اما هم‌زمان تصریح می‌کند که پیش از اتکا، این مراحل لازم‌اند. «چند میلی‌ثانیه» یا وجود پیاده‌سازی پژوهشی را نباید به معنی آماده‌بودن برای تولید دانست.
تمایز TLS پساکوانتومی و Private Access Token
TLS محل توافق کلید و احراز هویت کانال است. Cloudflare آن را از اولویت‌های بنیادی گذار می‌داند، زیرا بدون اجزای مقاوم، ارتباط محرمانهٔ اینترنت پس از دسترس‌پذیری رایانش کوانتومی پایدار نمی‌ماند. TLS پساکوانتومی دربارهٔ این است که طرفین کانال چگونه کلید بسازند و هویت را احراز کنند؛ این کار توکن ناشناسِ محدودکنندهٔ نرخ تولید نمی‌کند.
Privacy Pass سازوکار سطح کاربرد برای صدور، بازخرید ناشناس و تصمیم‌گیری ناظر است. «Private Access Token» در دو صفحهٔ مجاز تعریف یا مشخصات‌گذاری نشده؛ بنابراین این گزارش آن را خودکار معادل MOLE یا TLS نمی‌گیرد. نتیجهٔ قابل اتکا این است که مقاوم‌سازی کانال و مقاوم‌سازی اعتبارنامهٔ ناشناس، دو سطح متفاوت اما مکمل‌اند؛ سند محصول یا استاندارد مورد استفاده باید جداگانه بررسی شود.
تأثیر، مزایا و محدودیت‌ها
مزیت نخست حفظ حریم خصوصی در مقیاس است: کاربر برای اثبات اعتماد مجبور نیست هویت صادرکننده یا سابقهٔ صدور را بدهد. مزیت دوم کاهش وابستگی به CAPTCHA، حساب و fingerprinting است. مزیت سوم انعطاف MOLE و امکان اعتماد به anchorهای گوناگون است. منشور IETF نیز بر رمزچابکی، اثر فراداده، اندازهٔ مجموعهٔ ناشناس و خطر تمرکز صادرکننده تأکید دارد.
محدودیت اصلی اندازه است: امضای چندکیلوبایتی و کلید ده‌هاکیلوبایتی هزینهٔ شبکه، حافظه و کش را بالا می‌برد. مقاله پیشنهاد می‌کند یک بازخرید در چند درخواست مستهلک شود، اما جزئیات نهایی را نمی‌دهد. محدودیت‌های دیگر، بلوغ ناکافی تحلیل چندمتغیره و دشواری حکمرانی anchorهاست؛ تمرکز یا فرادادهٔ اضافی می‌تواند ناشناس‌بودن را کوچک کند.
راهنمای گام‌به‌گام مهاجرت دفاعی و مشروع
۱. دارایی‌ها را تفکیک کنید. مشخص کنید کدام سامانه TLS، کدام سامانه توکن سطح کاربرد و کدام کنترل نرخ به حساب یا چالش وابسته است؛ یک برچسب پساکوانتومی جای ارزیابی کل معماری را نگیرد.
۲. جریان داده را ثبت کنید. برای صادرکننده، کلاینت، ناظر و verifier بنویسید چه چیزی در صدور و بازخرید دیده می‌شود، کلید کجاست و چه فراداده‌ای افزوده می‌شود؛ هدف ناپیوندپذیری را به آزمون تبدیل کنید.
۳. مهاجرت TLS را جدا کنید. چرخهٔ عمر گواهی، کتابخانه و endpointهای توافق کلید را در محیط آزمایشی ارزیابی کنید؛ دو صفحهٔ حاضر نسخه یا پارامتر TLS سفارش‌گذاری ارائه نمی‌کنند، پس الگوریتم از این گزارش استخراج نمی‌شود.
۴. خط مبنا بسازید. اندازهٔ درخواست و پاسخ، زمان صدور و بازخرید، نرخ خطا و اندازهٔ مجموعهٔ ناشناس را ثبت کنید؛ اعداد VOLE-IHAT و VOLE-ACT را برآوردهای قابل تغییر بدانید.
۵. نمونهٔ محدود بسازید. پیاده‌سازی پژوهشی اشاره‌شده را فقط با دادهٔ ساختگی آزمایش کنید. بررسی کنید ناظر عضویت در anchor set را می‌پذیرد، اما شاخص anchor از گزارش عملیاتی نشت نمی‌کند.
۶. شکست امن تعریف کنید. برای اعتبارنامهٔ منقضی، تکراری یا نامعتبر مسیر کنترل‌شده داشته باشید؛ fallback نباید کاربر را به ردیابی پنهان یا جمع‌آوری بی‌دلیل داده وادار کند. نرخ‌محدودسازی و لغو کلید را جدا پایش کنید.
۷. گیت تولید بگذارید. تا تثبیت پارامترها، تحلیل UOV، اثبات امنیت نامزدها و ممیزی، خروجی فقط آزمایشی باشد. ورود به تولید به بازبینی رمزنگاری، تست همکاری، سنجش کش و تصویب حریم خصوصی نیاز دارد.
چک‌لیست کوتاه انتشار
- [ ] TLS و Privacy Pass در نقشهٔ معماری دو مؤلفهٔ جدا ثبت شده‌اند.
- [ ] هیچ کلاینتی مجبور نیست برای ناپیوندپذیری، هویت صادرکننده را افشا کند.
- [ ] اندازهٔ anchor set، فراداده و خطر تمرکز صادرکننده مستند شده است.
- [ ] اندازهٔ کلید عمومی و هزینهٔ چندکیلوبایتی در شبکه و کش آزموده شده است.
- [ ] کلیدها، انقضا، تکرار مصرف و مسیر شکست امن پایش می‌شوند.
- [ ] برچسب «آزمایشی» روی VOLE-IHAT و VOLE-ACT باقی مانده است.
- [ ] هیچ CVE، امتیاز CVSS یا ادعای محصولی که در منابع نیست به گزارش افزوده نشده است.
پرسش‌های متداول
آیا MOLE همان Privacy Pass است؟
خیر. Privacy Pass کلاسیک صادرکننده را برای بررسی توکن می‌شناسد؛ MOLE چارچوبی پیشنهادی برای پنهان‌کردن هویت anchor از ناظر است.
آیا VOLE یک الگوریتم نهایی است؟
در این گزارش، VOLEitH سامانهٔ اثبات دانش صفر و سازندهٔ نامزدهاست. Cloudflare از طرح‌های در حال توسعه و برآوردهای قابل تغییر سخن می‌گوید، نه استاندارد نهایی وب.
آیا پساکوانتومی‌بودن جعل و حریم خصوصی را خودکار حل می‌کند؟
خیر. مقاله می‌گوید Privacy Pass فعلی برای جعل در برابر مهاجم کوانتومی آسیب‌پذیر است، اما ناپیوندپذیری‌اش حفظ می‌شود. برای طرح‌های آینده، استواری UOV، فرض one-more و اثبات رسمی باید بررسی شود.
آیا یک بازخرید برای هر درخواست لازم است؟
منبع می‌گوید با بزرگ‌ترشدن توکن‌ها باید یک بازخرید در چند درخواست مستهلک شود، اما جزئیات نهایی را نمی‌دهد؛ این موضوع تصمیم طراحیِ باز است.
مدیر سامانه امروز چه کند؟
موجودی TLS و توکن‌های کاربردی را جدا ثبت کند، فراداده و اندازهٔ مجموعهٔ ناشناس را بسنجد، محیط آزمایشی بسازد و از ادعای مهاجرت فوری به MOLE خودداری کند.
نتیجه‌گیری
Cloudflare مسئله را فقط «انتخاب امضای بزرگ‌تر» نمی‌داند. Privacy Pass نشان می‌دهد کنترل سوءاستفاده و ناشناس‌ماندن می‌توانند کنار هم باشند، اما رمزنگاری کلاسیک توکن برای جعل در عصر کوانتومی کافی نیست. MOLE با پنهان‌کردن anchor و VOLEitH با اثبات دانش روی روابط مناسب، مسیر احتمالی را نشان می‌دهند؛ PoMFRIT، VOLE-IHAT و VOLE-ACT هنوز به اثبات امنیت، بلوغ تحلیل UOV و مهندسی پروتکل نیاز دارند.
پیام عملی برای تیم وب روشن است: کانال TLS، توکن Privacy Pass و اعتبارنامهٔ MOLE را سطوح جدا ببینید؛ حریم خصوصی را با ناپیوندپذیری و اندازهٔ مجموعهٔ ناشناس بسنجید؛ و هزینهٔ کلید و اثبات را پیش از تولید اندازه بگیرید. مهاجرت مسئولانه از موجودی‌برداری و آزمایش محدود شروع می‌شود، نه از ادعای آماده‌بودن فناوری‌ای که منبع هنوز در حال توسعه توصیف می‌کند.
