كيف يمكن للبيتكوين مقاومة الحواسيب الكمومية؟ مقارنة بين ثلاثة مخططات توقيع قائمة على الشبكات

المؤلف الأصلي: فريق بلوكستريم

الترجمة الأصلية: سورشا، فورسايت نيوز

أصدرت بلوكستريم ريسيرش تقريرًا بحثيًا شاملًا حول التوقيعات القائمة على الشبكات للبيتكوين. يلخص هذا المقال محتوى البحث والنتائج الرئيسية والتوصيات ذات الصلة. يمكن الوصول إلى التقرير الكامل هنا.

التوقيعات الرقمية هي الآلية الأساسية لتفويض معاملات البيتكوين، وتوقيعات شنور وECDSA المستخدمة حاليًا لهذا الغرض رخيصة جدًا. في عام 1994، أثبت شور أن الحاسوب الكمومي القوي بما يكفي يمكنه كسر كلا النوعين من التوقيعات. وبينما يوجد جدل مستمر حول متى ستتوفر مثل هذه الأجهزة، نحتاج إلى تطوير خطة نشر قابلة للتطبيق للتوقيعات ما بعد الكمومية قبل وصول المشكلة فعليًا.

مخططات التوقيع القائمة على الشبكات هي مرشح شائع لاستبدال التوقيعات الحالية. لتشفير الشبكات تاريخ بحثي يمتد لأكثر من قرن، وتطبيقاته التشفيرية تطورت منذ ما يقرب من ثلاثة عقود. في التشفير ما بعد الكمومي، تقدم التوقيعات القائمة على الشبكات عدة مزايا: يمكن أن يصل الحجم الإجمالي للمفاتيح العامة والتوقيعات إلى أقل من 1.6 كيلوبايت، وتتمتع ببنية جبرية واعدة لدعم التوقيعات المتعددة والتوقيعات العتبية والبراهين الموجزة في المستقبل.

يدرس هذا التقرير ثلاثة مخططات: ديليثيوم وفالكون وهوك. للقراء غير الملمين بتشفير الشبكات، نشرح مبررات التصميم لكل مخطط، ونقدم وصفًا كاملًا لتدفق الخوارزمية، ونحللها من أبعاد مثل الأمان والأداء والنشر العملي (مثل اشتقاق مفاتيح المحفظة). من بين الثلاثة، أي المخططات يمكن نشرها فعليًا على سلسلة كتل البيتكوين؟

معايير التقييم

لبيتكوين قيودها الخاصة على اختيار مخطط التوقيع، ويركز هذا التقييم على أربعة معايير أساسية:

• تكلفة السلسلة: أحد أهم المقاييس هو الحجم الإجمالي للمفاتيح العامة والتوقيعات. عند إنفاق مخرج، يتم تسجيل كل من المفتاح العام والتوقيع على السلسلة، وتحتاج العقد الكاملة إلى تنزيل وتخزين كل بايت. عبء التحقق مهم بنفس القدر: يتم التحقق من كل توقيع بواسطة جميع العقد في الشبكة، والتحقق البطيء سيثقل كاهل الشبكة بأكملها.
• تعقيد التطبيق: ما إذا كان يمكن تنفيذ المخطط بشكل آمن أمر بالغ الأهمية. إذا كان التصميم يتطلب حساب الفاصلة العائمة أو أخذ عينات غاوسية دقيقة، فإن خطأ التنفيذ أو هجوم القناة الجانبية مثل تحليل التوقيت قد يكشف المفتاح. لتحقيق ترحيل سلس، فإن تعقيد التطبيق عامل لا يمكن تجاهله.
• مخاطر التطبيق: عند الدمج الفعلي في البيتكوين، توجد عقبات عملية متنوعة: اختيار دالة الهاش على مستوى الإجماع (معظم المرشحين يستخدمون SHAKE، بينما تستخدم البيتكوين SHA-256)، وإمكانية إعادة إنتاج نتائج التوقيع عبر المنصات، وما إذا كان إجراء التوقيع يناسب قيود الذاكرة في محافظ الأجهزة.
• إمكانات التطوير المستقبلية: الغالبية العظمى من محافظ البيتكوين تستخدم آلية BIP-32 الهرمية الحتمية: من مفتاح عام رئيسي واحد، يمكن اشتقاق عدد لا نهائي من المفاتيح العامة الفرعية دون الوصول إلى المفتاح الخاص. حاليًا، لا يوجد مخطط توقيع ما بعد كمومي موحد يدعم هذه الميزة بشكل أصلي، لذلك ندرس تكلفة إضافة هذه القدرة؛ كما نفحص متغيرات مخططات غير قياسية متنوعة قد تقدم فوائد إضافية.

