Entropy Mixing

تخيّل سجلين للحدث نفسه. يختلف اسما الملفين، لكن السجل الثاني لا يضيف مجهولًا مستقلًا. وبالمثل، قد ترتبط أوقات وصول الحزم وأوقات الوصول إلى القرص. يحذّر معيار ⁦NIST SP 800-90B⁩ من جمع تقديرات إنتروبيا المصادر التابعة لبعضها ببساطة. يجب أولًا تحديد ما يبقى غير مؤكد عندما يعرف المهاجم بقية المدخلات أيضًا. [1]

الهاش بصمة تُحسب من البيانات. لكن إن عرف المهاجم كل المدخلات، أمكنه حساب النتيجة نفسها. لا قيمة ⁦hash⁩ طويلة ولا ثابت علني مضاف يحوّلان بيانات معروفة إلى سر. تميّز ⁦RFC 4086⁩ بين مزج عدم اليقين المتاح وتوليد قيم أخرى بصورة حتمية. المزج المصمم جيدًا يستفيد مما توفره المصادر فعلًا؛ ولا يعوّض الإنتروبيا المفقودة. [2]

تقارن XOR البتات: المتساويان ينتجان صفرًا والمختلفان واحدًا. لذلك ⁦X XOR X = 0⁩: مزج قيمة بنسختها يزيل هنا كل عدم اليقين. أما إذا كان أحد المدخلين عشوائيًا منتظمًا ومستقلًا عن الآخر، فتظل النتيجة منتظمة. توضّح RFC 4086 بهذا المثال أهمية الافتراضات. وليس هذا وصفة لصنع مولّد محفظة بنفسك. [2]

عند تقييم تصميم محدد، اسأل من أين تأتي المدخلات وما يستطيع المهاجم فعله بها. يستخدم ⁦HKDF⁩، وهو أسلوب لاشتقاق المفاتيح التشفيرية، مدخلًا مساعدًا اسمه ⁦salt⁩. لا يلزم أن يكون سريًا، لكن ⁦RFC 5869⁩ يفترض استقلاله عن البيانات الأصلية للمفتاح ويطلب أن يمنع التطبيق المهاجم من اختياره أو تغييره. ⁦Salt⁩ هنا اسم معامل. ولا تكفي قائمة المصادر أو النتيجة التي تبدو عشوائية لضمان الأمان عند تعطل مصدر. [4]

يعتمد ⁦NIST SP 800-90B⁩ على مصدر ضجيج أساسي. ويسمح بإلحاق مخرجات مصادر أخرى ببياناته، بشرط أن تمر معًا بطريقة معالجة معتمدة تسمى ⁦conditioning⁩. لكنه لا يحتسب لتلك المصادر إنتروبيا إضافية في هذا الإطار. لذلك لا تؤدي زيادة المدخلات تلقائيًا إلى رفع القيمة المعترف بها. هذه قاعدة لتقييم محدد، وليست قولًا إن المصادر الأخرى لا يمكن أن تفيد أبدًا. [1]

يظهر الفرق في ⁦OpenSSL 3.5⁩، وهي مكتبة تشفير تستطيع البرامج استخدامها للتشفير والأرقام العشوائية. تمزج الدالة ⁦RAND_add()⁩ بيانات من ⁦buffer⁩، أي منطقة في الذاكرة مخصصة لحفظها. يحدد ⁦num⁩ عدد البايتات المقروءة، بينما يقدر ⁦randomness⁩ إنتروبيا تلك البيانات بالبايت من الصفر إلى ⁦num⁩. حجم منطقة الذاكرة لا يثبت صحة هذا التقدير. عادة يهيئ المولّد الافتراضي نفسه ويجدد الإنتروبيا تلقائيًا من مصادر النظام. [3]

يسمى تزويد المولّد بإنتروبيا جديدة ⁦reseeding⁩، وهو أمر مختلف عن إضافة أي بيانات. توضح وثائق ⁦OpenSSL 3.5⁩ أن وضع ⁦FIPS⁩، الذي يتبع قواعد للوحدات التشفيرية، لا يعترف ببيانات التطبيق كمصدر موثوق للإنتروبيا. تُخلط هذه البيانات بوصفها مدخلًا إضافيًا فقط، ولا تُحتسب ⁦reseed⁩ كاملًا. لذلك لا يثبت استدعاء ⁦RAND_add()⁩ وحده حصول هذا التجديد. [3]

يقسم ⁦HKDF⁩ في ⁦RFC 5869⁩ العمل إلى ⁦HKDF-Extract⁩ و⁦HKDF-Expand⁩. تركز الخطوة الأولى الإنتروبيا المتاحة في المدخل داخل مفتاح وسيط، وتشتق الثانية منه بيانات بالطول المطلوب. لا يحصل هذا الإجراء على سر مستقل جديد. ويمكن للمعامل ⁦info⁩ ربط النتيجة باستخدامها المقصود، كبيان الغرض من المفتاح المشتق. هذا السياق لا يعوض بيانات أولية جيدة ولا يثبت توليد إنتروبيا جديدة. [4]