لماذا تخلينا عن RSA لصالح Ed25519 (ولماذا يجب عليك فعل ذلك أيضاً)

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

عادة RSA

كل دليل استضافة ذاتية على الإنترنت يقول نفس الشيء:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365

RSA 4096. لأن الأرقام الأكبر تعني أماناً أكثر، أليس كذلك؟ لم يعد الأمر كذلك. مفاتيح RSA 4096 بحجم 3.2 كيلوبايت. يستغرق توليدها ثوانٍ على خادم VPS بسعر 5 دولارات. وتوفر تقريباً نفس مستوى الأمان الذي توفره مفتاح منحنى إهليلجي بحجم 256 بت.

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

Ed25519 في لمحة

Ed25519 هو نظام توقيع EdDSA مبني على Curve25519. ينتج مفاتيح بحجم 256 بت ثابت ومدمجة. مصمم حصرياً للتوقيعات الرقمية — لا تشفير، لا تبادل مفاتيح، فقط توقيع. هذا التخصص يجعله أبسط وأسرع وأقل عرضة للأخطاء.

في Go، هو مواطن من الدرجة الأولى. حزمة crypto/ed25519 في المكتبة القياسية منذ Go 1.13. توليد المفتاح في سطرين. التسلسل يستخدم x509.MarshalPKCS8PrivateKey القياسي. لا تبعيات خارجية، لا CGo، لا علامات بناء خاصة.

مقارنة ثلاثية

المصادر: أنواع المفاتيح مشروحة، معايير Go: RSA مقابل ECDSA مقابل Ed25519، مقارنة خوارزميات مفاتيح SSH

فخ ECDSA KeyUsage

هنا خطأ يقع فيه تقريباً كل من ينتقل من RSA إلى ECDSA. في حزمة crypto/x509 في Go، تحتاج مفاتيح RSA إلى كل من KeyUsageDigitalSignature و KeyUsageKeyEncipherment في قالب الشهادة. إذا نسخت هذا النمط إلى ECDSA — بإضافة KeyUsageKeyEncipherment إلى مفتاح EC — سيرفض بعض عملاء TLS الشهادة. مفاتيح EC لا تقوم بتشفير المفاتيح. هذا الامتداد بلا معنى وضار فعلياً.

هكذا يبدو الإصلاح في توليد شهادات Bedrud (server/internal/utils/tls.go):

func keyUsageForAlgo(algo KeyAlgorithm) x509.KeyUsage {
    switch algo {
    case KeyRSA2048, KeyRSA4096:
        return x509.KeyUsageDigitalSignature | x509.KeyUsageKeyEncipherment
    default:
        return x509.KeyUsageDigitalSignature
    }
}

يقع Ed25519 في الفرع الافتراضي. توقيع رقمي نقي. لا خيار KeyEncipherment يمكن إعداده بشكل خاطئ. فخ أقل.

ما يعنيه على خادم VPS بسعر 5 دولارات

على Hetzner CX22 (2 vCPU، 4 GB RAM)، الفرق قابل للقياس:

• توليد المفتاح: RSA 4096 يستغرق ~1–2 ثانية. Ed25519 يستغرق أقل من 1 مللي ثانية. هذا مهم عندما يولد خادمك شهادة موقعة ذاتياً عند التشغيل الأول.
• مصافحة TLS: Ed25519 يوقع ويتحقق بشكل أسرع، مما يقلل من زمن انتظار المصافحة. على خادم مشغول يعالج عشرات اتصالات WebRTC، هذه الملي ثواني تتراكم.
• البصمة على القرص: مفتاح Ed25519 الخاص بحجم 48 بايت بصيغة PEM. مفتاح RSA 4096 بحجم 3.2 كيلوبايت. لشهادة واحدة ليس فرقاً كبيراً، لكنه يعكس الفرق في الوزن الحسابي.

ماذا يفعل Bedrud

يولد Bedrud شهادات Ed25519 الموقعة ذاتياً بشكل افتراضي. الدالة GenerateSelfSignedCert تستخدم KeyEd25519 ما لم تحدد خلاف ذلك.

إذا كنت بحاجة إلى خوارزمية مختلفة — للتوافق مع العملاء القدامى أو السياسات الداخلية — استخدم علامة --key-algorithm:

bedrud run --key-algorithm rsa4096
bedrud run --key-algorithm ecdsa256

القيم المدعومة: ed25519 (الافتراضي)، ecdsa256، rsa2048، rsa4096.

متى يجب البقاء مع RSA

RSA لم يمت. لا تزال بحاجة إليه من أجل:

• عملاء Java القدامى الذين لا يدعمون مصافحات TLS بـ Ed25519
• أجهزة Android قبل 7.0 (Nougat) التي تفتقر إلى دعم Ed25519 في مجموعة TLS الخاصة بها
• الأجهزة المضمنة بإصدارات قديمة من OpenSSL أو mbedTLS
• بيئات المؤسسات مع صناديق وسيطة لفحص TLS تفهم فقط RSA

إذا كانت مجموعتك التقنية حديثة — خلفية Go، متصفحات مبنية على Chromium، تطبيقات موبايل حديثة — فإن Ed25519 يعمل في كل مكان يهم.

الخلاصة

البنية التحتية المستضافة ذاتياً لا يجب أن تحمل مفاتيح RSA بسعة 4096 بت لمجرد أن درساً تعليمياً من 2013 أوصى بذلك. Ed25519 أسرع وأصغر وأقل عرضة للأخطاء. مكتبة Go القياسية محسنة له. وبالنسبة للشهادات الموقعة ذاتياً في مجموعة تقنية مسيطر عليها، حجة التوافق لصالح RSA لا تصمد.

استضافة ذاتية بخصائص افتراضية أفضل. ثبّت Bedrud وجربه بنفسك.