الخلاصة

  • تتيح المراجعة 12 من مسودة BBS للحامل أن يثبت معرفته بتوقيع واحد يغطي رسائل متعددة، مع كشف الرسائل التي يختارها فقط. خاصية عدم الربط تخص قيمة البرهان العشوائية؛ أما header وpresentation_header والقيم المكشوفة وعدد الرسائل وفهارسها ومفتاح الموقّع وعنوان الشبكة وبيانات التطبيق فتبقى أسطحاً محتملة للربط.
  • لذلك فإن نجاح ProofVerify إيصال تشفيري محدود. لا يثبت وحده هوية إنسان، أو تدقيق جهة الإصدار، أو الحالة الحالية والإلغاء، أو اكتمال العرض، أو التفويض، أو عدم الربط من طرف إلى طرف، أو النتيجة التشغيلية.

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

هذا ليس تناقضاً في التشفير، بل اختلاف في الشيء الذي قيس. يبرز draft-irtf-cfrg-bbs-signatures-12 لأنه يصف بدقة توقيعاً متعدد الرسائل وبرهان معرفة عديم المعرفة، ثم يصرّح بأن ضمان عدم الربط لا يمتد تلقائياً إلى كل ما يرافق البرهان. هذه الجملة المقيدة جزء من المنتج، لا هامش قانوني.

جعلت المراجعة 12 الاختبار قابلاً للتكرار، لا النشر خاصاً تلقائياً

رُفعت المراجعة 12 في 28 سبتمبر 2026 بوصفها Internet-Draft نشطة ضمن CFRG في مسار IRTF وبحالة مستهدفة Informational. ليست RFC نهائية، ولا معيار Standards Track، ولا دليلاً على تطبيق أو تشغيل أو توافق منتج مسمى.

الفرق الظاهر عن المراجعة 11 هو استبدال مواضع القوالب بثوابت حقيقية للحزم التشفيرية، وقيم scalar، ومولدات، وتواقيع، وfixtures للبراهين. يستطيع المطور تشغيل مدخلات ثابتة ومقارنة الناتج بايتاً ببايت. وهذا دليل مهم على الرياضيات والتسلسل والواجهة.

لكن fixture تعطي المفتاح والرسائل والرؤوس والعشوائية الوهمية سلفاً. أما بيئة الإنتاج فعليها أن تجيب: من نشر المفتاح؟ هل رأى الجميع key view واحدة؟ كم شخصاً يتشارك الرأس؟ هل كرر RNG حالته بعد fork أو snapshot؟ وما المعرّفات التي أضافتها المحفظة والنقل وVerifier؟ لا يرى متجه الاختبار أي قرار من هذه القرارات.

يجب أن يفصل ملف الإصدار بين سطرين. الأول يثبت أن هذا build يطابق مخرجات المراجعة 12. والثاني يثبت توزيع المفاتيح، وحجم مجموعات إخفاء الهوية، وقيم الرؤوس، وصحة العشوائية، وتقليل البيانات الوصفية، واختبارات الربط. لا ينوب الأول عن الثاني.

ضع نقطة عند نهاية ما تعنيه VALID

توقّع BBS قائمة مرتبة من الرسائل بتوقيع ثابت الحجم. ثم ينشئ Holder برهان معرفة عشوائياً ويكشف مجموعة فرعية يختارها. يأخذ Verifier المفتاح العام، والبرهان، وheader المرتبط بالتوقيع، وpresentation_header المرتبط بالعرض، والرسائل المكشوفة وفهارسها الأصلية.

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

لا تحدد النتيجة الشخص الذي شغّل البرنامج، ولا طريقة تحقق Issuer من الواقع، ولا تبحث تلقائياً في سجل إلغاء، ولا تثبت أن الحامل لم يحجب معلومة لازمة، ولا تطبق سياسة الدخول المحلية، ولا تشاهد ما حدث بعد القرار.

المقال القائم عن RFC 9901 يحتفظ بحدود SD-JWT بين الإفصاح الصحيح والسجل الكامل. أما هذه المقالة فتمتلك فرقاً آخر: يمكن أن تكون قيمة proof غير قابلة للربط تماماً بينما يبقى عرضها الخارجي بصمة ثابتة.

قد يتحول header الذي يختاره الموقّع إلى اسم دائم

تعرّف المسودة رأسين بمالكَين وعمرَين مختلفَين. يختار Signer قيمة header، وتُربط بالتوقيع الأصلي وبكل برهان مشتق منه، ويجب كشفها لكل Verifier. تصلح لسياق مشترك مثل معرّف تطبيق أو نطاق تشغيل أو إصدار منخفض الكاردينالية، لكنها خطرة إذا خصت شخصاً.

