QRNG "Quantum Random Number Generation" -> Hardware random number generator > Physical phenomena with random properties > Quantum random properties https://en.wikipedia.org/wiki/Hardware_random_number_generator#Quantum_random_properties
FWIW, SciPy and SymPy have various non-CSPRNG random distributions: - https://docs.scipy.org/doc/scipy/reference/stats.html - https://docs.scipy.org/doc/scipy/reference/generated/scipy.stats.uniform.html#scipy.stats.uniform - https://docs.sympy.org/latest/modules/stats.html - https://docs.sympy.org/latest/modules/stats.html#sympy.stats.Uniform - https://docs.sympy.org/latest/modules/stats.html#sympy.stats.DiscreteUniform "RFC 8937: Randomness Improvements for Security Protocols" (2020) https://www.rfc-editor.org/rfc/rfc8937.html *** FWIW, UUIDs and W3C DIDs require entropy e.g. from a CSPRNG or better: https://www.w3.org/TR/did-core/#terminology : > Universally Unique Identifier (UUID) > A type of globally unique identifier defined by [RFC4122]. UUIDs are similar to DIDs in that they do not require a centralized registration authority. UUIDs differ from DIDs in that they are not resolvable or cryptographically-verifiable On Mon, Nov 14, 2022, 11:54 AM Wes Turner <wes.tur...@gmail.com> wrote: > https://docs.python.org/3/library/random.html : > > > Warning: The pseudo-random generators of this module should not be used > for security purposes. For security or cryptographic uses, see the secrets > module > > https://docs.python.org/3/library/secrets.html#module-secrets > > PEP 506 – Adding A Secrets Module To The Standard Library > https://peps.python.org/pep-0506/#alternatives > https://github.com/python/peps/blob/main/pep-0506.txt > > PEP 12: new PEP template: > https://github.com/python/peps/blob/main/pep-0012/pep-NNNN.rst > > Pseudorandom number generator > Cryptographic PRNGs > > https://en.wikipedia.org/wiki/Pseudorandom_number_generator#Cryptographic_PRNGs > > Random number generator attack > Defenses > https://en.wikipedia.org/wiki/Random_number_generator_attack#Defenses > > > /? CSPRNG > https://www.google.com/search?q=CSPRNG > > From "THE LINUX CSPRNG IS NOW GOOD!" > https://words.filippo.io/dispatches/linux-csprng/ : > > > [ get random() is from OpenBSD and LibreSSL ] > > > Performance and ChaCha20 > > Some people would say they needed a userspace CSPRNG for PERFORMANCE. I > never really believed most of them, but to be fair Linux was using a kinda > slow SHA-1 extractor back then. However, since Linux 4.8 (2016) the default > getrandom(2) source is a fast ChaCha20-based CSPRNG, with separate pools > per NUMA node to avoid contention. (Just ignore the rude comments in the > code about applications not running their own CSPRNG, this is still Linux > after all.) > > > > There's even a neat trick XOR'ing some of the CSPRGN output back into > the ChaCha20 state to prevent an attacker from recovering any past output > from before the time of compromise. > > > > Some of these improvements came along thanks to the Wireguard work by > Jason A. Donenfeld > > "Problems emerge for a unified /dev/*random" (2022) > https://lwn.net/Articles/889452/ > > From > https://www.redhat.com/en/blog/understanding-red-hat-enterprise-linux-random-number-generator-interface > : > > """ > How does the kernel initialize its CSPRNG? > The kernel has an “entropy pool,” a place where unpredictable input > observed by the kernel is mixed and stored. That pool serves as a seed to > the internal CSPRNG, and until some threshold of estimated entropy is > reached initially, it is considered uninitialized. > > Let’s now see how the kernel initializes its entropy pool. > > 1. After the kernel takes control on power-on, it starts filling its > entropy pool by mixing interrupt timing and other unpredictable input. > > 2. The kernel gives control to systemd. > > 3. Next, systemd starts and initializes itself. > > 4. Systemd, optionally, loads kernel modules which will improve the > kernel's entropy gathering process on a virtual machine (e.g., virtio-rng). > > 5. Systemd loads the rngd.service which will gather additional input > entropy obtained via a random generator exposed by hardware (e.g., the x86 > RDRAND instruction or similar) and jitter entropy1; this entropy is fed > back into the kernel to initialize its entropy pool, typically in a matter > of milliseconds. > > After the last step, the kernel has its entropy pool initialized, and any > systemd services started can take advantage of the kernel’s random > generator. > > Note that the virtio-rng kernel module loading in step (3), is an optional > step which improves entropy gathering in a virtual machine by using the > host's random generator to initialize the guest systems in KVM. The > rngd.service loading at the final step (4) is what ensures that the kernel > entropy pools are initialized on every scenario, and furthermore it > continues mixing additional data in the kernel pool during system runtime. > """ > > https://github.com/nhorman/rng-tools/blob/master/fips.c : > > ```c > /* fips.c -- Performs FIPS 140-1/140-2 RNG tests > ``` > > /? FIPS 140-1/140-2 RNG tests > https://www.google.com/search?q=FIPS+140-1%2F140-2+RNG+tests > > /? CMVP "cprng" > https://www.google.com/search?q=CMVP+%22cprng%22 > https://csrc.nist.gov/publications/detail/fips/140/3/final > > https://www.google.com/search?q=rng+tests > > - https://www.johndcook.com/blog/rng-testing/ : > > > We test RNGs using the standard test suites: PractRand, TestU01 > (BigCrush), DIEHARD(ER), NIST SP 800-22. > > Randomness tests: > > https://en.wikipedia.org/wiki/Randomness_test#Notable_software_implementations > : > - https://en.wikipedia.org/wiki/Diehard_tests > - https://en.wikipedia.org/wiki/TestU01 > - /? NIST 800-22 https://www.google.com/search?q=nist+800-22 > > /? nist 800-22 site:github.com > https://www.google.com/search?q=nist+800-22+site%3Agithub.com > > - > https://github.com/google/paranoid_crypto/blob/main/docs/randomness_tests.md > > > From https://cryptography.io/en/latest/random-numbers/ > https://github.com/pyca/cryptography/blob/main/docs/random-numbers.rst : > > > ```rst > Random number generation > ======================== > > When generating random data for use in cryptographic operations, such as an > initialization vector for encryption in > :class:`~cryptography.hazmat.primitives.ciphers.modes.CBC` mode, you do not > want to use the standard :mod:`random` module APIs. This is because they > do not > provide a cryptographically secure random number generator, which can > result in > major security issues depending on the algorithms in use. > > Therefore, it is our recommendation to `always use your operating system's > provided random number generator`_, which is available as > :func:`os.urandom`. > For example, if you need 16 bytes of random data for an initialization > vector, > you can obtain them with: > > .. doctest:: > > >>> import os > >>> iv = os.urandom(16) > > This will use ``/dev/urandom`` on UNIX platforms, and ``CryptGenRandom`` on > Windows. > > If you need your random number as an integer (for example, for > :meth:`~cryptography.x509.CertificateBuilder.serial_number`), you can use > ``int.from_bytes`` to convert the result of ``os.urandom``: > > .. code-block:: pycon > > >>> serial = int.from_bytes(os.urandom(20), byteorder="big") > > In addition, the `Python standard library`_ includes the ``secrets`` > module, > which can be used for generating cryptographically secure random numbers, > with > specific helpers for text-based formats. > > .. _`always use your operating system's provided random number generator`: > https://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ > .. _`Python standard library`: > https://docs.python.org/3/library/secrets.html > > ``` > > > On Mon, Nov 14, 2022, 10:57 AM Barry <ba...@barrys-emacs.org> wrote: > >> >> >> > On 14 Nov 2022, at 14:31, James Johnson <jj126...@gmail.com> wrote: >> > >> > >> > I wrote the attached python (3) code to improve on existing prng >> functions. I used the time module for one method, which resulted in >> disproportionate odd values, but agreeable means. >> > >> > I used the hashlib module for the second. It is evident that the code >> is amateur, but the program might result in better PRN generation. >> > >> > The "app" lends itself to checking, using statistical tools (see >> comments.) >> >> Have you used any cryptographic tools to prove the quality of your PRNG? >> What results did you get? >> How does your PRNG compare to what python already has? >> >> Without that this analysis this will be unlikely to be considered as a >> candidate for python stdlib. >> >> Barry >> >> > >> > I remain a fan, >> > >> > James Johnson >> > <testrandom.py> >> > _______________________________________________ >> > Python-ideas mailing list -- python-ideas@python.org >> > To unsubscribe send an email to python-ideas-le...@python.org >> > https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> > Message archived at >> https://mail.python.org/archives/list/python-ideas@python.org/message/VENAT2YTVYVHTBSEVHHMIURCU6MG2CEO/ >> > Code of Conduct: http://python.org/psf/codeofconduct/ >> >> _______________________________________________ >> Python-ideas mailing list -- python-ideas@python.org >> To unsubscribe send an email to python-ideas-le...@python.org >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-ideas@python.org/message/HWQV4AKQAUM7CY4NWS2IRIVLRAYMKR3V/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> >
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XPU24VJKOZVAOQ2AZYP6OIC5HL7NWA2G/ Code of Conduct: http://python.org/psf/codeofconduct/
