While FWIU it is advisable to keep seeding an RNG after startup - that's what e.g. rngd does - the cryptography.io docs do advise to just use `os.urandom()` (which is not the same as random.SystemRandom()?).
There probably should be better default random in CPython; though I'm personally not at all qualified to assess, TIL about NIST 800-22 and FIPS 140-2 for evaluating sources of entropy. Differential entropy > Differential entropies for various distributions https://en.wikipedia.org/wiki/Differential_entropy *** (TIL that quantum information is never destroyed; so which physical processes are actually nonreversible like hashing and RNG are supposed to be is up for consideration as classical information is a subset of quantum information. Do black holes shift gamma radiation may actually be relevant! Perhaps a permanent magnet under a (double-jointed?) bar and ball pendulum on a magnetic bearing would produce enough Brownian motion to get enough uniform random to call it sufficiently entropic for purposes of CSPRNG? Nondeterministic NDE fluid calculations diffract into many possible outcomes, but a brute force combinatorial search of all the possible return values is still deterministically ordered. And the quantum computing folks are working on increasing coherence / reducing error propagation; like ECC.) - [ ] DOC: The docs could advise regarding which decent enough open source hw RNG would be supported by os.urandom or random.SystemRandom if rngd is not configured to keep nondeterministically seeding with entropy that should presumably be from a Uniform random entropic process There should be better software random in python. On Tue, Nov 15, 2022, 1:19 AM James Johnson <jj126...@gmail.com> wrote: > Thank you for replying with such specific assistance. I am made acutely > aware that I am only a Python enthusiast, and not an academic. > > Hashes are deterministic, not random, but byte by byte, they can be very > random. Please accept the attached script as a "hack," that might be novel, > or a curiosity. My first script was defective several ways. In this, I seed > the hash by hashing the uu-8 ENCODED string value of the time - it is not > random, but it is rarely the same twice. I used 0-9 because it is decimal, > and 0-59, because hours and minutes come in 60's. > > I found that taking time.time_nc() gave me far more odds than evens. > > I do not know how the scheme I devised of adding hex digits together would > scale to larger ranges - it is done by adding hex digits that vary from 0 - > 15 repeatedly, but, since the number of hex digits varies with the range, > it could actually work for larger ranges. > > The random function in Python is not really adequate for a magic eight > ball program, so as a consumer I am dissatisfied without examining it at a > quantum level, for repeated reference thousands of times each. > > Thank you for your kind attention, and I hope the (much improved) hack can > be helpful to other enthusiasts. > > James J > (A.A. Faulkner University) > > On Mon, Nov 14, 2022 at 11:23 AM Wes Turner <wes.tur...@gmail.com> wrote: > >> 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/XXTRFWFMBOTIM664LWASNZKCDTWP7R5U/ Code of Conduct: http://python.org/psf/codeofconduct/
