--- dir: rtl lang: ar title: "التشفير المتجانس: من الجزئي إلى الكامل (PHE → SHE → FHE) وكيف حلّ جنتري معضلة الضجيج" date: 2025-12-27 tags: [Cryptography, FHE, Lattices, Algebraic Number Theory, Post-Quantum] --- <style> body { direction: rtl; text-align: right; } </style> <div dir="rtl" lang="ar"> # التشفير المتجانس (Homomorphic Encryption): الحساب على بيانات لا تُرى الفكرة التي تبدو “سحرًا” في التشفير المتجانس (Homomorphic Encryption – HE) هي في الواقع **رياضيات قاسية**: تُشفّر بياناتك (Encrypted Data / Ciphertext)، ثم يُجري طرفٌ غير موثوق (Server / Cloud) عمليات حسابية عليها **وهي ما تزال مشفّرة**، ثم تفك أنت فقط التشفير (Decryption) فتجد أن النتيجة مطابقة تمامًا لما لو أجريت الحساب على البيانات الأصلية (Plaintext). النتيجة: **حوسبة دون كشف** (Computation without Disclosure). وهذا بالضبط ما تحتاجه الحوسبة السحابية (Cloud Computing)، البيانات الطبية والمالية الحساسة، وأجزاء من الذكاء الاصطناعي (AI/ML) عندما تكون الخصوصية خطًا أحمر. --- ## صورة سريعة للفكرة (Conceptual Setup) > (الصورة التالية مرخّصة CC0 من ويكيميديا كومنز) ![Homomorphic Encryption Setup (CC0)](https://upload.wikimedia.org/wikipedia/commons/2/2c/Homomorphic_Encryption_Setup.jpg) **المعنى**: - المستخدم يرسل قيَمًا مشفّرة. - الخادم يحسب على المشفّر. - المستخدم يسترجع ناتجًا مشفّرًا ويفك تشفيره فقط. --- ## التعريف الرسمي (مع قليل من LaTeX للتدقيق) لنفترض لدينا: - دالة تشفير `Enc(·)` (Encryption) - دالة فك تشفير `Dec(·)` (Decryption) - وخوارزمية تقييم/حساب على النص المشفّر `Eval(·)` (Evaluation) الخاصية المتجانسة تعني – بصيغة مثالية – أن: ```latex Dec\big(Eval(f, Enc(m))\big) = f(m). ```` أي أن “فك تشفير ناتج الحساب على المشفّر” يساوي “ناتج الحساب على الصريح”. --- # قبل الوصول إلى FHE: لماذا لم يكن الأمر سهلًا؟ ## 1) التشفير المتجانس الجزئي (Partially Homomorphic Encryption – PHE) هذا هو الجيل الأبسط: يدعم **نوعًا واحدًا فقط** من العمليات: * إما جمع (Addition) * أو ضرب (Multiplication) لكن ليس كليهما معًا بمرونة كاملة. **أمثلة شهيرة (كمفهوم)**: * RSA غير المبطّن يدعم ضربًا متجانسًا بشكل طبيعي (Multiplicative Homomorphism). * Paillier يدعم جمعًا متجانسًا (Additive Homomorphism). وهنا جوهر القيد: معظم الخوارزميات الواقعية (وخاصة تعلم الآلة) تحتاج **جمعًا وضربًا معًا** وبشكل متكرر، لذا PHE مفيد لكنه غير كافٍ لبناء “حاسوب عام على بيانات مشفّرة”. --- ## 2) التشفير المتجانس المحدود (Somewhat Homomorphic Encryption – SHE) جاءت الخطوة التالية: أن ندعم الجمع والضرب معًا، لكن **إلى حد معيّن فقط**. السبب ليس مزاج المصمّم… بل “وحش” اسمه: ### الضجيج (Noise) — سلاح الأمان الذي يتحول إلى لعنة في معظم مخططات HE الحديثة، كل نصّ مشفّر يحمل معه **ضجيجًا رياضيًا** صغيرًا مقصودًا: * الضجيج ضروري للسرية (Security). * لكنه **يتراكم** أثناء الحساب. قاعدة عملية شائعة: * الجمع يزيد الضجيج قليلًا. * الضرب يرفع الضجيج بقفزة كبيرة. عندما يتجاوز الضجيج حدًا معيّنًا (Noise Threshold)، يصبح فك التشفير غير مضمون: النتيجة تنهار أو تصبح عشوائية. --- ## 3) مفهوم مهم: عمق الضرب (Multiplicative Depth) ليس عدد العمليات هو ما يقتل الأداء فقط، بل **عدد طبقات الضرب المتسلسلة** داخل الدائرة الحسابية (Circuit). لهذا السبب تسمع غالبًا أن HE “يكره الضرب” أكثر مما يكره الجمع. --- # المعضلة التاريخية قبل جنتري: كيف نحصل على FHE؟ المعضلة كانت واضحة ومزعجة: 1. نحتاج ضجيجًا لتحقيق الأمن. 2. لكن الضجيج ينفجر مع الضرب المتكرر. 3. إذن: كيف ننفّذ حسابات غير محدودة (Unbounded Computation) دون أن يقتل الضجيج فك التشفير؟ طوال عقود، كانت النتيجة العملية: * **PHE**: جيد لعملية واحدة (جمع أو ضرب). * **SHE**: جيد لعدد محدود من العمليات/عمق محدود. * **FHE**: فكرة مرغوبة لكنها “غير عملية/غير معروفة الطريق”. --- # حلّ جنتري (Craig Gentry) سنة 2009: فتح الباب نحو FHE في 2009 قدّم كريغ جنتري أول بناء مقنع لـ **التشفير المتجانس الكامل** (Fully Homomorphic Encryption – FHE) مبنيًا على تشفير قائم على الشبكيات (Lattice-based). الفكرة الجوهرية التي قلبت الطاولة اسمها: ## Bootstrapping (إعادة التهيئة/إعادة الإقلاع) بدل أن نترك الضجيج يتراكم حتى يقتل النص المشفّر، نقوم بعملية “تجديد” (Noise Refreshing): * نأخذ نصًا مشفّرًا ضجيجه مرتفع. * نجري عليه عملية داخل النظام تقلل الضجيج دون كشف الرسالة. * فيعود النص صالحًا لمزيد من الحساب. الفكرة العميقة هنا: أن يكون النظام قادرًا على **تقييم دالة فك التشفير الخاصة به** على نحوٍ مشفّر، أي “يشغّل نفسه على نفسه” بشكل مضبوط. عندها تصبح الحسابات قابلة للتمديد نظريًا بلا حد (Unbounded Depth). > ملحوظة مهمة: كثير من المكتبات اليوم تستخدم “FHE بمستوى محدد” (Leveled FHE) بدون bootstrapping دائمًا، لأن bootstrapping مكلف—لكن وجوده هو الذي يعطيك مبدئيًا FHE الحقيقي. --- # لماذا الرياضيات هنا ليست زينة؟ (الدور الحاسم للأعداد الجبرية والشبكيات) هذه النقطة هي لبّ الموضوع: **FHE لا يعيش على الأفكار البرمجية وحدها**، بل على بنية رياضية عميقة. ## أولًا: نظرية الأعداد الجبرية (Algebraic Number Theory) معظم مخططات FHE العملية الحديثة تعمل في حلقات كثيرات حدود (Polynomial Rings) بدل الأعداد الصحيحة فقط. الشكل الشائع هو العمل في فضاء من نوع: $$R_q = \mathbb{Z}_q[x]/(f(x))$$ حيث: * `q` عدد كبير (Modulus) * و `f(x)` كثير حدود خاص، وغالبًا يُختار ليعطي بنية دورانية/سيكلوتومية (Cyclotomic Structure) لماذا هذا الاختيار مهم؟ * يسمح بحسابات جمع وضرب أسرع على “كتل” من البيانات. * يعطي انتظامًا بنيويًا يمكن استغلاله للتسريع. * يقلّل أحجام المفاتيح والتمثيلات مقارنة ببعض البدائل. بعبارة مباشرة: **الأعداد الجبرية هنا هي ما يجعل الأداء “قابلًا للتفاوض”، لا مجرد نظري.** --- ## ثانيًا: نظرية الشبكيات (Lattice Theory) — أساس الأمن الأمن في كثير من مخططات FHE الحديثة يرتبط بمسائل من نوع: * LWE (Learning With Errors) * RLWE (Ring Learning With Errors) الصيغة المبسطة (للتقريب الذهني) لفكرة LWE/RLWE هي وجود علاقة من نمط: ```latex b \approx a \cdot s + e \pmod q ``` حيث: * `s` هو السر (Secret) * `e` ضجيج صغير (Error/Noise) * والمهاجم يرى `a` و `b` لكنه لا يستطيع استخراج `s` لأن الضجيج يربك المعادلة. السبب في قوة هذا النموذج هو أن محاولة “إزالة الضجيج” تقود إلى مشاكل هندسية صعبة داخل الشبكيات، مثل: * مشكلة أقصر متجه (Shortest Vector Problem – SVP) * مشكلة أقرب متجه (Closest Vector Problem – CVP) وهذه المسائل تقع في فضاءات عالية الأبعاد (High-Dimensional Geometry)، ويُعتقد أنها صعبة حتى أمام الحواسيب الكمية (Quantum Computers). لذلك تُصنّف هذه العائلة ضمن **تشفير ما بعد الكم** (Post-Quantum Cryptography). --- ## صورة توضيحية مفيدة: اختزال الشبكة (Lattice Reduction) > (الصورة التالية في المجال العام Public Domain من ويكيميديا كومنز) ![Lattice Reduction (Public Domain)](https://upload.wikimedia.org/wikipedia/commons/thumb/2/27/Lattice-reduction.svg/960px-Lattice-reduction.svg.png) الفكرة: نفس الشبكة يمكن تمثيلها بقواعد مختلفة (Bases)، وبعض القواعد “أسهل” من غيرها—ومن هنا تأتي خوارزميات مثل LLL و BKZ في التشفير القائم على الشبكيات. --- # لماذا لا يزال FHE صعبًا عمليًا؟ (العوائق والمشاكل) لنكن صريحين: FHE ليس مجانيًا. ## 1) البطء (Performance Overhead) الحساب على نصوص مشفّرة أثقل بكثير من الحساب على بيانات صريحة: * عمليات أكثر تعقيدًا * معاملات أكبر * ومحددات صارمة على شكل الحساب (خصوصًا الضرب) ## 2) كلفة الذاكرة (Memory Overhead) النصوص المشفّرة عادة أكبر بكثير من البيانات الأصلية، خصوصًا مع: * تعبئة البيانات (Packing/SIMD) * أو معايير أمان أعلى * أو عمليات bootstrapping ## 3) صعوبة البرمجة (Programming Model Constraints) أشياء بديهية في البرمجة العادية تصبح مكلفة أو غير مباشرة هنا: * المقارنات (Comparisons) * الشروط (If/Else) * الفروع (Branching) لذلك تُحوّل كثير من الحسابات إلى دوائر (Circuits) أو كثيرات حدود (Polynomials)، وهذا يغيّر طريقة التفكير كليًا. ## 4) اختيار المعاملات (Parameter Selection) أي خطأ في المعاملات قد يعطي: * نظامًا بطيئًا جدًا * أو غير صحيح (يفشل فك التشفير) * أو (في أسوأ الأحوال) أضعف أمنيًا --- # أين يلمع FHE فعليًا؟ (Use Cases واقعية) يظهر FHE عندما تكون الخصوصية أهم من كل شيء: * تحليلات طبية حساسة (Healthcare Analytics) * بيانات مالية ومعاملات تحتاج سرية شديدة (Finance) * تعاون بين أطراف لا تثق ببعضها (Distrustful Parties) * استعلامات قواعد بيانات مشفّرة * تشغيل نماذج تعلم آلي على بيانات خاصة دون كشفها (Privacy-preserving ML inference) --- # المستقبل (Future Outlook): ماذا نتوقع بواقعية؟ ## ما لن يحدث قريبًا * FHE لن يصبح أسرع من الحساب التقليدي (Plain Computation) بشكل عام. * ولن يدخل “كل تطبيق يومي” دون تمييز. ## ما يُرجّح أن يحدث * تحسّن كبير في bootstrapping وطرق تقليل كلفته. * أدوات ومترجمات (Compilers) تنقل الخوارزميات تلقائيًا إلى شكل مناسب للحساب المشفّر. * حلول هجينة تجمع بين: * FHE * الحوسبة متعددة الأطراف (Multi-Party Computation – MPC) * العتاد الموثوق (Trusted Hardware / TEEs) للوصول إلى توازن عملي بين السرية والكلفة. الخلاصة المستقبلية: **FHE سيصبح “طبقة خصوصية معيارية” في القطاعات الحساسة، لا بديلًا شاملًا لكل الحوسبة.** --- # قاموس مصطلحات مختصر (Glossary) * التشفير المتجانس: Homomorphic Encryption (HE) * التشفير المتجانس الجزئي: Partially Homomorphic Encryption (PHE) * التشفير المتجانس المحدود: Somewhat Homomorphic Encryption (SHE) * التشفير المتجانس الكامل: Fully Homomorphic Encryption (FHE) * تشفير كامل بمستوى محدد: Leveled FHE * الضجيج/الخطأ: Noise / Error * إعادة التهيئة: Bootstrapping * نظرية الأعداد الجبرية: Algebraic Number Theory * نظرية الشبكيات: Lattice Theory * تعلّم مع وجود أخطاء: Learning With Errors (LWE) / Ring-LWE (RLWE) * أقصر/أقرب متجه: SVP / CVP * ما بعد الحوسبة الكمية: Post-Quantum Cryptography (PQC) --- # صور إضافية (اختيارية) عن “السيادة على البيانات” ودمج HE > (الصورة التالية مرخّصة CC0 من ويكيميديا كومنز) ![Hybrid homomorphic encryption diagram (CC0)](https://upload.wikimedia.org/wikipedia/commons/f/fe/Secured_video_conferencing_using_a_hybrid_of_two_homomorphic_encryption_schemes.png) --- # مراجع مقترحة للقراءة (Recommended Reading) * Craig Gentry (2009): "A Fully Homomorphic Encryption Scheme" (thesis). * Wikipedia: Homomorphic Encryption (overview + taxonomy + history). * Wikipedia: Lattice problem (SVP/CVP definitions and relations). * Hanrot, Stehlé et al.: "Algorithms for the Shortest and Closest Lattice Vector Problems" (survey PDF). --- </div> اعتمدتُ في **التقسيم الرسمي للأنواع (PHE/SHE/Leveled FHE/FHE)**، وشرح تراكم الضجيج وعمق الضرب، وملخص تاريخ “جنتري 2009 + bootstrapping” على صفحة *Homomorphic encryption* في ويكيبيديا. :contentReference[oaicite:0]{index=0} واعتمدتُ في **النقطة التاريخية** (أول بناء مقنع لـ FHE سنة 2009، وفكرة تقييم الدوائر على نصوص مشفّرة، وكون المسألة طُرحت منذ 1978) على أطروحة جنتري وملخص ورقته “Ideal Lattices”. :contentReference[oaicite:1]{index=1} وفي تعريفات **SVP/CVP** وعلاقتها بمشاكل الشبكيات استندتُ إلى تعريفات “Lattice problem” في ويكيبيديا وإلى مسح Hanrot/Stehlé. :contentReference[oaicite:2]{index=2} أما الصور الثلاث المدرجة فهي من ويكيميديا كومنز وبترخيص CC0 أو Public Domain كما هو مذكور في صفحات الملفات. :contentReference[oaicite:3]{index=3} ::contentReference[oaicite:4]{index=4}