الحلول الثلاثة المفضلة لدى a16z لحل المشكلات الأساسية لتشفير المفتاح العام

المصدر: Noemi Glaeser, a16z crypto

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

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

بالنسبة للمشاكل المذكورة أعلاه، توجد حاليًا ثلاثة حلول: دليل المفاتيح العامة، والتشفير القائم على الهوية (IBE)، والتشفير القائم على التسجيل (RBE). تتمتع كل طريقة من هذه الطرق الثلاث بمزاياها الخاصة في عدم الكشف عن الهوية والتفاعل والكفاءة. على سبيل المثال، يتطلب IBE أساسًا قويًا من الثقة، ولكن في بعض الحالات، يكون أداء IBE أفضل من حيث عدم الكشف عن هويته والكفاءة. تهدف هذه المقالة إلى استكشاف تطبيق هذه الطرق الثلاثة على blockchain ومقارنة مزاياها وعيوبها.

ثلاث طرق

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

ومع ذلك، في بيئة Web2، تتطلب صيانة دليل المفتاح العام هذا تكاليف عالية وعمليات مرهقة. بالإضافة إلى ذلك، يتعرض المستخدمون لخطر إساءة الاستخدام المحتملة من قبل سلطات التصديق.

بعض البدائل المقترحة من قبل خبراء التشفير لحل مشاكل البنية التحتية للمفتاح العام (PKI). في عام 1984، اقترح عدي شامير التشفير القائم على الهوية (IBE)، حيث يمكن استخدام هوية الطرف (مثل رقم الهاتف أو البريد الإلكتروني أو اسم مجال ENS) مباشرة كمفتاح عام. يلغي هذا الأسلوب الحاجة إلى الاحتفاظ بدليل المفتاح العام، ولكنه يقدم مشكلة جديدة: الاضطرار إلى الاعتماد على طرف ثالث موثوق به (مولد المفتاح) لإنشاء المفتاح الخاص.

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

ومع ذلك، كما سيتم مناقشته لاحقًا في هذه المقالة، يمكن حل مشكلة الثقة هذه من خلال الاعتماد على طرف موثوق به (أي نصاب مجموعة من المشاركين) الحل، ويمكن لتقنية blockchain تحقيق ذلك بسهولة.

المزايا والعيوب

هناك العديد من الاعتبارات المختلفة التي يجب مراعاتها عند مقارنة عوامل أنظمة التشفير هذه ، أقوم بافتراضين حول هذا:

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

لا تستخدم العقود الذكية أي خدمة توفر بيانات خارج السلسلة (DAS) أو بيانات كبيرة: أي على افتراض أن العقد الذكي يعتمد بالكامل على السلسلة البيانات، لا تتضمن خدمات بيانات خارج السلسلة أو تخزين بيانات إضافي.

دليل المفاتيح العامة

يمكن لأي شخص نقل معرف لا يشغله الآخرون عن طريق الاتصال بالعقد الذكي، وهو (id , pk) تتم إضافة الإدخال إلى الدليل الموجود على السلسلة.

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

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

دعونا نلقي نظرة على مزايا وعيوب هذه الطريقة:

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

التشفير القائم على الهوية (IBE)

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

في نظام IBE، لا يقوم المستخدمون بإنشاء زوج من المفاتيح العامة والخاصة بأنفسهم كما هو الحال في أنظمة التشفير التقليدية. وبدلاً من ذلك، يحتاج المستخدمون إلى التسجيل لدى منشئ مفاتيح موثوق به. يحمل مولد المفاتيح زوجًا من المفاتيح الرئيسية (بما في ذلك المفتاح الرئيسي الخاص msk والمفتاح العام الرئيسي mpk). عندما يقدم المستخدم معرفه، يستخدم منشئ المفتاح المفتاح الخاص الرئيسي msk ومعرف المستخدم لحساب مفتاح خاص فريد لذلك المستخدم. يجب تسليم المفتاح الخاص الذي تم إنشاؤه إلى المستخدم من خلال قناة آمنة. وبشكل عام، يتم استخدام بروتوكول تبادل المفاتيح لإنشاء هذه القناة الآمنة.

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

يجب الاحتفاظ بالمفتاح الخاص الرئيسي لمولد المفاتيح (msk) لفترة طويلة لأنه يحتاج إلى إنشاء مفاتيح خاصة جديدة للمستخدم بشكل مستمر أثناء تشغيل النظام. وهذا يختلف عن بعض أنظمة SNARK، التي يتم إنشاؤها أثناء الإعداد الموثوق به ولكن يمكن تدميرها بعد اكتمال الإعداد. في نظام IBE، لا يمكن حذف المفتاح الخاص الرئيسي بعد التهيئة كما هو الحال في SNARK.

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

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

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