ما مستوى الحماية الذي يجب اختياره؟

قبل مقارنة الأحجام، يجب أولاً تحديد مستوى الحماية المستهدف، وهذا الاختيار ليس مباشرًا كما يبدو. يصنف NIST مستويات الحماية من 1 إلى 5؛ المستويات الأعلى توفر حماية أقوى ولكن أحجام مفاتيح وتوقيعات أكبر.

نعتقد أن البيتكوين يجب أن تتبنى على الأقل مستوى الحماية 3. قد تظل مخرجات البيتكوين غير منفقة لعقود، وإذا أدت التطورات في تحليل الشفرات إلى تقليل مستوى الحماية الفعلي للمخطط، فسيتم قفل الأصول بمفاتيح ضعيفة وتتعرض لمخاطر طويلة الأجل. لقد صمدت الافتراضات الشبكية بالفعل لما يقرب من ثلاثة عقود من التحليل التشفيري العام، أطول من أساس البحث عندما تبنت البيتكوين المنحنيات الإهليلجية. ومع ذلك، فإن البنية الجبرية المعقدة لتشفير الشبكات لا تزال تترك العديد من السبل للهجمات المستقبلية، ولا ينبغي لنا المراهنة بكل حمايتنا طويلة الأجل عليها.

المنتجات الرئيسية السائدة اتخذت نفس الحكم. بروتوكول iMessage PQ3 من Apple يتجاهل مباشرة معلمات الشبكات من المستوى 1 ويستخدم معلمات المستوى 3 والمستوى 5 في كل مكان؛ تستخدم Cloudflare ML-KEM-768 (المستوى 3) في نشر TLS ما بعد الكمومي، مشيرة إلى أنه بينما يبدو المستوى 1 آمنًا حاليًا، من الضروري الاحتفاظ بهامش حماية لعقود من التحليل التشفيري المستقبلي. الأفق الزمني للحماية للبيتكوين أطول من كليهما.

رفع مستوى الحماية يأتي بتكلفة. على سبيل المثال، نقل ديليثيوم من المستوى 2 إلى المستوى 3 يزيد الحجم الإجمالي بحوالي 1.5 كيلوبايت. يقارن التقرير مجموعات البارامترات في جميع مستويات الحماية، مما يسمح للقراء بموازنة المفاضلات بأنفسهم. حالة هوك تثبت أن اعتبارات الحماية المتحفظة ليست مجرد نظرية.

تحليل مفصل للمخططات المرشحة

ديليثيوم: تصميم بسيط

ديليثيوم، الموحد من قبل NIST كـ ML-DSA في FIPS 204، ينقل نموذج الالتزام-التحدي-الاستجابة لتوقيعات شنور إلى حساب الشبكات المعيارية.

أكبر ميزة له هي البساطة. جميع العمليات في ديليثيوم هي عمليات أعداد صحيحة: عمليات الحلقات، ضرب المصفوفات والمتجهات، الهاش، والتقريب. لا توجد حساب فاصلة عائمة ولا أخذ عينات غاوسية منفصلة. من الأسهل كتابة تطبيقات ذات زمن ثابت. وهو أيضًا المرشح الأكثر نشرًا على نطاق واسع، مدمج بالفعل في OpenSSL وBoringSSL وAWS-LC وApple CryptoKit.

المفاضلة هي الحجم الأكبر. عند مستوى الحماية 3، يمتلك ML-DSA-65 مفتاحًا عامًا بحجم 1952 بايت وتوقيعًا بحجم 3309 بايت، بإجمالي 5261 بايت، حوالي 55 ضعف الحجم الإجمالي للمفتاح العام/الخاص والتوقيع الأصلي للبيتكوين، مما يجعله الأكبر بين المخططات الثلاثة عند نفس مستوى الحماية.

