Random Number Generator

تخيّل محفظة تشتق سرّها من الوقت الحالي وحده. قد تبدو النتيجة معقدة، لكن من يعرف وقت إنشائها سيجد أمامه احتمالات أقل بكثير لتجربتها. تحذّر RFC 4086 تحديدًا من مثل هذه المدخلات المتوقعة. لذلك قد يصلح مولّد للألعاب أو المحاكاة ولا يصلح للمفاتيح. وحتى التوزيع الإحصائي الجيد لا يثبت الأمان بمفرده. [2]

تتعاون عادةً عدة أجزاء. يوفّر المصدر قدرًا من عدم اليقين، ثم تُعالَج مخرجاته عند الحاجة، ويولّد مولّد حتمي تشفيري قيمًا إضافية من حالة داخلية سرية. ومعنى «حتمي» أن الحالة الداخلية والمدخلات نفسها تعطي النتيجة نفسها؛ لذلك يجب إبقاء هذه الحالة سرية. يطلب التطبيق هذه القيم عبر واجهة النظام. لذا ليس من الضروري إجراء قياس فيزيائي جديد لكل بت يُعاد. يشرح معيار ⁦NIST SP 800-90C⁩ الجمع بين مولّدات وفق 90A ومصادر وفق 90B. [1]

في BIP39، يتكوّن أساس استعادة المحفظة قبل ظهور أول كلمة: يولّد المولّد من 128 إلى 256 بت من الإنتروبيا الأولية. البت وحدة أساسية للمعلومات، قيمتها صفر أو واحد؛ والمهم ألا يستطيع المهاجم توقّع التسلسل الناتج. يُضاف مجموع تحقق، وهو قيمة قصيرة تساعد على اكتشاف بعض أخطاء النسخ، ثم تُحوّل النتيجة إلى كلمات الاسترداد. ويمكن إضافة passphrase، أي نص سري إضافي. تشتق الدالة PBKDF2 من هذه المدخلات seed بطول 512 بت، وهي القيمة السرية التي تبدأ منها المحفظة اشتقاق مفاتيحها. لا تعوّض المخرجات الأطول ولا مجموع التحقق العشوائية المفقودة. لهذا لا تختَر كلمات الاسترداد بنفسك. [6]

يجب أن يتمكن الجهاز من اكتشاف أعطال مثل بدء مصدر الضجيج بتكرار القيمة نفسها. لذلك يتطلب معيار ⁦NIST SP 800-90B⁩ فحوصًا عند بدء التشغيل وأثناءه، ومعالجة الأعطال المكتشفة. لا يجوز تجاهل الخطأ والاستمرار في تقديم المخرجات بوصفها عشوائية متحققًا منها. هذه الفحوص تراقب المصدر؛ ولا تضمن أمان المحفظة بأكملها. [3]

يحتفظ المولّد الحتمي بحالة داخلية يحسب منها النتائج التالية. يشرح معيار ⁦NIST SP 800-90A⁩ إنشاءه والتوليد وإضافة إنتروبيا جديدة (reseed) وإنهاءه. إذا تسربت الحالة، فقد لا يكفي استدعاء المولّد مرة أخرى لاستعادة الأمان. تتطلب الاستعادة إجراءً مناسبًا وإنتروبيا جديدة يجهلها المهاجم. ولا يسحب ذلك من يديه المفاتيح التي انكشفت سابقًا. [7]

لا تحتاج إلى برمجة RNG بنفسك. انظر إلى ما إذا كانت طريقة التوليد ومعالجة الأخطاء موثقتين لإصدار المحفظة المحدد. كلمتا «عتادية» أو «غير متصلة» لا تثبتان ذلك وحدهما. يجب أن تشمل المراجعة المصدر والخوارزمية والتهيئة وواجهة التطبيق. وحتى السر الذي أُنشئ بصورة صحيحة يفقد حمايته إذا كشفت لاحقًا نسخته الاحتياطية. [1] [2]

ينتظر ⁦getrandom()⁩ في Linux افتراضيًا تهيئة urandom؛ ومع ⁦GRND_NONBLOCK⁩ قد يعيد EAGAIN بدل الانتظار. بعد التهيئة، يضمن الطلب من urandom الذي لا يتجاوز 256 بايت قراءة المقدار كاملًا دون مقاطعة بإشارة. لا يشمل هذا الضمان الطلبات الأكبر. لذا يجب على البرنامج التحقق من حالة الإرجاع وعدد البايتات المستلمة فعلًا. [4]

يوفّر Web Crypto الدالة ⁦getRandomValues()⁩ لملء مصفوفة أعداد صحيحة مدعومة بقيم قوية تشفيريًا. إذا تجاوز الحجم 65536 بايت، تُطلق ⁦QuotaExceededError⁩. توصي المواصفة باستخدام ⁦generateKey()⁩ لمفاتيح الخوارزميات المدعومة؛ وليست مولّدًا عامًا لمحافظ بيتكوين. حتى الاستخدام الصحيح للواجهة لا يثبت موثوقية الصفحة: فقد تتمكن شيفرتها من الوصول إلى السر المُنشأ. [5]