ما الفرق بين الأرقام شبه العشوائيّة والأرقام العشوائيّة الحقيقيّة - كيف نميّز بينها

عندما يتحدّث الناس عن الأرقام العشوائيّة، كثيرًا ما تُجمع أمور مختلفة جدًّا تحت كلمة واحدة هي random، فينحرف النقاش بسرعة. فالمتتالية المُولَّدة بالحساب مثل Math.random() والمتتالية المستمدّة من ظواهر فيزيائيّة كالضجيج الحراريّ أو jitter في الساعة، كلتاهما قد تبدوان على أنّهما متبعثرتان بشكل لطيف للوهلة الأولى.

غير أنّ ترك هذا التمييز ضبابيًّا في الممارسة يقود إلى أخطاء كهذه:

• تريد قابليّة الإعادة في محاكاة، لكنّ النتيجة تتغيّر في كلّ تشغيل
• تُولِّد رموز إعادة تعيين كلمة المرور بأرقام عشوائيّة يسهل التنبّؤ بها
• تفترض أنّ اجتياز اختبار إحصائيّ يعني “إذًا هذا عشوائيّ حقيقيّ”
• أو، في الاتّجاه المعاكس، تسمع pseudo فتظنّ أنّ كلّ شيء غير آمن

تنظّم هذه المقالة ما تعنيه الأرقام pseudo-random و ما تعنيه الأرقام true random و كيف نميّز بينها، بصورة أسهل في الاستخدام في قرارات الهندسة الواقعيّة. والتركيز الرئيس ليس على المظهر السطحيّ للمخرجات، بل على بنية المُولِّد.

النقاش هنا منظَّم اعتمادًا على وثائق NIST و IETF ونظام التشغيل والتوثيق الرسميّ للغات البرمجة، التي أمكن التحقّق منها حتّى أبريل 2026.

جدول المحتويات

1. الإجابة الموجزة
2. ما تقصده هذه المقالة بـ “pseudorandom” و “true random”
3. صورة عامّة في صفحة واحدة
   • 3.1. مخطّط العلاقات
   • 3.2. أقصر ملخّص للمصطلحات
4. ما تعنيه الأرقام pseudorandom
   • 4.1. في جملة واحدة
   • 4.2. ينبغي التمييز بين PRNG الاعتياديّ و CSPRNG
5. ما تعنيه الأرقام true random
   • 5.1. في جملة واحدة
   • 5.2. حتّى العشوائيّة الفيزيائيّة لا تُستخدم دائمًا خامًا
6. ما الذي يختلف
   • 6.1. مصدر التوليد
   • 6.2. قابليّة الإعادة
   • 6.3. قابليّة التنبّؤ
   • 6.4. السرعة وقيود التشغيل
7. كيف نميّز بينها
   • 7.1. لا يمكن التمييز الكامل من المخرجات وحدها عمومًا
   • 7.2. أوّلًا، افحص تصميم المُولِّد
   • 7.3. ثمّ استخدم الاختبارات الإحصائيّة للبحث عن العيوب الواضحة
   • 7.4. للاستخدامات الأمنيّة، قِّم من زاوية المهاجم
8. أيّها ينبغي استخدامه ولأيّ غرض
9. سوء الفهم الشائع
10. جدول قرار عمليّ عند التردّد
11. الخلاصة
12. المراجع

1. الإجابة الموجزة

لنبدأ بملخّص متعمّد الخشونة لكنّه عمليّ:

• الأرقام pseudo-random متتاليات تُولَّد بشكل deterministic من حالة داخليّة وخوارزميّة
• الأرقام true random متتاليات يأتي مصدر entropy فيها من ظواهر فيزيائيّة كالضجيج الحراريّ أو jitter
• غير أنّ كثيرًا من APIs الأرقام العشوائيّة الآمنة المُستخدَمة في الممارسة لا تُعيد العشوائيّة الفيزيائيّة الخام مباشرةً، بل قِيَمًا من DRBG / CSPRNG يُغذَّى ببذرة seed من entropy source
• لذا لا يمكن التمييز بينها بمجرّد سؤال هل المخرجات “تبدو عشوائيّة”؛ بل ما عليك فحصه هو تصميم المُولِّد، وكيفيّة دخول seed، وعمليّة reseeding، واختبارات السلامة (health tests)
• في المحاكاة والاختبارات القابلة للإعادة، تُعدّ قابليّة إعادة الأرقام pseudo-random ميزة قوّة
• في الاستخدامات الحسّاسة أمنيًّا كالمفاتيح والرموز و nonces، ينبغي أن يكون الافتراض هو APIs الأرقام العشوائيّة الآمنة التي يقدّمها نظام التشغيل أو وقت تشغيل اللغة

