[Python-Dev] Re: [slightly OT] cryptographically strong random.SystemRandom()

2021-07-12 Thread Dan Stromberg 
On Fri, Jul 9, 2021 at 2:26 PM Tim Peters  wrote:

> [Ethan Furman]
> > A question [1] has arisen about the viability of `random.SystemRandom` in
> > Pythons before and after the secrets module was introduced
> > (3.5 I think) -- specifically
> >
> >  does it give independent and uniform discrete distribution for
> >  cryptographic purposes across CPython 3.x versions?
> >
> > ,,,
> > [1] https://stackoverflow.com/q/68319071/208880
>
> `secrets` is just a wrapper around `random.SystemRandom`, so the
> presence or absence of `secrets` doesn't matter.
>
> As to SystemRandom, all answers depend on the quality of the platform
> os.urandom(), which Python has no control over. See my answer here,
> and the comments on it:
>
>
> https://stackoverflow.com/questions/20936993/how-can-i-create-a-random-number-that-is-cryptographically-secure-in-python/20937265#20937265
>

It looks like CPython could do better on Windows: SystemRandom (because of
os.urandom()) is good on Linux and mac, but on Windows they use the
CryptGenRandom deprecated API

Supporting detail:
https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptgenrandom

Should I open an issue?
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/QP4EFVS66JMNXRADYKPW4YOI4PDCD6OU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [slightly OT] cryptographically strong random.SystemRandom()

2021-07-12 Thread Steve Dower 

On 7/12/2021 4:11 PM, Dan Stromberg wrote:
It looks like CPython could do better on Windows: SystemRandom (because 
of os.urandom()) is good on Linux and mac, but on Windows they use the 
CryptGenRandom deprecated API


Supporting detail: 
https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptgenrandom 



Should I open an issue?


Please do, but note that the API is only deprecated because it was not 
very extensible and the new API is much more comple... er... extensible.


There's nothing wrong with the randomness from the function. It'll be 
using the new API under the covers. So this is an enhancement, not a 
security issue, and should only target 3.11.


Cheers,
Steve
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/N6K3GLAEOXYFAJY5S4Z6APUCKXVYTIEV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [slightly OT] cryptographically strong random.SystemRandom()

2021-07-12 Thread Wes Turner 
"PEP 543 -- A Unified TLS API for Python" could specify a [CS][P][RNG]
interface that could be used instead of os.urandom, which is probably also
wrong.

PEP 543 compares  OpenSSL, SecureTransport, SChannel, and NSS; which
presumably all have some sort of a CSPRNG function that may or may not need
to be initialized with state and paramaetrs.

https://wiki.openssl.org/index.php/Random_Numbers#Generation

Hopefully, hardware support for RNGs that OpenSSL already has is already
functionally extant in the various OSes as well:
https://wiki.openssl.org/index.php/Random_Numbers#Hardware

https://en.wikipedia.org/wiki//dev/random

On Sat, Jul 10, 2021 at 7:54 PM Wes Turner  wrote:

> * Citation: https://cryptography.io/en/latest/random-numbers/
>
> On Sat, Jul 10, 2021 at 7:53 PM Wes Turner  wrote:
>
>> FWIW, here is what https://cryptography.io has re: random (/? rng python
>> cryptography)
>>
>> ```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")
>>
>> Starting with Python 3.6 the `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/
>> .. _`standard library includes`:
>> https://docs.python.org/3/library/secrets.html
>> ```
>>
>> - https://docs.python.org/3/library/random.html
>> - https://docs.python.org/3/library/random.html#random.SystemRandom
>>   - https://docs.python.org/3/library/os.html#os.urandom (see below for
>> the docs)
>> - https://docs.python.org/3/library/secrets.html
>> -
>> https://numpy.org/doc/stable/reference/random/generator.html#simple-random-data
>> -
>> https://docs.scipy.org/doc/scipy/reference/tutorial/stats/discrete.html#discrete-distributions-in-scipy-stats
>>   -
>> https://docs.scipy.org/doc/scipy/reference/tutorial/stats/discrete_randint.html
>> - https://docs.python.org/3/library/os.html#os.urandom :
>>
>> ```rst
>> Random numbers
>> --
>>
>>
>> .. function:: getrandom(size, flags=0)
>>
>>Get up to *size* random bytes. The function can return less bytes than
>>requested.
>>
>>These bytes can be used to seed user-space random number generators or
>> for
>>cryptographic purposes.
>>
>>``getrandom()`` relies on entropy gathered from device drivers and
>> other
>>sources of environmental noise. Unnecessarily reading large quantities
>> of
>>data will have a negative impact on  other users  of the
>> ``/dev/random`` and
>>``/dev/urandom`` devices.
>>
>>The flags argument is a bit mask that can contain zero or more of the
>>following values ORed together: :py:data:`os.GRND_RANDOM` and
>>:py:data:`GRND_NONBLOCK`.
>>
>>See also the `Linux getrandom() manual page
>>`_.
>>
>>.. availability:: Linux 3.17 and newer.
>>
>>.. versionadded:: 3.6
>>
>> .. function:: urandom(size)
>>
>>Return a string of *size* random bytes suitable for cryptographic use.
>>
>>This function returns random bytes from an OS-specific randomness
>> source.  The
>>returned data should be unpredictable enough for cryptographic
>> applications,
>>though its exact quality depends on the OS implementation.
>>
>>On Linux, if the ``getrandom()`` syscall is available, it is used in
>>blocking mode: block until the system urandom entropy pool is
>> initialized
>>(128 bits of entropy are collected by the kernel). See the :pep:`524`
>> for
>>the rationale. On Linux, the :func:`getrandom` function can be used to
>> get
>>random bytes in non-blocking mode (using the :data:`GRND_NONBLOCK`
>> flag) or
>>