إذا وضع المصدر رقم اعتماد عشوائياً، أو بريداً، أو معرّف جهاز، أو وقت انتهاء دقيقاً، فسيتكرر في كل عرض. لن تمنع عشوائية proof الربط عبر هذا المفتاح الأسهل. لذلك تطلب المسودة رأساً منخفض الانتروبيا تتشاركه مجموعة كبيرة.

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

يجب أن يحتفظ Issuer بالبايتات الدقيقة، وقاعدة التوليد، والحجم المتوقع والفعلي للمجموعة، والمفتاح المقترن، والاستثناءات. لا يستطيع Holder تغيير رأس مرتبط بتوقيع صدر فعلاً. من يملك قرار الحقل يملك مخاطرَه أيضاً.

يربط presentation header التحدي ولا يصنع سياقه

يختار Prover قيمة presentation_header لبرهان واحد. يمكن أن تحمل nonce من Verifier، أو audience، أو domain، أو مدة صلاحية، أو رسالة يوقعها Prover. يثبت البرهان الصالح سلامة القيمة وارتباطها به.

لكن الحداثة حالة خارجية. يجب أن يعرف Verifier من ولّد nonce، ولأي جلسة وجمهور، ومتى ينتهي، وهل استُهلك. وفي النمط غير التفاعلي يلزم قانون آخر للفرادة. قد تكون السلسلة جديدة تماماً لكنها مرتبطة بالمعاملة الخطأ.

القيمة عالية الانتروبيا مناسبة إذا كانت جديدة لكل proof ولا تحمل هوية. إعادة استخدامها تخلق مقبضاً ثابتاً. إدخال رقم حساب، أو موقع دقيق، أو build نادر قد يعرّف الحامل من مرة واحدة. حماية سلامة الحقل لا تعني أن محتواه يحفظ الخصوصية.

يحتاج السجل إلى مصدر nonce والجلسة والجمهور ووقت الإنشاء والانتهاء والاستهلاك، مع مدة احتفاظ محدودة. حفظ عبارة «nonce صالح» وحدها يمنع إعادة بناء القرار، وحفظ كل التحديات إلى الأبد ينشئ قاعدة تتبع جديدة.

شكل البيانات المخفية يظل معلومة

يسمح طول proof وعدد القيم المكشوفة باستنتاج العدد الكلي للرسائل، وتكشف الفهارس مواضعها في schema. خمس خانات للموظفين، وتسع للمتعاقدين، وثلاث عشرة لبرنامج محمي تكفي لتصنيف الحامل من دون فك قيمة واحدة.

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

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

يمكن للمفتاح العام تقسيم السكان قبل إنشاء البرهان

يُتحقق من كل proof تحت مفتاح Signer. فإذا خُصص مفتاح لشخص أو مجموعة صغيرة، أشار كل عرض إلى تلك المجموعة حتى لو تعذر ربط قيم البراهين بعضها ببعض.

قد يحدث ذلك بلا قصد بسبب دورات إقليمية غير متزامنة، أو canary، أو عزل حادث، أو هرم مفاتيح موروث. وقد يكون خبيثاً إذا أظهر Issuer key view مختلفة لحامليْن مختارين فصارت علامة صامتة.

الإيصال ليس «المفتاح صالح». بل يتضمن بايتات المفتاح ومعرّفه ومسار النشر والتفعيل والسحب والسكان المقصودين والفعليين ودليل اتساق. تقدم آليات key consistency اتجاهاً، لكن الواجب هو منع التجزئة الانتقائية للرؤية.

مفتاح عالمي يوسّع مجموعة إخفاء الهوية ويوسّع أثر الاختراق. هرم مفاتيح يحسن العزل التشغيلي ويصغر المجموعات. لا توجد طوبولوجيا مثالية؛ يجب تسمية السكان المحميين وقياسهم بعد كل دورة.

قد تكون الحقيقة المكشوفة أقوى معرّف

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

تثبت BBS أصالة القيمة، لا ضرورة طلبها. الغرض والتناسب والاحتفاظ والبدائل قرارات تطبيقية. من يطلب تاريخ الميلاد كله عندما تكفي أهلية «فوق الثامنة عشرة» يهدر فائدة الخصوصية من دون أن يخالف الخوارزمية.