في الممارسة، يساعد فصل هذه الأسئلة الثلاثة أوّلًا:

1. هل يدور الأمر حول PRNG اعتياديّ؟
2. هل يدور حول cryptographic PRNG / CSPRNG / DRBG؟
3. هل يدور حول NRBG / TRNG مدعوم بـ entropy source فيزيائيّ؟

2. ما تقصده هذه المقالة بـ “pseudorandom” و “true random”

في هذا الموضوع، كلمة random وحدها فضفاضة، فيساعد تثبيت معناها أوّلًا.

• الأرقام pseudo-random (PRNGs): مولِّدات تُنتج متتالية بشكل deterministic من seed وحالة داخليّة. تُنتج المتتالية نفسها في الظروف نفسها.
• الأرقام pseudo-random الآمنة تشفيريًّا (CSPRNG / DRBG): نوع من المولِّدات pseudo-random مصمَّم بعدم القابليّة للتنبّؤ في الحسبان. يعرّفها NIST SP 800-90A بأنّها deterministic random bit generator.
• الأرقام true random: في الاستعمال اليوميّ تعني عادةً الأرقام العشوائيّة الفيزيائيّة أو true RNGs. وفي مصطلحات NIST، NRBG (non-deterministic random bit generator) هو الأقرب. وهو يصف مولِّدًا يعتمد باستمرار على entropy source ويُنتج، في التشغيل العاديّ، مخرجات بـ full-entropy.

النقطة الأساسيّة هنا أنّ pseudorandom ليست الشيء نفسه كـ غير آمن.

فمثلًا، PRNG سريع كـ Linear Congruential Generator أو Xorshift بسيط، و CSPRNG كـ CTR_DRBG أو HMAC_DRBG، كلاهما deterministic، لكنّهما يعنيان أمورًا شديدة الاختلاف من منظور الأمن.

3. صورة عامّة في صفحة واحدة

3.1. مخطّط العلاقات

من الأسرع غالبًا النظر إلى العلاقة المفاهيميّة في صورة واحدة.

flowchart LR
    NOISE["Physical phenomena<br/>thermal noise, jitter, etc."] --> ENT["Entropy source"]
    ENT --> SEED["seed / reseed"]
    SEED --> DRBG["DRBG / CSPRNG<br/>expands random bits at high speed"]
    DRBG --> API["Random values returned by the OS / library"]

    STATE["Internal state + formula"] --> PRNG["Ordinary PRNG"]
    PRNG --> OUT["A sequence that looks random"]

النقطة المهمّة أنّ مخرجات secure random-number API التي يستعملها التطبيق تختلف قليلًا عن كلٍّ من PRNG الاعتياديّ على اليمين و الضجيج الفيزيائيّ الخام على اليسار.

في تنفيذات كثيرة، يُستخدَم entropy source على اليسار لـ seed / reseed، ثم يقوم DRBG / CSPRNG بتوسيع ذلك إلى قيم بسرعة. ووثيقتا NIST SP 800-90B و 800-90C هما تحديدًا من تنظّمان بنية entropy source + deterministic generator هذه.

3.2. أقصر ملخّص للمصطلحات

إن أردت أقصر مساعد للذاكرة:

• PRNG الاعتياديّ هو عشوائيّة يمكنك إعادتها
• CSPRNG هو عشوائيّة لا تزال قابلة للإعادة من حيث المبدأ، لكنّها مصمَّمة لتكون صعبة التنبّؤ من الخارج
• الأرقام true random هي عشوائيّة مستخرَجة من ظواهر فيزيائيّة

4. ما تعنيه الأرقام pseudorandom

4.1. في جملة واحدة

تُنتَج الأرقام pseudo-random بالحساب، عبر تحديث الحالة الداخليّة لتوليد متتالية تبدو عشوائيّة.

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