[Python-Dev] Re: [slightly OT] cryptographically strong random.SystemRandom()

2021-07-12 Thread Dan Stromberg 
On Mon, Jul 12, 2021 at 8:37 AM Steve Dower  wrote:

> On 7/12/2021 4:11 PM, Dan Stromberg wrote:
> > It looks like CPython could do better on Windows: SystemRandom (because
> > of os.urandom()) is good on Linux and mac, but on Windows they use the
> > CryptGenRandom deprecated API
> >
> > Supporting detail:
> >
> https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptgenrandom
> > <
> https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptgenrandom
> >
> >
> > Should I open an issue?
>
> Please do, but note that the API is only deprecated because it was not
> very extensible and the new API is much more comple... er... extensible.
>
> There's nothing wrong with the randomness from the function. It'll be
> using the new API under the covers. So this is an enhancement, not a
> security issue, and should only target 3.11.
>

I created https://bugs.python.org/issue44611 for this.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/C3QBAG3YHBJSJQ5MO32TFN6R6PBYKEKD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [slightly OT] cryptographically strong random.SystemRandom()

2021-07-12 Thread Thomas Grainger 
https://docs.microsoft.com/en-us/windows/win32/seccng/cng-portal ?

On Mon, 12 Jul 2021, 23:18 Dan Stromberg,  wrote:

>
> On Mon, Jul 12, 2021 at 8:37 AM Steve Dower 
> wrote:
>
>> On 7/12/2021 4:11 PM, Dan Stromberg wrote:
>> > It looks like CPython could do better on Windows: SystemRandom (because
>> > of os.urandom()) is good on Linux and mac, but on Windows they use the
>> > CryptGenRandom deprecated API
>> >
>> > Supporting detail:
>> >
>> https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptgenrandom
>> > <
>> https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptgenrandom
>> >
>> >
>> > Should I open an issue?
>>
>> Please do, but note that the API is only deprecated because it was not
>> very extensible and the new API is much more comple... er... extensible.
>>
>> There's nothing wrong with the randomness from the function. It'll be
>> using the new API under the covers. So this is an enhancement, not a
>> security issue, and should only target 3.11.
>>
>
> I created https://bugs.python.org/issue44611 for this.
>
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/C3QBAG3YHBJSJQ5MO32TFN6R6PBYKEKD/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/JSLZGO3TZUDLSS3VJHE2WHKEBUDWJLPH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: From the SC (was Re: Enum -- last call for comments on 3.10 changes)

2021-07-12 Thread Ethan Furman 

On 7/11/21 4:00 PM, Miro Hrončok wrote:
> On 07. 07. 21 3:58, Ethan Furman wrote:

>> I was unable to revert just the str and repr changes in the time available 
as many of them were
>> integral to fixes and improvements made to Flag.  As a result the enum in 
3.10 will be the same
>> as 3.9 (complete module reversion).
>
> I see the revert was merged with the "skip news" label. The changelog now 
mentions the original
> change, but not the revert.
>
> Is it possible to mention this retroactively in the 3.10.0b4 changelog, or is 
that frozen now?
> I think it's important to document this for maintainers of codebases that 
already adapted their
> code to the new behavior with an if Python version >= 3.10 conditional.

Thanks for bringing that up, a new news entry has been added.

--
~Ethan~
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/RXFYYX74WVI5ALUNJUL645EANUVFNU6G/
Code of Conduct: http://python.org/psf/codeofconduct/