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/LD2TFTNWACW5RATOKTLCZ4GZOV7M54YZ/ Code of Conduct: http://python.org/psf/codeofconduct/