ولأنّ النتيجة قابلة للإعادة، يمكنك قول أشياء مثل هذا الـ seed يُعيد إنتاج العلّة أو أريد مقارنة نتيجة اليوم بنتيجة الأمس مرّة أخرى.

4.2. ينبغي التمييز بين PRNG الاعتياديّ و CSPRNG

هنا يخلط الناس أكثر ما يخلطون. القول pseudorandom = مزيّف = لا ينبغي استخدامه أبدًا خطأ.

يعرّف NIST SP 800-90A deterministic random bit generators المبنيّة فوق دوالّ hash أو block ciphers. أي إنّ جزءًا كبيرًا من توليد الأرقام العشوائيّة المستخدَم في الأنظمة التشفيريّة هو أيضًا deterministic.

الفرق الحقيقيّ ليس مجرّد سلوك يبدو عشوائيًّا، بل عدم القابليّة للتنبّؤ من منظور المهاجم.

• PRNG الاعتياديّ
  • سريع
  • سهل الإعادة
  • أسهل في التنبّؤ إن تسرّبت الحالة الداخليّة أو seed
• CSPRNG / DRBG
  • deterministic أيضًا
  • لكنّه مصمَّم بحيث يصعب التنبّؤ بالمخرجات ما دامت الحالة الداخليّة غير معروفة
  • الخيار الصائب للاستخدام الأمنيّ

لذا إن حكمت على السلامة فقط بالسؤال هل الشيء pseudorandom، فستخطئ غالبًا. ما يهمّ هو أيّ نوع من المولِّدات pseudo-random هو.

5. ما تعنيه الأرقام true random

5.1. في جملة واحدة

تُستمدّ الأرقام true random من عدم اليقين الفيزيائيّ كالضجيج الحراريّ، أو jitter في المذبذب، أو ضجيج الانهيار الجليديّ، أو الظواهر الكموميّة.

في الاستعمال اليوميّ تُسمَّى غالبًا الأرقام العشوائيّة الفيزيائيّة أو true random numbers. وفي مصطلحات NIST، الأقرب هو NRBG: مولِّد يصل إلى entropy source باستمرار، وما دام يعمل بشكل طبيعيّ، يُنتج مخرجات بـ full-entropy.

5.2. حتّى العشوائيّة الفيزيائيّة لا تُستخدم دائمًا خامًا

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

تأتي المصادر الفيزيائيّة بصعوبات عمليّة من قبيل:

• الانحياز bias
• الحساسيّة لدرجة الحرارة وظروف الطاقة والأعطال والشيخوخة
• معدّلات مخرجات خام قد لا تكون مرتفعة جدًّا
• أعطال يصعب ملاحظتها بدون health checks

ولذلك، يُشدّد NIST SP 800-90B على مبادئ تصميم entropy source، وتقدير min-entropy، واختبارات التحقّق، و health testing. وفي التنفيذات الكاملة، كثيرًا ما يُهيكَل النظام كلّه على شكل entropy source + DRBG، كما في NIST SP 800-90C.

بعبارة أخرى، true random ليست مادّة خامًا غامضة. هي شيء يُتعامل معه جنبًا إلى جنب مع المصادر الفيزيائيّة، والتقييم، والمراقبة، والمعالجة اللاحقة.

6. ما الذي يختلف

لا يمكن تنظيم الفرق بين مولِّدات الأرقام العشوائيّة بمجرّد السؤال هل المخرجات تبدو عشوائيّة. كحدّ أدنى، يفيد مقارنتها على هذه المحاور الأربعة.

6.1. مصدر التوليد

• pseudorandom: خوارزميّة وحالة داخليّة
• true random: entropy source فيزيائيّ

هذا أكثر الفروق جوهريّة.

6.2. قابليّة الإعادة

• pseudorandom: قابل للإعادة بالـ seed نفسه
• true random: حتّى في الظروف نفسها، يصعب إعادة المتتالية نفسها

قابليّة الإعادة قوّة في الاختبار وقد تكون ضعفًا في أمور كالسحوبات.

6.3. قابليّة التنبّؤ

