مكتبة Voron للتشفير/البروتوكول — طلب مراجعة

هذا هو جوهر التشفير وبروتوكول التراسل لمشروع مراسلة صغير بتشفير E2EE، عُزل وحده للمراجعة الخارجية. وهو ليس المنتج كاملاً — تم استبعاد عميل Android وإعدادات النشر عمداً؛ هذا فقط الجزء الذي يحتاج إلى تدقيق.

ما يوجد هنا

• common/ — المكتبة نفسها:
  • e2ee/ — X3DH-lite (اتفاق مفاتيح غير متزامن) مع Double Ratchet في الأعلى، مبني على Curve25519/ChaCha20-Poly1305/Ed25519/HKDF (بدائيات مقدمة من JDK، لا شيء مكتوب يدوياً في تلك الطبقة).
  • crypto/ — أغلفة رقيقة فوق بدائيات JDK تلك.
  • group/ — تراسل جماعي عبر مخطط sender-keys (النهج السابق لـ MLS الذي استخدمته مجموعات WhatsApp/Signal المبكرة)، بالإضافة إلى سجل أحداث بتسلسل تجزئة موقّع من جهة العميل للعضوية والأدوار، نظراً لأن المرحّل لا يملك أي مفهوم للمجموعات إطلاقاً.
  • onion/ — ناقل تشفير طبقي اختياري (عدد قفزات ثابت، حشو بحاويات ذات حجم ثابت) لمنع المرحّل من الربط المباشر بين عنوان IP الخاص بالاتصال ومفتاح هويته.
  • client/ وtransport/ وbackup/ — بروتوكول الاتصال (wire protocol)، ومصافحة ناقل Noise_IK، وتنسيق نسخ احتياطي مشفّر.
• server/ — تنفيذ مرحّل مرجعي: توجيه بالتخزين ثم الإرسال (store-and-forward)، ودليل مفاتيح prekey، وصندوق بريد دون اتصال، ودور قفزة البصل. مصمم عمداً على الحد الأدنى من الثقة: المرحّل لا يرى النص الصريح أبداً، ولا يحتفظ برسالة أطول من وقت تسليمها، و(بالتصميم) ليس لديه أي إدراك لعضوية المجموعات.
• client/ — أداة اختبار بسيطة على وحدة تحكم JVM (ليست تطبيقاً حقيقياً) تُستخدم لدفع common وserver ضد بعضهما في اختبارات التكامل، بالإضافة إلى عدد قليل من PoCs مستقلة للاستغلال (انظر أدناه).
• security-audit/ — تقارير من جولات المراجعة الداخلية السابقة، والأخطاء التي عثرت عليها، وتلك التي تم إصلاحها بالفعل. اقرأ هذا قبل الإبلاغ عن شيء — فهناك احتمال حقيقي أن يكون موجوداً هنا بالفعل. REPORT.md هو التقرير الرئيسي؛ وADVERSARIAL_REVIEW_PAVEL.md هو جولة لاحقة وأضيق نطاقاً؛ ويحتوي fuzz/ وclient/.../exploit/ على PoCs قابلة للتشغيل، وليست مجرد أوصاف.

نموذج التهديد، باختصار

• المرحّل ليس طرفاً موثوقاً. فهو يوجّه النص المشفّر وبيانات الدليل (مفاتيح prekey المنشورة)، ويُفترض أن يكون خبيثاً بنشاط، وليس مجرد فضولي — فالعديد من الأخطاء المُصلحة في security-audit/ هي بالضبط "ماذا يمكن أن يفعل مرحّل عدائي؟".
• تهدف الجلسات الفردية 1:1 إلى السرية الأمامية (X3DH) والأمن بعد الاختراق (عبر DH-ratchet في الأعلى). الجلسات الجماعية تعتمد مخطط sender-keys: تغيير العضوية يعيد توليد مفاتيح المجموعة بأكملها، لكن اختراق مفتاح مرسل واحد يكشف رسائل تلك الحقبة — فلا يوجد ratchet لكل رسالة في الطبقة الجماعية (ليس MLS/TreeKEM كاملاً؛ وهو تقليص نطاق متعمد، موثق في group/GroupCryptoSession.kt).
• يخفي توجيه البصل الرابط بين IP↔الهوية عن مرحّل يرى قفزة واحدة فقط، ويحشو الإطارات إلى حاويات ذات حجم ثابت بحيث لا يؤدي الارتباط الحجمي السلبي عبر القفزات إلى كشف هوية الدائرة بسهولة. وهو لا يخفي الارتباط الزمني عن خصم يراقب الطرفين في الوقت نفسه — فهذا يتطلب حركة تغطية أو خلطاً (mixing)، وهذا غير منفّذ. هذا موضّح صراحةً في security-audit/REPORT.md وADVERSARIAL_REVIEW_PAVEL.md، وليس شيئاً يتم إخفاؤه.

ما نريد فحصه تحديداً

• تكامل X3DH-lite ↔ Double Ratchet (common/src/main/kotlin/messenger/common/e2ee/) — هذا هو البناء التشفيري الوحيد المصمم خصيصاً هنا، وكل ما تحته مكوّنات جاهزة (off-the-shelf). تمت مراجعته داخلياً عدة مرات (انظر security-audit/) لكن لم تتم مراجعته من قبل أي شخص خارج هذا المشروع.
• نموذج التفويض في سجل التحكم الجماعي (common/src/main/kotlin/messenger/common/group/GroupControlLog.kt) — وهو تسلسل تجزئة موقّع من جهة العميل دون أي تطبيق من الخادم إطلاقاً.
• أي شيء في طبقة توجيه البصل غير مغطى بالفعل بالملاحظة التحذيرية الموثقة أعلاه بشأن الارتباط الزمني.

تشغيله

./gradlew test

مشروع Gradle/Kotlin قياسي، يتطلب JDK 17+. لا حاجة لوصول إلى الشبكة أو خدمات قيد التشغيل لمجموعة اختبارات مستوى الوحدة. يحتوي security-audit/README.md على تعليمات لـ PoCs الخاصة بالفحص الحي للمرحّل (relay-fuzzing) وارتباط البصل، والتي تتطلب تشغيل عمليات محلية (لا توجّه أي جزء منها أبداً نحو مضيف إنتاج).

ما ليس هذا

لم يتم إجراء أي تدقيق تشفيري مستقل على هذا. كل ما في security-audit/ هو مراجعة هندسية داخلية — دقيقة، لكنها مراجعة ذاتية، دون سند من براهين رسمية ودون سجل مهني/مؤسسي خلفها. تعامل معها كنقطة انطلاق للمراجعة، وليس كشهادة اعتماد.