عدد البتات في ملف مفتاح ثابت ليس قوة تشفير OpenVPN

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

هنا يختلط سؤالان: كم مادة مفتاح يخزّن الملف، ومدى قوة الشيفرة المتفاوض عليها. والسؤال الثاني وحده هو الذي يصف النفق.

ما الذي يحسبه الرقم المطبوع في الرأس فعلًا

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

قارن ذلك بمفتاح شهادة، حيث يصف عدد البتات فعلًا حجم كائن واحد. فمفتاح RSA بطول 4,096 بتة وملف مفتاح يقرأ رأسه 4,096 بتة شيئان مختلفان بمهمتين مختلفتين، وصفّهما كإعدادين على قرص واحد يفضي إلى استنتاجات خاطئة.

مجموعتان من المفاتيح في ملف واحد

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

إذا كنت تريد فعلًا مفتاحًا أطول، فالإعداد الذي يجب تغييره هو الشيفرة أو الموجز، والمولّد ينتج ما تحتاجه الخوارزميات المختارة.

قراءة الملف الشخصي تخبرك أي وضع لديك

يخدم التنسيق نفسه وظيفتين مختلفتين تمامًا، والملف الشخصي وحده يقول أيّهما لديك. فسطر secret القديم يجعل الملف مادة المفتاح الوحيدة للنفق، بينما tls-auth أو tls-crypt يجعله حماية لقناة التحكم إلى جانب الشهادات. ولا يحوّله أي من الاستخدامين إلى مفتاح خاص لشهادة عميل، مهما بدت الكتلة مشابهة. حدّد الخيار والإصدار قبل توليد بديل، واستخدم المولّد الموثق بدلًا من إلحاق محارف.

وذلك التمييز يحدد أيضًا الاستجابة للانكشاف. فمفتاح tls-auth الذي يتسرب لا يكشف مفاتيح الجلسة، لكنه يتيح لمهاجم حقن حركة قناة التحكم، لذا يلزم استبداله رغم ذلك. ومفتاح secret المسرّب أسوأ، لأنه كان المادة التي تحمي البيانات نفسها.

ما ينبغي أن تسجله مراجعة الأمن

سجّل ثلاثة أمور منفصلة: حماية قناة البيانات المتفاوض عليها، وحماية قناة التحكم، وكيفية مصادقة الأقران. فسطر مثل data-ciphers AES-256-GCM يصف الأول فقط، والتقرير الذي يتوقف عنده لا يستطيع الإجابة عما إذا كانت قناة التحكم محمية أصلًا. وملف المفتاح الثابت ينتمي إلى السلة الثانية عندما يُستخدم مع tls-auth أو tls-crypt، ولا ينتمي إلى أي منهما عندما لا يُستخدم. والمراجعون الذين يخلطون بين السلتين يطلبون ملف مفتاح أكبر حين يكون ما يريدونه شيفرة أقوى.

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

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