• PRNG الاعتياديّ: إن أمكن استنتاج seed أو الحالة الداخليّة، فقد تصبح القيم المستقبليّة قابلة للتنبّؤ إلى حدٍّ معقول
• CSPRNG: مصمَّم بحيث تظلّ القيم المستقبليّة صعبة التنبّؤ ما دامت الحالة الداخليّة محميّة
• true random: صعب التنبّؤ إن كان المصدر الفيزيائيّ سليمًا، لكن أعطال المستشعرات وأخطاء التصميم مشكلة منفصلة

في الأمن، يكون هذا المحور هو الأهمّ. التشتّت البصريّ للمخرجات أقلّ أهمّيّة من إمكان تخمين القيمة التالية.

6.4. السرعة وقيود التشغيل

• pseudorandom: سريع، مستقرّ، وسهل التنفيذ
• true random: يتطلّب جمع entropy ومراقبتها، ما يجلب قيود سرعة وتنفيذ

ولذلك نادرًا ما تكون أنظمة الإنتاج الحقيقيّة خيارًا بسيطًا بين true random فقط و pseudorandom فقط. في الممارسة، عادةً ما تكون الإجابة الأكثر واقعيّة هي CSPRNG يُغذَّى ببذرة seed من entropy فيزيائيّ.

7. كيف نميّز بينها

7.1. لا يمكن التمييز الكامل من المخرجات وحدها عمومًا

هذه أهمّ إجابة منفردة. إن كان كلّ ما لديك هو متتالية مخرجات منتهية، فلا يمكنك إثبات أنّ هذه true random.

السبب بسيط: لأيّ متتالية منتهية تلاحظها، يمكن دائمًا كتابة برنامج deterministic يُخرِج تلك المتتالية بالضبط. وفي الحالة القصوى، يمكن ببساطة تضمين المتتالية في مصفوفة أو ROM وإعادتها قيمة تلو الأخرى.

لذا لا يمكنك القول يبدو طبيعيًّا، إذًا هو true random. ويذكر NIST SP 800-22 أيضًا أنّ الاختبار الإحصائيّ ليس سوى خطوة أولى، ولا يُثبت بمفرده صلاحيّة المُولِّد إثباتًا قاطعًا.

من الجهة الأخرى، يُصمَّم CSPRNG الجيّد عمدًا ليكون من الصعب تمييزه من مخرجاته وحدها. وبهذا المعنى، فإنّ صعوبة التمييز بحدّ ذاتها جزء من هدف التصميم.

7.2. أوّلًا، افحص تصميم المُولِّد

للتمييز بينها في الممارسة، يهمّ التصميم أكثر من المظهر السطحيّ للمخرجات. تحقّق من أمور كهذه:

• أيّ خوارزميّة توليد تُستخدَم؟
  • PRNG بسيط، أم DRBG / CSPRNG؟
• من أين يأتي seed؟
  • seed ثابت، أم الوقت الحاليّ، أم PID، أو ما شابه؟
  • أم من entropy source في نظام التشغيل؟
• هل ثمّة reseeding؟
  • seed مرّة واحدة فقط عند البدء ثم لا يتكرّر؟
  • أم reseed أثناء التشغيل أيضًا؟
• هل يجري التحقّق من entropy source؟
  • تقدير min-entropy
  • health tests
  • كشف الأعطال
• أيّ API يُستخدَم؟
  • تنفيذ مخصّص؟
  • أم API قياسيّ من نظام التشغيل أو اللغة؟

من خلال هذه العدسة، تصبح حالات كثيرة قابلة للتمييز بدرجة كافية لقرارات الهندسة:

• تثبيت seed يُعيد إنتاج المتتالية نفسها دائمًا -> pseudorandom
• يوجد entropy source فيزيائيّ ويفترض التصميم وجود تحقّق / health testing -> تصميم بمصدر true random
• يستدعي API الـ secure RNG في نظام التشغيل -> في حالات كثيرة هجين من entropy فيزيائيّ + CSPRNG

7.3. ثمّ استخدم الاختبارات الإحصائيّة للبحث عن العيوب الواضحة

الاختبار الإحصائيّ ليس عديم الفائدة. هو مهمّ. لكنّ دوره أقرب إلى كشف العيوب منه إلى الإثبات.

تشمل الأمور الاعتياديّة التي تنظر إليها:

• الانحياز في الأصفار والآحاد
• انحياز الـ runs
• الدوريّة
• الترابط
• approximate entropy
• linear complexity

يُشار عادةً إلى NIST SP 800-22، وفي اليابان إلى الحدّ الأدنى من مجموعة اختبارات الأرقام العشوائيّة من CRYPTREC. وهي مفيدة للتحقّق ممّا إذا كانت المتتالية تُظهر انحيازًا أو بنية مريبة.

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

التفسير العمليّ هو:

• النجاح: لا يبدو ثمّة عيب فاضح للوهلة الأولى
• الإخفاق: غالبًا ثمّة خطأ ما
• وعليه، أنّه ثبت أنّه true random: هذا الاستنتاج لا يتبع

7.4. للاستخدامات الأمنيّة، قِّم من زاوية المهاجم

في استخدامات كرموز إعادة تعيين كلمة المرور، أو session IDs، أو nonces، أو توليد المفاتيح، فإنّ السؤال هل هو true random؟ لا يكفي بعد.

السؤال الحقيقيّ هو هل يستطيع المهاجم التنبّؤ بالقيمة التالية.

على سبيل المثال:

• يستند seed إلى الوقت الحاليّ فقط
• يخلط فقط معرّف عمليّة أو رقمًا تسلسليًّا
• تنفيذ مخصّص بلا تقييم جادّ لجودة seed
• إعادة استخدام API على نمط random لغرض حسّاس أمنيًّا

لا يُمنع أيّ من هذه المشكلات لمجرّد أنّ المخرجات تبدو عشوائيّة بما يكفي.

كذلك توصي IPA بفهم APIs الأمن المتوفّرة والمكتبات الموجودة بدلًا من بناء مولِّد مخصّص باستخفاف. وتنصّ Python صراحة على تفضيل وحدة secrets على random للأغراض الأمنيّة. وفي Java، يؤدّي هذا الدور SecureRandom.

في النهاية، السؤال الأهمّ في الأمن ليس pseudorandom أم true random، بل هل تستخدم seed / entropy آمنين و API آمنًا؟

8. أيّها ينبغي استخدامه ولأيّ غرض

على مستوى التنفيذ، تعدّ هذه الاختيارات افتراضات آمنة عادةً:

• Windows native: BCryptGenRandom
• .NET: System.Security.Cryptography.RandomNumberGenerator
• Linux: getrandom()
• Python: secrets
• Java: SecureRandom

يوضّح Microsoft Learn أنّ Windows BCryptGenRandom يستخدم مزوّدًا افتراضيًّا متوافقًا مع NIST SP 800-90 CTR_DRBG. ويُوثَّق Linux getrandom() على أنّه مناسب لـ cryptographic purposes. وكذلك RandomNumberGenerator في .NET، و secrets في Python، و SecureRandom في Java، فهي APIs مخصّصة للعشوائيّة الحسّاسة أمنيًّا.

9. سوء الفهم الشائع

9.1. إن اجتاز اختبارات إحصائيّة، فلا بدّ أنّه true random

لا. على أبعد تقدير، يعني ذلك لا يوجد انحياز واضح يبرز فورًا.

9.2. إن كان true random، فهو دائمًا آمن

لا. عطل المصدر الفيزيائيّ، والانحياز، وعيوب التنفيذ، وغياب health tests، كلّها قد تُدهور الجودة.

9.3. كلّ الأرقام pseudo-random خطرة

لا. CSPRNGs / DRBGs هي في الواقع جوهر كثير من APIs الأرقام العشوائيّة الآمنة المستخدَمة في الممارسة.

9.4. للاستخدام الأمنيّ، يجب استخدام عشوائيّة فيزيائيّة خام مباشرة ولا شيء غيرها

ليس بالضرورة. في الممارسة، البنية المعتادة هي تركيبة من entropy source فيزيائيّ و CSPRNG.

9.5. random أو Math.random() يبعثر القيم بما يكفي، فهو مناسب للرموز

هذا يخلط بين سؤالين مختلفين. التشتّت البصريّ وعدم القابليّة للتنبّؤ ضدّ مهاجم ليسا الشيء نفسه.

10. جدول قرار عمليّ عند التردّد