التشفير القائم على التسجيل (RBE)

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

سأناقش طريقة فعالة لبناء RBE في هذا القسم، لأنه على حد علمي يتمتع هذا بميزة كبيرة مقارنة بإنشاءات RBE العملية الأخرى، ويمكن أن يكون تم نشرها على blockchain لأنها تعتمد على الاقتران وليس على الشبكة.

في نظام RBE، يقوم كل مستخدم بإنشاء زوج من المفاتيح (بما في ذلك المفتاح العام والمفتاح الخاص). يحتاج المستخدمون أيضًا إلى حساب بعض قيم التحديث (التي تم وضع علامة عليها في الرسم التخطيطي) بناءً على مفتاحهم الخاص والسلسلة المرجعية المشتركة (CRS). يتم استخدام هذه القيم المحدثة لمزيد من العمليات في النظام. إن وجود سلسلة مرجعية مشتركة (CRS) يعني أن النظام لم يتم إعداده بالكامل بدون ثقة. ومع ذلك، تستخدم عملية توليد CRS طريقة بناء تسمى قوة تاو. يمكن إكمال طريقة البناء هذه من خلال الحسابات التعاونية التي يجريها العديد من المشاركين في السلسلة. وطالما أن مشاركًا واحدًا على الأقل صادق، فإن خدمة CRS هذه آمنة.

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

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

في هذا النظام، يحتاج المرسل فقط إلى القيام بأمرين:

تنزيل المرجع العام السلسلة (CRS): يجب تنزيلها مرة واحدة فقط ولا يلزم تحديثها بعد ذلك.

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

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

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

من الواضح أن هذا الحل أكثر تعقيدًا من الحلين الآخرين. ولكنه يتطلب تخزينًا أقل على السلسلة من دليل المفتاح العام ويتجنب افتراض الثقة القوية لـ IBE.

معلمات موجزة:

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

التشفير مع تفاعل معين:

• < p style="text-align: left;">عند إرسال رسالة، يطلب المرسل نسخة من المعلمات العامة التي تحتوي على المستلم المقصود. وهذا يعني أن المرسل يحتاج إلى تحديث هذه المعلمات في مرحلة ما بعد تسجيل المستلم، لكنه لا يحتاج إلى تحديثها بشكل فردي لكل مستلم، حيث أن التحديث الواحد قد يحتوي على مفاتيح لعدة مستلمين. وبشكل عام، يعد إرسال الرسائل أكثر تفاعلية من IBE، ولكنه أقل من استخدام دليل المفتاح العام.

فك التشفير بتفاعل معين:

• < p style="text-align: left;">كما هو الحال مع التشفير، يحتاج المستلم إلى معلومات مساعدة تطابق إصدار المعلمات العامة المستخدمة في التشفير. عندما يقوم مستخدم جديد بالتسجيل في مجموعة معينة، يتم تحديث المعلمات العامة والمعلومات المساعدة، وتتوافق القيمة التي يمكنها فك تشفير النص المشفر مع إصدار المعلمات العامة المستخدمة أثناء التشفير. يمكن للمستخدمين اختيار الحصول على تحديثات المعلومات المساعدة بشكل دوري وليس على الفور في كل مرة ما لم يفشل فك التشفير. على عكس تحديثات المعلمات العامة، فإن الحصول على تحديثات المعلومات المساعدة بشكل متكرر لا يكشف عن معلومات خاصة.

المرسل مجهول:

• كما هو الحال مع أدلة المفاتيح العامة، يمكن للمرسل تشفير الرسالة بشكل مستقل (طالما أنها تحتوي على أحدث المعلمات) دون الحاجة إلى الاستعلام عن معلومات محددة حول المستلم. عندما يحتاج المرسل إلى قراءة المعلومات من السلسلة، تكون المعلومات غير ذات صلة بالمستلم المقصود (ما لم يطلب المرسل فقط مجموعة نقاط معلمة محددة، مما قد يؤدي إلى تسرب بعض المعلومات).

الشفافية:

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

مجموعة المعرفات المقيدة:

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

مستلم مجهول:

• < p style ="text-align: left;">تمنع هذه الطريقة النص المشفر من الكشف عن هوية المستلم.