بالنسبة للبيتكوين، الجانب الأكثر قيمة في ديليثيوم هو أنه الوحيد من بين الثلاثة الذي يقترب من تنفيذ اشتقاق مفاتيح بأسلوب BIP-32. بناء المفاتيح القابل لإعادة العشوائية DilithiumRK يمكنه توليد مفاتيح فرعية من المفاتيح الأم باستخدام المعلومات العامة فقط. يحلل التقرير ثلاثة متغيرات، بما في ذلك DilithiumRKS المقترح من قبلنا، حيث يكون منطق الاشتقاق بالكامل داخل برنامج المحفظة والسلسلة تتطلب فقط محققًا قياسيًا لمعالجة توقيعات ML-DSA العادية. ومع ذلك، لا يوجد أي من الثلاثة جاهز للإنتاج: متغيران يتطلبان تعديلات على المحقق، وDilithiumRKS نفسه يفتقر إلى إثبات عدم قابلية التزوير الكامل؛ جميع المخططات تعتمد على مصفوفة مشتركة على مستوى الشبكة، وهي آمنة رسميًا تحت افتراض Module-LWE ولكنها تربط حماية جميع المفاتيح بمثيل واحد. نعتقد أن اشتقاق المفاتيح العامة القائم على ديليثيوم هو حاليًا مجرد إثبات مفهوم ولا يمكن نشره عمليًا.

فالكون: مخطط مدمج

فالكون، الذي اختاره NIST وتم توحيده كـ FN-DSA، هو الأكثر إحكامًا بين الثلاثة. عند مستوى الحماية 1، يمتلك Falcon-512 حجمًا مشتركًا للمفتاح العام والتوقيع يبلغ 1563 بايت؛ عند المستوى 5، يبلغ إجمالي Falcon-1024 3073 بايت. Falcon-1024، بهامش حماية أعلى، أصغر حتى من ديليثيوم من المستوى 3.

يتبع فالكون نهجًا مختلفًا عن ديليثيوم: نموذج الهاش والتوقيع القائم على شبكات NTRU. المفتاح الخاص للموقّع هو أساس قصير للشبكة؛ يتم هاش الرسالة إلى نقطة في الفضاء، ويستخدم الموقّع الأساس القصير للعثور على متجه شبكة قريب من تلك النقطة. النقطة والمتجه القريب معًا يشكلان التوقيع؛ التحقق يتحقق فقط من أن المتجه ينتمي إلى الشبكة وقريب بما فيه الكفاية. التحدي في التنفيذ هو العثور على المتجه دون تسريب معلومات عن الأساس. المخططات المبكرة GGH وNTRUSign اختارت مباشرة نقاط شبكة قريبة، مما سرب بعض المعلومات الهندسية مع كل توقيع. يتبنى فالكون إطار GPV، بأخذ عينات من المتجهات القريبة من توزيع غاوسي، مما يثبت أن المخرجات المأخوذة مستقلة عن الأساس، مما يزيل خطر التسريب، لكن صعوبة تنفيذ العينة تزداد بشكل كبير.

العينة هي نقطة الضعف الهندسية في فالكون. تعمل في مجال فورييه المركب وتتطلب حساب الفاصلة العائمة. المعالجات والمترجمات وخيارات تحسين الترجمة المختلفة يمكن أن تسبب نتائج فاصلة عائمة غير متسقة. هذه ليست مجرد مشكلة توافق ولكنها أيضًا مصدر قلق أمني: يتطلب إثبات حماية GPV ألا يخرج الموقّع أبدًا متجهين قصيرين مختلفين لنفس الملخص؛ إذا أصبح التوقيع حتميًا، فإن اختلافات تقريب الفاصلة العائمة الناتجة عن المنصة ستنتهك هذا الشرط. يوجد حل قابل للتطبيق: يمكن لفالكون الحتمي استبدال الفاصلة العائمة للأجهزة بمحاكاة الأعداد الصحيحة، مما ينتج توقيعات متطابقة على جميع المنصات. التكلفة هي تباطؤ في سرعة التوقيع بحوالي 15 ضعفًا وتباطؤ في توليد المفاتيح بحوالي ضعفين.

الأهم من ذلك، التحقق لا يتأثر: تحقق فالكون يعتمد بالكامل على الأعداد الصحيحة، حتمي، وهو أيضًا الأسرع بين المرشحين. هذه الخاصية غير المتماثلة ودية جدًا للبيتكوين: يتم التوقيع مرة واحدة بواسطة المحفظة عند إنفاق معاملة، بينما يتم التحقق من كل توقيع بواسطة جميع العقد الكاملة في الشبكة. التباطؤ بمقدار 15 ضعفًا في التوقيع هو تكلفة منخفضة التردد، وفي المقابل نحصل على إمكانية إعادة الإنتاج عبر المنصات وحساب الأعداد الصحيحة، وهو ما نعتبره مفاضلة معقولة. لذلك، فإن مشكلة الفاصلة العائمة هي عقبة يمكن حلها بوسائل هندسية، وليست عيبًا قاتلًا.