عند الشكّ، يكفي عادةً هذا الترتيب من الأسئلة:

1. هل تحتاج إلى إعادة إنتاج النتيجة نفسها؟
   • نعم -> PRNG الاعتياديّ
   • لا -> تابع
2. هل ستكون مشكلة لو تمكّن مهاجم من التنبّؤ به؟
   • نعم -> secure RNG قياسيّ من نظام التشغيل / اللغة
   • لا -> اختر بناءً على متطلّبات الجودة والسرعة
3. هل تحتاج إلى مساءلة أو قابليّة تدقيق لمصدر العشوائيّة نفسه؟
   • نعم -> فكِّر في مصدر random فيزيائيّ أو خدمة معتمدة
4. هل تريد تنفيذه بنفسك؟
   • هذا الإحساس مفهوم، لكنّ RNGs يسهل الإخفاق فيها، فابدأ من API القياسيّ أوّلًا

بهذا الترتيب، تصبح القرارات عادةً أسرع كثيرًا من معاملة المسألة على أنّها مجرّد اختيار ثنائيّ بين pseudo و true.

11. الخلاصة

إن أردت أخشن ملخّص لا يزال مفيدًا عمليًّا للفرق بين pseudo-random و true random، فهو هذا:

• تُولَّد الأرقام pseudo-random بالحساب
• تستمدّ الأرقام true random entropy من ظواهر فيزيائيّة
• لكن في APIs الأرقام العشوائيّة الآمنة الواقعيّة، الفاعل الرئيس عادةً هو الطبقة الوسطى: entropy source + CSPRNG

لذا ما يهمّ ليس المظهر بل البنية.

• لا يمكنك أن تحدّد من المخرجات وحدها هل الشيء true random
• تساعد الاختبارات الإحصائيّة في كشف العيوب، لكنّها لا تُثبت الأصالة
• في الأمن، السؤال الحقيقيّ هل يمكن التنبّؤ به
• إن احتجت إلى قابليّة الإعادة، استخدم PRNG؛ وإن احتجت إلى عدم القابليّة للتنبّؤ، استخدم secure RNG القياسيّ من نظام التشغيل أو وقت تشغيل اللغة

بهذا التأطير، يمكنك الخروج من الجدل غير المفيد حول ما إذا كانت الأرقام pseudo-random مزيّفة.

12. المراجع

1. NIST SP 800-90A Rev. 1: Recommendation for Random Number Generation Using Deterministic Random Bit Generators
   الوثيقة المؤسِّسة لـ deterministic random bit generators.

2. NIST SP 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation
   تنظّم الأفكار وراء entropy sources، والتحقّق، و health testing.

3. NIST SP 800-90C: Recommendation for Random Bit Generator (RBG) Constructions
   تنظّم بنى entropy source + DRBG.

4. NIST SP 800-22 Rev. 1a: A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications
   تشرح دور الاختبار الإحصائيّ. النقطة المهمّة أنّ الاختبار خطوة أولى لا إثبات.

5. NIST Glossary: Non-deterministic Random Bit Generator (NRBG)
   مفيد للتحقّق من مصطلح NIST الأقرب إلى true random.

6. RFC 4086: Randomness Requirements for Security
   ينظّم تحذيرات حول العشوائيّة و entropy sources للاستخدام الأمنيّ.

7. Microsoft Learn: BCryptGenRandom function
   يشرح Windows secure RNG API و CTR_DRBG للمزوّد الافتراضيّ.

8. Linux man page: getrandom(2)
   API الأرقام العشوائيّة في Linux المناسب لـ cryptographic purposes.

9. Microsoft Learn: RandomNumberGenerator class
   API الـ .NET للأرقام العشوائيّة القويّة تشفيريًّا.

10. Python documentation: secrets — Generate secure random numbers for managing secrets
    المرجع الأساس للعشوائيّة الحسّاسة أمنيًّا في Python.

11. Oracle Java Documentation: SecureRandom
    يلخِّص secure RNG في Java ومعالجته لـ seed / entropy.

12. IPA: الفصل 3، القسم 3. التشفير الصعب الكسر واستخدام الأرقام pseudo-random
    مرجع يابانيّ ينظّم أهمّيّة seed، والاختبار الإحصائيّ، واستخدام API.

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

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