GingerWallet، فورک WasabiWallet که توسط کارکنان سابق zkSNACKs پس از تعطیلی هماهنگ‌کننده coinjoin Wasabi نگهداری می‌شود، گزارشی از آسیب‌پذیری دریافت کرده است که توسط توسعه‌دهنده drkgry ارائه شده است. این آسیب‌پذیری به طور کلی امکان شناسایی مجدد ورودی‌ها و خروجی‌های کاربران در یک دوره coinjoin را فراهم می‌کند و به یک هماهنگ‌کننده مخرب این توانایی را می‌دهد که به طور کامل هرگونه مزایای حریم خصوصی ناشی از coinjoining را با انجام یک حمله فعال خنثی کند.

Wasabi 2.0 یک طراحی کامل از نحوه‌ی هماهنگی coinjoin در Wasabi بود که از چارچوب Zerolink با مقادیر ترکیبی ثابت به پروتکل Wabisabi با مقادیر چندگانه و پویا منتقل شد. این فرایند شامل انتقال از توکن‌های همگن و بلید شده برای ثبت خروجی‌ها به منظور ادعای بازگردانی سکه‌های شما به یک سیستم اعتبار پویا به نام اعتبار سنجی ناشناس با کلید (KVACs) بود. این امکان را به کاربران می‌دهد که مقادیر بلید شده را ثبت کنند که از سرقت سکه‌های سایر کاربران جلوگیری کند، بدون اینکه به سرور مقادیر متن‌خوان ارائه دهد که می‌تواند با هم همبسته شده و مالکیت ورودی‌های جداگانه را شناسایی کند.

هنگامی که کاربران شروع به شرکت در یک دوره می‌کنند، آنها برای دریافت اطلاعات مربوط به دوره به سرور هماهنگ‌کننده مراجعه می‌کنند. این درخواست یک مقدار در پارامترهای RoundCreated به نام maxAmountCredentialValue بازمی‌گرداند. این بیشترین مقدار اعتبار است که سرور صادر خواهد کرد. هر صدور اعتبار بر اساس مقداری که در اینجا تنظیم شده است قابل شناسایی است.

برای صرفه‌جویی در پهنای باند، چندین روش پیشنهادی برای مشتریان به منظور صحت‌سنجی متقابل این اطلاعات هرگز پیاده‌سازی نشد. این اجازه می‌دهد تا یک هماهنگ‌کننده مخرب به هر کاربر در زمان شروع ثبت ورودی‌هایشان یک maxAmountCredentialValue منحصر به فرد بدهد. در پیام‌های بعدی به هماهنگ‌کننده، از جمله ثبت خروجی، هماهنگ‌کننده می‌تواند شناسایی کند که با کدام کاربر در ارتباط است بر اساس این مقدار.

با “برچسب‌گذاری” هر کاربر با یک شناسه منحصر به فرد به این شیوه، یک هماهنگ‌کننده مخرب می‌تواند ببیند که کدام خروجی‌ها متعلق به کدام کاربران است و تمام مزایای حریم خصوصی که می‌توانستند ناشی از coinjoining به دست آورند را خنثی کند.

به نظر من، drkgry به‌طور مستقل این مشکل را کشف کرده و با حسن نیت آن را افشا کرده است، اما اعضای تیم که در هنگام فاز طراحی Wabisabi در zkSNACKs حضور داشتند، به‌طور کامل از این مشکل آگاه بودند.

“هدف دوم هش دوره، محافظت از مشتریان در برابر حملات برچسب‌گذاری از طرف سرور است، پارامترهای صدور اعتبار باید برای همه اعتبارات یکسان باشد و سایر metadata دوره نیز باید برای همه مشتریان یکسان باشد (به عنوان مثال، برای اطمینان از اینکه سرور در تلاش نیست تا بر روی مشتریان تأثیر بگذارد تا بایاس قابل تشخیص در ثبت‌نام‌ها ایجاد کند).”

این موضوع در سال ۲۰۲۱ توسط یووال کاگمن، که به عنوان nothingmuch نیز شناخته می‌شود، مطرح شد. یووال توسعه‌دهنده‌ای بود که پروتکلی را طراحی کرد که به پروتکل Wabisabi تبدیل شد و یکی از طراحان در واقع مشخص‌کردن کامل پروتکل با ‪István András Seres‬ بود.

یک یادداشت نهایی این است که آسیب‌پذیری برچسب‌گذاری بدون این پیشنهاد از یووال و همچنین اثبات کامل مالکیت مربوط به UTXOهای واقعی طبق پیشنهاد او در درخواست کشش اولیه‌اش برای بحث درباره حملات برچسب‌گذاری، واقعاً مورد توجه قرار نمی‌گیرد. تمام داده‌ها که به مشتریان ارسال می‌شود به یک شناسه دوره خاص وابسته نیست، بنابراین یک هماهنگ‌کننده مخرب هنوز قادر است حمله مشابهی با ارائه شناسه‌های منحصر به فرد برای هر دوره به کاربران، و به سادگی کپی‌کردن داده‌های ضروری و اختصاص‌دهی مجدد هر شناسه منحصر به فرد دوره برای هر کاربر قبل از ارسال هر گونه پیام انجام دهد.

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