نقطتان يجب ملاحظتهما: بسبب القيود الهيكلية، لا توجد معلمات من المستوى 3 لفالكون؛ يجب اختيار إما المستوى 1 أو المستوى 5. بناءً على اعتبارات هامش الحماية، نوصي بـ Falcon-1024. ثانيًا، يستهلك التوقيع كمية كبيرة من الذاكرة: تعتمد العينة لمجموعة المعلمات 1024 على شجرة محسوبة مسبقًا، تشغل حوالي 90 كيلوبايت من الذاكرة. يمكن لمحافظ الأجهزة إعادة بناء الشجرة فرعًا بفرع ديناميكيًا، مما يقلل استخدام الذاكرة إلى 16 كيلوبايت، لكن وقت التوقيع يتضاعف. التوقيع الأبطأ على الأجهزة هو تكلفة حقيقية، لكنها لا تزال مقبولة.

هوك: مخطط فاشل

هدف هوك إلى الجمع بين مزايا المخططين الآخرين: توقيعات Hawk-512 تبلغ 555 بايت فقط، أصغر من فالكون؛ التوقيع يعتمد بالكامل على الأعداد الصحيحة، مع حد أدنى لاستخدام الذاكرة يبلغ 6 كيلوبايت فقط. كان أيضًا المرشح الوحيد القائم على الشبكات المتبقي في الجولة الثالثة من مسابقة التوقيعات الإضافية لـ NIST، ويخصص التقرير مساحة كبيرة لهذا المخطط.

المفاضلة تكمن في الافتراضات الأمنية. لا يعتمد على مشاكل NTRU أو SIS التي خضعت لعقود من التحليل التشفيري، بل على مشكلة تماثل الشبكات وافتراض one-more-SVP، وكلاهما له تاريخ بحثي قصير نسبيًا.

قبل الانتهاء من التقرير مباشرة، اكتشف سترازنيكاس ووايس من Anthropic عيبًا هيكليًا في بناء شبكات هوك: بُعد مشكلة SVP التي يجب حلها فعليًا لاستعادة المفتاح هو نصف ما قصده المصممون فقط. تم إضعاف بتات حماية استعادة المفتاح لمجموعات المعلمات المرشحة بشكل كبير. أكمل الباحثون هجوم استعادة مفتاح كامل من البداية إلى النهاية على معلمة التحدي HAWK-256 المستخدمة للتحليل التشفيري؛ حتى تحت الهجوم، تظل HAWK-512 وHAWK-1024 المقترحتان رسميًا غير قابلتين للكسر عمليًا. أكد فريق هوك صحة الهجوم وسحب المخطط من عملية NIST؛ وذكر الفريق أنه إذا تم إصلاح الثغرة بمضاعفة المعلمات، فإن ميزة الحجم الأصلية لهوك ستختفي تمامًا.

يحتفظ التقرير بقسم هوك لأن الهجوم يستهدف الخصائص الجبرية لحقل أرقام محدد ولا ينفي تمامًا نموذج التصميم. ما إذا كانت إعادة التصميم يمكن أن تتجنب الثغرة تظل سؤالًا مفتوحًا. حادثة هوك تثبت أيضًا بشكل بديهي إصرارنا على هوامش الحماية المتحفظة: مخطط بحجم وسرعة ممتازين، بعد أن مر بجولات متعددة من التوحيد القياسي، يمكن أن ينخفض مستوى حمايته المقدر بشكل كبير بورقة واحدة.

جدول مقارنة المخططات

جميع المخططات في الجدول أعلاه (بما في ذلك SPHINCS+) هي توقيعات عديمة الحالة: لا يحتاج الموقّع إلى تسجيل التوقيعات السابقة. التوقيعات القائمة على الهاش ذات الحالة مثل XMSS يمكنها تحقيق أحجام توقيع أصغر ولكنها تتطلب الحفاظ على حالة التوقيع؛ انظر التقرير الخاص بالتوقيعات القائمة على الهاش للمقارنة.

لا تزال هناك عقبات كثيرة أمام النشر

يفتقر فالكون إلى مخطط اشتقاق مفاتيح قابل للاستخدام. المخطط الوحيد المتاح علنًا لاشتقاق مفاتيح بأسلوب BIP-32 لفالكون يعيد عشوائية أساس المفتاح الخاص، مما يتسبب في زيادة الحد الأعلى لمعيار التوقيع بشكل كبير، وتتضخم التوقيعات على السلسلة إلى حوالي 23.7 كيلوبايت. علاوة على ذلك، لا تلبي معلمات المخطط شروط الحماية الخاصة به، وإصلاح هذه المشكلة سيزيد الحجم أكثر. لا يوجد حاليًا تنفيذ قابل للتطبيق لاشتقاق المفاتيح العامة لفالكون، وهو أيضًا المشكلة المفتوحة الأكثر قيمة المحددة في التقرير.