يمكن لبراهين المدى أو العضوية أن تقلل الكشف، لكنها تركيبات إضافية. لا تحول BBS الأساسية العمر تلقائياً إلى عتبة، ولا تثبت عدم الإلغاء لأن معرّف الإلغاء ظل مخفياً.

العشوائية مادة من مواد السرية

تحتاج ProofGen إلى عدة قيم عشوائية مستقلة وفريدة ومتقاربة من التوزيع المتجانس لكل نداء. إعادة الاستخدام أو التنبؤ أو العلاقات المعروفة قد تكشف الرسائل أو التوقيع المخفي. وقد يبقى proof صحيح البنية بعد انهيار الخصوصية.

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

تحدد أدلة الإنتاج نوع RNG وbuild المكتبة ومسار seed واختبارات الصحة وحدود العملية والجهاز وfork وsnapshot وطريقة الفشل. عبارة «يستخدم RNG النظام» تصميم وليست إيصال تشغيل.

وتظل مراجعة المفتاح وsubgroup checks وdomain separation ومقاومة side channel واتساق تحويل الرسائل ضوابط منفصلة. نجاح fixtures لا يثبتها بالاستنتاج.

لا تستعر خصائص المسودات المجاورة

Blind BBS Signatures بروتوكول منفصل يتيح لـSigner توقيع رسائل Holder مخفية في commitment. الإفصاح الانتقائي في BBS الأساسية يخفي عن Verifier وقت العرض؛ ولا يثبت أن Issuer لم ير القيم عند الإصدار.

BBS per Verifier Linkability تضيف pseudonym مرتبطاً بالسياق، فيتعرف Verifier إلى العودة داخل سياقه مع السعي إلى عدم الربط بين السياقات. لا تنتج BBS الأساسية هذا الاسم المستعار المستقر وحدها.

أما W3C bbs-2023 فهو profile لـVerifiable Credentials يحدد mandatory/selective pointers وتحويل البيانات وخيارات holder binding أو pseudonym. يجب أن تفصل المشتريات بين revision وciphersuite والواجهة والامتداد والprofile. عبارة «يدعم BBS» غير كافية.

يفصل الخطر الكمي الأصالة عن الإخفاء

تعتمد أصالة BBS على صعوبة اللوغاريتم المتقطع وليست post-quantum. يستطيع حاسوب كمي ذي صلة استخراج سر Signer، وصنع تواقيع على رسائل مختارة، وإنشاء proofs صحيحة منها.

تفصل المسودة سرية البراهين الموجودة: إخفاء الرسائل غير المكشوفة والتوقيع ذو طبيعة معلوماتية، فلا تستخرجها قدرة حسابية غير محدودة حتى مع سر Signer. هذه everlasting privacy للـproof، وليست علامة quantum safe للنظام كله.

تحتاج الهجرة إلى ساعتين. يجب استبدال الأصالة قبل أن يصل الخطر إلى عمر القرار. قد تستمر النصوص القديمة في الإخفاء، بينما تبقى الرؤوس والقيم المكشوفة وIP والسجلات قابلة للربط. تدوير المفتاح لا يمحو النسخ.

يجب أن يغطي الإيصال التفاعل كله

تفصل السلسلة الدنيا: نسخة الوثيقة وciphersuite؛ مصدر المفتاح واتساق الرؤية؛ إصدار blind أو عادي؛ header وحجم المجموعة؛ schema والترتيب وpadding؛ القيم والفهارس؛ presentation header وnonce والجمهور والحداثة؛ proof والنتيجة؛ RNG؛ parser وsubgroup وdomain separation؛ بيانات الشبكة والجهاز؛ الحالة أو الإلغاء؛ policy؛ التفويض؛ الفعل؛ الأثر؛ الاحتفاظ؛ الهجرة.

لا يلزم مركز واحد. يحتفظ Issuer والمحفظة وVerifier والتطبيق والأمن والخصوصية بالقرار الذي يملكونه، ويربطونه بهوية معاملة محدودة. مبدأ Lu Heng للمواصفة الأولية الدنيا يبقي الطبقة المشتركة صغيرة. انضباط طبقات الواقع يمنع zero knowledge من استعارة سلطة التفويض. وتسأل أولوية الكود العامل أي مفتاح وschema وRNG وbinary ومسار سجل عمل فعلاً.

BBS لا تقدم وعداً ضعيفاً؛ بل وعداً قوياً على شيء محدد. يبدأ الخطر عندما تضيف المؤسسة عبارة «النظام كله» من دون أدلة جديدة.

المصادر