23 مايو 2025·8 دقيقة
اختراق وايتفيلد ديفي في التشفير بالمفتاح العام للويب والهوية
كيف مكّن اختراق وايتفيلد ديفي للمفتاح العام HTTPS والرسائل الآمنة والهوية الرقمية — شرح بالأفكار الأساسية والتطبيقات الواقعية.
كيف مكّن اختراق وايتفيلد ديفي للمفتاح العام HTTPS والرسائل الآمنة والهوية الرقمية — شرح بالأفكار الأساسية والتطبيقات الواقعية.
في كل مرة تسجل دخولك إلى بنك، تشتري شيئًا عبر الإنترنت، أو ترسل رسالة خاصة، فأنت تعوّل على فكرة بسيطة: يمكنك مشاركة معلومات عبر شبكة يمكن للآخرين مراقبتها، ومع ذلك تحافظ على سرية الأجزاء المهمة.
هذا يبدو بديهيًا الآن، لكنه كان فوضى عملية سابقًا. إذا أراد شخصان استخدام التشفير، كان عليهما أولًا الاتفاق على مفتاح سري مشترك. وقد تطلّب ذلك غالبًا ساعي موثوق، لقاء مُنسّق مسبقًا، أو شبكة شركة آمنة — خيارات لا تتوسع لتخدم ملايين الغرباء على الإنترنت المفتوح.
التشفير بالمفتاح العام غيّر القواعد. قدم وسيلة لنشر مفتاح واحد علنًا (المفتاح العام) مع الاحتفاظ بمفتاح آخر سري (المفتاح الخاص). مع هذا الانقسام، يمكنك بدء علاقة آمنة دون مشاركة سر مسبقًا. كان لوايتفيلد ديفي دور مركزي في دفع هذا الاختراق إلى العلن وبيان سبب أهميته.
سنربط المفاهيم الأساسية بالأشياء التي تستخدمها فعلاً:
ستحصل على شروحات بسيطة باللغة العادية، مع الحد الأدنى من الحدس الرياضي لفهم لماذا تعمل الحيل — دون تحويلها إلى كتاب دراسي. الهدف أن يجعل التشفير بالمفتاح العام أقل سحرًا وأكثر أداة عملية تحمي الحياة اليومية بصمت.
قبل التشفير بالمفتاح العام، كانت الاتصالات الآمنة تعني غالبًا التشفير المتناظر: كلا الطرفين يستخدمان نفس المفتاح السري لقفل وفك رسائل.
فكر فيه كقفل و مفتاح مشترك. إذا كان لديك ولي نسخة من نفس المفتاح، أستطيع إغلاق صندوق، أرسله إليك، ويمكنك فتحه. القفل والفتح بسيطان — شرط أن يكون لدينا المفتاح مسبقًا.
العقبة واضحة: كيف نشارك المفتاح بأمان بالأساس؟ إذا بعثته عبر البريد الإلكتروني قد يعترضه أحدهم. نفس المشكلة مع الرسائل النصية. إذا وضعته في ظرف مختوم وأرسلته بالبريد، قد ينجح ذلك لمرة واحدة، لكنه بطيء ومكلف وغير مضمون.
هذا يخلق مشكلة دائرية:
التشفير المتناظر يعمل جيدًا عندما يكون هناك عدد قليل من الأشخاص وطريقة موثوقة لتبادل المفاتيح مسبقًا. لكن على الإنترنت المفتوح، ينهار بسرعة.
تخيل موقعًا يحتاج اتصالات خاصة مع ملايين الزوّار. مع المفاتيح المتناظرة فقط، سيحتاج الموقع إلى مفتاح سري مختلف لكل زائر، بالإضافة إلى طريقة آمنة لتسليم كل واحد. عدد المفاتيح واللوجستيات المرتبطة بها (الإنشاء، التخزين، التدوير، الإلغاء) تصبح عبئًا تشغيليًا ضخمًا.
هذا لا يعني أن التشفير المتناظر "سيئ". إنه ممتاز فيما يفعله: تشفير سريع وفعّال لكميات كبيرة من البيانات (مثل الغالبية العظمى مما يُرسل عبر HTTPS). التحدي قبل ديفي لم يكن السرعة — كان القطعة المفقودة: طريقة عملية ليتفق الغرباء على سر دون مشاركته مسبقًا.
في أوائل السبعينيات، كانت الاتصالات الآمنة تعني إلى حد كبير الأسرار المشتركة. إذا أراد شخصان استخدام التشفير، كانا بحاجة لنفس المفتاح السري — وكان عليهما أن يجدوا وسيلة آمنة لتبادله أولًا. هذه الفرضية عملت في بيئات صغيرة ومتحكم بها، لكنها لم تكن قابلة للتوسع لعالم قد يحتاج فيه غرباء إلى التواصل الآمن.
كان وايتفيلد ديفي باحثًا شابًا مفتونًا بالخصوصية والحدود العملية للتشفير في ذلك الوقت. اتصل بمارتن هيلمان في ستانفورد، وتأثر عملهما بازدياد الاهتمام الأكاديمي بأمن الكمبيوتر والشبكات — مجالات بدأت تنتقل من أنظمة معزولة إلى أنظمة مترابطة.
لم تكن قصة عبقري منفرد بقدر ما كانت الفكرة المناسبة في البيئة المناسبة: باحثون يتبادلون الملاحظات، يستكشفون تجارب فكرية، ويتحدى الافتراضات "الواضحة" التي قبلها الجميع لعقود.
كان اختراق ديفي وهيلمان هو الفكرة القائلة بأنه يمكن أن يستخدم التشفير مفتاحين مرتبطين بدلًا من سر واحد مشترك:
ما يجعل هذا قويًا ليس مجرد وجود مفتاحين — بل أن لكل منهما وظيفة مختلفة. المفتاح العام مصمم للتوزيع الآمن، بينما المفتاح الخاص مصمم للسيطرة والحصرية.
أعاد هذا تعريف مشكلة تبادل المفاتيح. بدلًا من ترتيب لقاء سري أو ساعي موثوق لتبادل سر واحد، يمكنك نشر مفتاح عام على نطاق واسع مع الحفاظ على الأمن.
هذا التحول — من "يجب أن نتقابل أولًا" إلى "يمكننا البدء بأمان بمعلومة عامة" — هو الأساس المفاهيمي الذي مكّن لاحقًا التصفح الآمن على الويب، التراسل المشفّر، وأنظمة الهوية الرقمية الحديثة.
ديفي–هيلمان (DH) طريقة ذكية لتمكين شخصين من إنشاء نفس السر المشترك حتى عندما تكون كل رسائلهما مرئية لأي شخص يراقب. يمكن بعد ذلك استخدام هذا السر المشترك كمفتاح متناظر عادي لتشفير المحادثة.
فكر في DH كخلط مكونات بطريقة يسهل القيام بها للأمام، لكن من الصعب جدًا "فك الخلطة". الوصفة تستخدم:
المتنصت يمكنه رؤية المعاملات العامة والقيمتين المتبادلتين. لكن ما لا يستطيع فعله بشكل عملي هو استرجاع أي من القيم الخاصة — أو حساب السر المشترك — من تلك الأجزاء العامة وحدها. مع معاملات مُختارة جيدًا، فإن عكس العملية يتطلب طاقة حسابية غير واقعية.
DH لا يشفر الرسائل بنفسه — بل يخلق مفتاحًا مشتركًا يجعل التشفير المتناظر السريع ممكناً.
يعمل التشفير بالمفتاح العام لأن بعض العمليات الرياضية غير متماثلة: من السهل تنفيذها في اتجاه واحد، لكن من الصعب جدًا عكسها بدون قطعة معلومات خاصة.
نموذج مفيد هو "دالة أحادية الاتجاه". تخيل آلة تحول مدخلاً إلى مخرج بسرعة. يمكن لأي شخص تشغيل الآلة، لكن إعطاء المخرج فقط، استرجاع المدخل الأصلي ليس واقعيًا.
في التشفير، لا نعتمد على سرية الآلة. نعتمد على أن عكسها يتطلب حلًا لمشكلة «صعبة» — مشكلة يُعتقد أنها تحتاج موارد حسابية غير عملية.
"صعب" لا يعني مستحيلاً إلى الأبد. بل يعني:
لذلك يعتمد الأمان على افتراضات (ما يعتقده الرياضيون وعلماء التشفير عن هذه المسائل) وممارسات العالم الحقيقي (أحجام المفاتيح، تنفيذات آمنة، معايير محدثة).
تحدث الكثير من الرياضيات العامة "بالقاسم" — فكر فيها كساعة. على ساعة 12 ساعة، إن أضفت 5 ساعات إلى 10 لن تحصل 15؛ ستعود إلى 3. ذلك السلوك هو الحساب المقاوم.
مع أعداد كبيرة، يمكن لعمليات "الالتفاف" المتكررة أن تخلق مخرجات تبدو مشوشة. التقدم للأمام (إجراء العمليات) سريع. الرجوع للخلف (التوصل إلى ما بدأت به) يمكن أن يكون بطيئًا جدًا ما لم تعرف اختصارًا سريًا — مثل المفتاح الخاص.
هذه الفجوة من السهل للأمام والصعب للخلف هي المحرك وراء تبادل المفاتيح والتواقيع الرقمية.
عندما ترى قفل المتصفح، عادةً تستخدم HTTPS: اتصال مشفر بين جهازك وموقع ويب. لم يكن بالإمكان توسيع الويب ليخدم مليارات الاتصالات الآمنة إذا كان على كل متصفح أن يشارك سرًا مع كل خادم مسبقًا.
يحِل التشفير بالمفتاح العام مشكلة "الاتصال الأول": يسمح لمتصفحك بإنشاء سر مشترك بأمان مع خادم لم يلتقِ به من قبل.
تعد مصافحة TLS الحديثة تفاوضًا سريعًا يهيئ الخصوصية والثقة:
عمليات المفتاح العام أبطأ ومصممة لـ الاتفاق والمصادقة، ليست لحماية الكتلة الكبيرة من البيانات. بعد أن يؤسس TLS مفاتيح الجلسة، يتحول إلى التشفير المتناظر السريع (مثل AES أو ChaCha20) لحماية كل ما ترسله فعليًا — طلبات الصفحات، كلمات المرور، وملفات تعريف الارتباط.
إذا أردت الفرق المبسط بين HTTP و HTTPS، راجع /blog/https-vs-http.
التوقيع الرقمي هو أداة المفتاح العام لجعل رسالة ما قابلة للإثبات. عندما يوقّع شخص ملفًا أو رسالة بمفتاحه الخاص، يمكن لأي شخص التحقق من التوقيع باستخدام المفتاح العام المطابق.
توقيع صالح يبرهن على شيئين:
هاتان الفكرتان غالبًا ما تختلطان:
يمكنك فعل أحدهما دون الآخر. على سبيل المثال، يمكن توقيع إعلان عام (حتى يثق الناس فيه) دون تشفيره (لأنه معد للقراءة من الجميع).
تظهر التواقيع الرقمية في أماكن قد تستخدمها يوميًا:
الميزة الرئيسية أن التحقق لا يتطلب مشاركة سر. يحتفظ الموقع بالتوقيع بالمفتاح الخاص، بينما يمكن توزيع المفتاح العام على نطاق واسع. هذا الفصل — خاص للتوقيع، عام للتحقق — يتيح للغرباء التحقق من الرسائل على نطاق واسع دون ترتيب كلمة مرور أو سر مشترك مسبقًا.
التشفير بالمفتاح العام يحل "كيف نتشارك الأسرار"، لكنه يترك سؤالًا آخر: لمن ينتمي هذا المفتاح فعلاً؟ المفتاح العام بحد ذاته مجرد رقم طويل. تحتاج وسيلة لربط هذا المفتاح بهوية حقيقية مثل "مصرفي" أو "خادم بريد هذه الشركة".
الشهادة الرقمية هي مستند موقّع يقول، بعبارة أوضح: "هذا المفتاح العام ينتمي لهذه الهوية." تتضمن اسم الموقع أو المنظمة (وتفاصيل أخرى)، المفتاح العام، وتواريخ انتهاء الصلاحية. الجزء المهم هو التوقيع: جهة موثوقة توقّع الشهادة حتى يتمكن جهازك من التحقق من أنها لم تُعدَّل.
الجهة الموثوقة عادةً ما تكون سلطة شهادات (CA). المتصفح ونظام التشغيل يأتون مع قائمة جذور CA موثوقة. عند زيارتك لموقع، يعرض الخادم شهادته مع شهادات وسيطة، مكونة سلسلة ثقة تعود إلى جذر CA موثوق مثبت على جهازك.
عند كتابة رابط مصرفك ورؤية أيقونة القفل، فقد تحقق المتصفح من:
إذا نجحت تلك الفحوصات، يمكن لـ TLS استخدام ذلك المفتاح العام للمصادقة والمساعدة في إقامة التشفير.
PKI ليست مثالية. يمكن للسلطات أن ترتكب أخطاء أو تُخترق، مما يؤدي إلى إصدار شهادات خاطئة (شهادة لطرف غير صحيح). الشهادات تنتهي صلاحيتها، وهذا مفيد للأمان لكنه قد يعرقل الوصول إذا لم تُجدَّد. كما أن إبطال الشهادات (إعلام العالم بأن شهادة ما لم يعد موثوقًا بها) أمر معقد على مقياس الإنترنت، والمتصفحات لا تنفذ دائمًا الإبطال بشكل صارم.
تهدف المراسلة المشفّرة من طرف إلى طرف لوعد بسيط: فقط الأشخاص في المحادثة يمكنهم قراءة الرسائل. لا مزود التطبيق، ولا شركة الاتصالات، ولا شخص يراقب الشبكة.
تحاول معظم تطبيقات الدردشة الحديثة موازنة ثلاثة أهداف:
التشفير يحتاج مفاتيح. لكن لا ينبغي أن يضطر شخصان لم يلتقيا من قبل إلى مشاركة سر مسبقًا — وإلا نعود لمشكلة تبادل المفاتيح الأصلية.
يحل التشفير بالمفتاح العام خطوة الإعداد. في العديد من أنظمة E2EE، تستخدم العملاء تبادلًا يعتمد على المفتاح العام (بروح ديفي–هيلمان) لإنشاء أسرار مشتركة عبر شبكة غير موثوقة. ثم تُستخدم تلك الأسرار للتشفير المتناظر السريع لمرور الرسائل.
السرية المستقبلية تعني أن التطبيق لا يعتمد على مفتاح طويل الأمد لكل شيء. بدلاً من ذلك، يجدد المفاتيح بمرور الوقت — غالبًا لكل جلسة أو حتى لكل رسالة — بحيث لا يؤدي اختراق مفتاح واحد إلى فتح التاريخ الكامل للرسائل.
لهذا السبب يصبح "سرق الهاتف اليوم، فك تشفير سنوات من الدردشات غدًا" أصعب كثيرًا عندما تُنفّذ السرية المستقبلية بشكل صحيح.
حتى مع تشفير قوي، يضيف العالم الحقيقي احتكاكًا:
تحت السطح، المراسلة الآمنة قصة عن تبادل المفاتيح وإدارة المفاتيح — لأن هذا ما يحول "مشفر" إلى "خاص، حتى لو كانت الشبكة غير موثوقة".
الهوية الرقمية هي النسخة الإلكترونية لـ "من أنت" عند استخدام خدمة: حسابك، تسجيل دخولك، والإشارات التي تثبت أنه أنت فعلًا. لسنوات، اعتُبرت كلمة المرور دليلًا على ذلك — بسيطة ومألوفة، لكنها سهلة الصيد، وإعادة الاستخدام، والتسريب، أو التخمين.
يقدّم التشفير بالمفتاح العام مقاربة مختلفة: بدلًا من إثبات أنك تعرف سرًا مشتركًا (كلمة مرور)، تُثبت أنك تتحكّم في مفتاح خاص. يخزن الموقع المفتاح العام، بينما يبقى المفتاح الخاص معك.
مع تسجيل الدخول القائم على المفاتيح، ترسل الخدمة تحديًا (مقطعًا عشوائيًا). يوقّع جهازك هذا التحدي بمفتاحك الخاص. تتحقق الخدمة من التوقيع بالمفتاح العام. لا حاجة لمرور كلمة السر عبر الشبكة، ولا يوجد شيء يمكن للمهاجم سرقته من نموذج تسجيل الدخول ليُعاد استخدامه.
هذه الفكرة تشغّل تجربة "بدون كلمات مرور" الحديثة:
تعمل هوية المفتاح العام أيضًا للآلات. على سبيل المثال، يمكن لعميل API توقيع الطلبات بمفتاح خاص وتتحقق الخوادم منها بالمفتاح العام — مفيد لمصادقة خدمة إلى خدمة حيث تكون أسرار API المشتركة صعبة التدوير وسهلة التسريب.
إذا أردت غوصًا أعمق في النشر الفعلي وتجربة المستخدم، راجع /blog/passwordless-authentication.
التشفير بالمفتاح العام قوي، لكنه ليس سحرًا. العديد من الإخفاقات الحقيقية تحدث ليس لأن الرياضيات منحلة، بل لأن الأنظمة المحيطة به غير صحيحة.
يمكن أن تدمر العشوائية الضعيفة كل شيء بصمت. إذا ولدت الأجهزة أعدادًا قابلة للتنبؤ للمهيئات أو المفاتيح (خاصة أثناء التشغيل الأولي، في الآلات الافتراضية، أو أجهزة إنترنت الأشياء المقيدة)، قد يتمكن المهاجمون من إعادة بناء الأسرار.
(التنفيذ الضعيف) سبب متكرر آخر: استخدام خوارزميات قديمة، تخطي التحقق من الشهادات، قبول معاملات ضعيفة، أو التعامل غير الصحيح مع الأخطاء. حتى تغييرات "مؤقتة" صغيرة — مثل إيقاف فحوص TLS للتصحيح — غالبًا ما تُشحن في الإنتاج.
الــصيد والهندسة الاجتماعية تتجاوز التشفير تمامًا. إن خُدع المستخدم للموافقة على تسجيل دخول أو كشف رمز استرداد أو تثبيت برمجيات خبيثة، فلن تساعد المفاتيح القوية.
يجب تخزين المفاتيح الخاصة بحيث لا يمكن نسخها بسهولة (ويُفضَّل في أجهزة آمنة)، وحمايتها في السكون بتشفير. كما تحتاج الفرق إلى خطط للـ نسخ الاحتياطية، التدوير، والإبطال — لأن المفاتيح تضيع، وتُسرق الأجهزة، ويغادر الناس الشركات.
إذا كانت الإجراءات الآمنة مربكة، سيلجأ الناس إلى طرق مختصرة: مشاركة الحسابات، إعادة استخدام الأجهزة، تجاهل التحذيرات، أو حفظ أكواد الاسترداد في أماكن غير آمنة. التصميم الأمني الجيد يقلل نقاط القرار ويجعل الفعل الآمن هو الأسهل.
إذا كنت تبني وترسل برمجيات بسرعة، غالبًا ما يكون الخطر الأكبر ليس التشفير نفسه — بل التكوين غير المتسق عبر البيئات. منصات مثل Koder.ai يمكن أن تسرّع التسليم، لكن نفس أساسيات المفتاح العام ما زالت تنطبق:
باختصار: البناء الأسرع لا يغيّر القواعد — أفكار ديفي ما زالت الأساس لكسب ثقة المستخدم عند الاتصال لأول مرة.
اختراق ديفي لم يضف أداة جديدة فحسب — بل غيّر الفرضية الافتراضية للأمن من "يجب أن نلتقي أولًا" إلى "يمكننا أن نبدأ التحدث بأمان عبر شبكة مفتوحة". ذلك التحول الوحيد جعل من العملي لمليارات الأجهزة والغرباء إنشاء أسرار، إثبات الهوية، وبناء الثقة على نطاق الإنترنت.
ما زال تبادل المفاتيح ديفي–هيلمان أساسًا، لكن معظم الأنظمة الحديثة تستخدم إصدارات محدثة.
تبادل المفاتيح على المنحنيات الإهليلجية (ECDH) يحافظ على هدف "الاتفاق على سر مشترك علنًا" مع مفاتيح أصغر وعملية أسرع. أصبح RSA، الذي طُوّر بعد عمل ديفي، مشهورًا للتشفير والتواقيع في أمان الويب المبكر؛ اليوم يُستخدم بحذر أكبر، بينما تواقيع المنحنيات الإهليلجية وECDH شائعة.
كل نشر واقعي تقريبًا هو مخطط هجين: طرق المفتاح العام تتعامل مع المصافحة (المصادقة والاتفاق)، ثم يقوم التشفير المتناظر السريع بحماية البيانات الفعلية. هذا النمط هو السبب في أن HTTPS يمكن أن يكون آمناً وسريعًا.
أجهزة الكم المستقبلية قد تُضعف تقنيات المفتاح العام الشائعة اليوم (خاصة المعتمدة على التحليل إلى عوامل وقيم اللوغاريتمات المتقطعة). الاتجاه العملي هو "إضافة خيارات جديدة والهجرة بأمان"، وليس الاستبدال الفوري. تختبر العديد من الأنظمة تبادل مفاتيح وتواقيع ما بعد-الكم بينما تحتفظ بتصاميم هجينة لتكسب حماية جديدة دون مخاطرة بالرهان كله على خوارزمية واحدة.
حتى مع تغير الخوارزميات، تبقى المشكلة الصعبة نفسها: تبادل الأسرار والثقة بين طرفين قد لا يكونان قد التقيا — بسرعة، على مستوى العالم، وبأقل احتكاك ممكن للمستخدم.
خلاصة: يمكّن التشفير بالمفتاح العام الاتصال الآمن الأول؛ المخططات الهجينة تجعلها قابلة للاستخدام على نطاق واسع؛ والعصر القادم يتطلب تطورًا حذرًا.
قراءات مقترحة: /blog/diffie-hellman-explained, /blog/tls-https-basics, /blog/pki-certificates, /blog/post-quantum-crypto-primer
التشفير المتناظر يستخدم مفتاحًا سريًا مشتركًا واحدًا للتشفير وفك التشفير. إنه سريع وممتاز للبيانات الكبيرة، لكن لديه مشكلة إعداد: يجب أن تشارك ذلك المفتاح بأمان أولًا.
التشفير بالمفتاح العام يقسم الأدوار إلى مفتاح عام (قابل للمشاركة) ومفتاح خاص (يبقى سريًا)، مما يجعل «الاتصال الآمن الأول» ممكنًا دون حاجة إلى سر مشترك مسبقًا.
حل مشكلة توزيع المفاتيح: يمكن لاثنين من الغرباء البدء اتصال آمن عبر شبكة يمكن للآخرين مراقبتها دون الالتقاء لتبادل سر.\n\nهذا التغيير هو ما يجعل أمان على نطاق الإنترنت عمليًا لتطبيقات مثل:
ديفي–هيلمان (DH) هي طريقة لإنشاء سر مشترك عبر قناة عامة.
عمليًا:
DH بنفسه لا يقوم بتشفير الرسائل؛ بل يساعدكما على الاتفاق على المفتاح الذي سيُستخدم للتشفير.
لا يكفي بمفرده. DH يوفر اتفاقًا على المفتاح لكنه لا يثبت هوية الطرفين.\n\nلمنع هجمات الرجل في الوسط، يُقرن DH عادةً بالمصادقة، مثل:
يستخدم TLS التشفير بالمفتاح العام أساسًا لـ المصادقة والاتفاق على المفاتيح خلال المصافحة، ثم يتحول إلى مفاتيح متناظرة للبيانات.\n\nنظرة مبسطة:\n\n- يعرض الخادم شهادة تحتوي على مفتاح عام
التوقيع الرقمي يتيح لشخص ما إثبات أنه أنشأ شيئًا وأنه لم يتغير.\n\nالاستخدامات النموذجية تشمل:\n\n- التحقق من أن تحديثات البرامج صادرة عن البائع
الشهادة تربط مفتاحًا عامًا بهوية (مثل اسم موقع) عبر توقيع جهة موثوقة.
تثق المتصفحات بالشهادات لأن بإمكانها بناء سلسلة ثقة من شهادة الموقع عبر شهادات وسيطة وصولًا إلى جذر CA موثوق مثبت في نظام التشغيل/المتصفح.
عمليًا، لهذا السبب تعتبر تجديد الشهادات الصحيح، تكوين أسماء المضيف، والتحقق السليم أمورًا حاسمة لعمل HTTPS reliably.
تطبيقات التشفير من طرف إلى طرف تحتاج طريقة لإنشاء مفاتيح مشتركة بين أجهزة لم تتبادل أسرارًا من قبل.\n\nتستخدم عادةً تبادلات على شاكلة DH (غالبًا على المنحنيات الإهليلجية) لـ:
تمريري الدفع (Passkeys - FIDO2/WebAuthn) تستبدل تسجيل الدخول بالكلمة السرية بتوقيع تحدي–استجابة.\n\nعمليًا:\n\n- يخزن الخدمة مفتاحك العام
معظم الإخفاقات تكون في التنفيذ والتشغيل، وليس في الرياضيات الأساسية.\n\nالعيوب الشائعة:\n\n- عشوائية ضعيفة عند إنشاء المفاتيح