معيار فالكون لم يتم الانتهاء منه بعد. على الرغم من أن NIST اختارت فالكون، لم يتم إصدار مسودة FN-DSA رسميًا. فقط بعد اكتمال التوحيد القياسي سيكون لدينا تطبيقات مدققة ومتجهات اختبار ودعم على مستوى الأجهزة. يمكن أن يقلل الاعتماد الواسع من مخاطر وصعوبة الدمج في طبقة الإجماع للبيتكوين. نوصي بانتظار الإصدار الرسمي لـ FN-DSA؛ حتى ذلك الحين، يظل فالكون في حالة تغير مستمر.

متغير Falcon-WS: هذا المتغير يخفف المعلمات الداخلية ويعتمد على أخذ العينات بالرفض للتعويض، مما يضغط الحجم الإجمالي إلى 1114 بايت عند المستوى 1 و2387 بايت عند المستوى 5، مما يقلل الحجم أكثر مقارنة بفالكون الأصلي. هذا الاتجاه له قيمة بحثية لكنه لن يُدرج في المعيار الرسمي ويتطلب مزيدًا من التحقق التحليلي التشفيري. وجدت الأبحاث الحالية عيوبًا في إثباتات عدم قابلية التزوير القوية لمخططاته المشتقة (عدم قابلية التزوير العادية لا تتأثر).

هل ستظهر مخططات أفضل في المستقبل؟ بصرف النظر عن المخططات المذكورة أعلاه، تعود عائلة فيات-شمير إلى BLISS في عام 2013. النتيجة الأخيرة لغارتنر في CRYPTO 2025، بناءً على افتراضات ناضجة، لها أحجام ورقية مماثلة لفالكون. السبب الجذري لصعوبة هندسة هذه العائلة يكمن في أمان التنفيذ: تم كسر BLISS بهجمات القناة الجانبية بسبب أخذ العينات الغاوسية غير الثابتة الزمن؛ المخططات اللاحقة لم تحل هذه المشكلة تمامًا، والنتيجة الأخيرة تشير أيضًا إلى أن حماية خطوة أخذ العينات أكثر صعوبة. حتى يتم حل المشكلة، تكون هذه المخططات جذابة نظريًا فقط وغير مناسبة للنشر.

التوقيعات القائمة على الشبكات والهاش يمكن أن تكمل بعضها البعض. يمكن أن تكون التوقيعات القائمة على الشبكات مكونات لمخططات هجينة. على سبيل المثال، في SHRINCS، يستخدم مسار الاسترداد عديم الحالة حاليًا توقيعات SPHINCS+ بعدة كيلوبايتات؛ استبدالها بتوقيعات فالكون (أو Falcon-WS) سيكون أصغر وأسرع في التحقق، مما يقلل بشكل كبير من عبء مسار الاسترداد غير المتكرر دون التأثير على مسار الاستخدام اليومي.

استنتاجات البحث

ترتيب المرشحين القائمين على الشبكات واضح: انسحب هوك من المنافسة بعد هجوم فريق Anthropic؛ ديليثيوم لديه أقل صعوبة تنفيذ وهو المخطط الوحيد الذي لديه أساس بحثي لاشتقاق المفاتيح، لكن حجمه غير ودود لتكاليف البيتكوين على السلسلة؛ يجمع فالكون بين الحجم المدمج والتحقق السريع والافتراضات الأمنية الناضجة؛ نقطة ضعفه الرئيسية—حساب الفاصلة العائمة على جانب التوقيع—لديها بالفعل حل هندسي قابل للتطبيق. إذا كان علينا اختيار مخطط توقيع قائم على الشبكات للبيتكوين اليوم، فسنختار Falcon-1024.

في الوقت الحالي، وجهة نظرنا متسقة مع تقرير التوقيعات القائمة على الهاش: المسار قصير الأجل المتحفظ يظل التوقيعات القائمة على الهاش، مع افتراضات الحماية الأكثر نضجًا وأقل مخاطر، مناسبة كمخطط انتقالي. بمجرد الانتهاء رسميًا من FN-DSA، مع مواصفات مستقرة وقواعد أكواد مدققة ودعم محافظ الأجهزة، سيجلب فالكون تحسينات كبيرة على التوقيعات القائمة على الهاش الخالصة؛ يمكن أيضًا اعتماد نشر هجين، مما يسمح لنظامي التوقيع بتكملة بعضهما البعض.