iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add default entropy.

This commit is contained in:
Steven D'Aprano 2015-10-05 03:11:17 +11:00
parent 2e7f441334
commit 31d76ee55a
1 changed files with 50 additions and 46 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

96
pep-0506.txt
View File

@ -159,14 +159,19 @@ implementation::
def randbelow(exclusive_upper_bound):
return _sysrand._randbelow(exclusive_upper_bound)
def token_bytes(nbytes=32):
DEFAULT_ENTROPY = 32 # bytes
def token_bytes(nbytes=None):
if nbytes is None:
nbytes = DEFAULT_ENTROPY
return os.urandom(nbytes)
def token_hex(nbytes=32):
def token_hex(nbytes=None):
return binascii.hexlify(token_bytes(nbytes)).decode('ascii')
def token_url(nbytes=32):
return base64.urlsafe_b64encode(token_bytes(nbytes)).decode('ascii')
def token_url(nbytes=None):
tok = token_bytes(nbytes)
return base64.urlsafe_b64encode(tok).rstrip(b'=').decode('ascii')
The ``secrets`` module itself will be pure Python, and other Python
@ -176,18 +181,17 @@ necessary.
Default arguments
~~~~~~~~~~~~~~~~~
One difficult question is "How many bytes should my token be?" We can help
with this question by giving the "token_*" functions a sensible default for
the ``nbytes`` argument. This default value should be large enough to be
expected to be secure for medium-security uses [xxx]_.
It is expected that future versions will need to increase those default
values, possibly even during
One difficult question is "How many bytes should my token be?". We can
help with this question by providing a default amount of entropy for the
"token_*" functions. If the ``nbytes`` argument is None or not given, the
default entropy will be used. This default value should be large enough
to be expected to be secure for medium-security uses, but is expected to
change in the future, possibly even in a maintenance release [13]_.
Naming conventions
~~~~~~~~~~~~~~~~~~
One question is the naming conventions used in the module [13]_, whether to
One question is the naming conventions used in the module [14]_, whether to
use C-like naming conventions such as "randrange" or more Pythonic names
such as "random_range".
@ -200,7 +204,7 @@ Alternatives
============
One alternative is to change the default PRNG provided by the ``random``
module [14]_. This received considerable scepticism and outright opposition:
module [15]_. This received considerable scepticism and outright opposition:
* There is fear that a CSPRNG may be slower than the current PRNG (which
in the case of MT is already quite slow).
@ -219,12 +223,12 @@ module [14]_. This received considerable scepticism and outright opposition:
* Demonstrated attacks against MT are typically against PHP applications.
It is believed that PHP's version of MT is a significantly softer target
than Python's version, due to a poor seeding technique [15]_. Consequently,
than Python's version, due to a poor seeding technique [16]_. Consequently,
without a proven attack against Python applications, many people object
to a backwards-incompatible change.
Nick Coghlan made an earlier suggestion for a globally configurable PRNG
which uses the system CSPRNG by default [16]_, but has since withdrawn it
which uses the system CSPRNG by default [17]_, but has since withdrawn it
in favour of this proposal.
@ -233,7 +237,7 @@ Comparison To Other Languages
* PHP
PHP includes a function ``uniqid`` [17]_ which by default returns a
PHP includes a function ``uniqid`` [18]_ which by default returns a
thirteen character string based on the current time in microseconds.
Translated into Python syntax, it has the following signature::
@ -244,7 +248,7 @@ Comparison To Other Languages
applications use it for that purpose (citation needed).
PHP 5.3 and better also includes a function ``openssl_random_pseudo_bytes``
[18]_. Translated into Python syntax, it has roughly the following
[19]_. Translated into Python syntax, it has roughly the following
signature::
def openssl_random_pseudo_bytes(length:int)->Tuple[str, bool]
@ -256,16 +260,16 @@ Comparison To Other Languages
* Javascript
Based on a rather cursory search [19]_, there do not appear to be any
Based on a rather cursory search [20]_, there do not appear to be any
well-known standard functions for producing strong random values in
Javascript, although there may be good quality third-party libraries.
Standard Javascript doesn't seem to include an interface to the
system CSPRNG either, and people have extensively written about the
weaknesses of Javascript's ``Math.random`` [20]_.
weaknesses of Javascript's ``Math.random`` [21]_.
* Ruby
The Ruby standard library includes a module ``SecureRandom`` [21]_
The Ruby standard library includes a module ``SecureRandom`` [22]_
which includes the following methods:
* base64 - returns a Base64 encoded random string.
@ -287,13 +291,13 @@ What Should Be The Name Of The Module?
There was a proposal to add a "random.safe" submodule, quoting the Zen
of Python "Namespaces are one honking great idea" koan. However, the
author of the Zen, Tim Peters, has come out against this idea [22]_, and
author of the Zen, Tim Peters, has come out against this idea [23]_, and
recommends a top-level module.
In discussion on the python-ideas mailing list so far, the name "secrets"
has received some approval, and no strong opposition.
There is already an existing third-party module with the same name [23]_,
There is already an existing third-party module with the same name [24]_,
but it appears to be unused and abandoned.
@ -305,9 +309,9 @@ Frequently Asked Questions
A: The consensus among security professionals is that MT is not safe
in security contexts. It is not difficult to reconstruct the internal
state of MT [24]_ [25]_ and so predict all past and future values. There
state of MT [25]_ [26]_ and so predict all past and future values. There
are a number of known, practical attacks on systems using MT for
randomness [26]_.
randomness [27]_.
While there are currently no known direct attacks on applications
written in Python due to the use of MT, there is widespread agreement
@ -318,7 +322,7 @@ Frequently Asked Questions
A: No. This is a "batteries included" solution, not a full-featured
"nuclear reactor". It is intended to mitigate against some basic
security errors, not be a solution to all security-related issues. To
quote Nick Coghlan referring to his earlier proposal [27]_::
quote Nick Coghlan referring to his earlier proposal [28]_::
"...folks really are better off learning to use things like
cryptography.io for security sensitive software, so this change
@ -329,10 +333,10 @@ Frequently Asked Questions
* Q: What about a password generator?
A: The consensus is that the requirements for password generators are too
variable for it to be a good match for the standard library [28]_. No
variable for it to be a good match for the standard library [29]_. No
password generator will be included in the initial release of the
module, instead it will be given in the documentation as a recipe (à la
the recipes in the ``itertools`` module) [29]_.
the recipes in the ``itertools`` module) [30]_.
References
@ -367,46 +371,46 @@ References
.. [12] https://github.com/pyca/cryptography/issues/2347
.. [xx] See discussion thread starting with
https://mail.python.org/pipermail/python-ideas/2015-September/036509.html
.. [13] https://mail.python.org/pipermail/python-ideas/2015-September/036517.html
https://mail.python.org/pipermail/python-ideas/2015-September/036515.html
.. [13] https://mail.python.org/pipermail/python-ideas/2015-September/036474.html
.. [14] https://mail.python.org/pipermail/python-ideas/2015-September/036474.html
.. [14] Link needed.
.. [15] Link needed.
.. [15] By default PHP seeds the MT PRNG with the time (citation needed),
.. [16] By default PHP seeds the MT PRNG with the time (citation needed),
which is exploitable by attackers, while Python seeds the PRNG with
output from the system CSPRNG, which is believed to be much harder to
exploit.
.. [16] http://legacy.python.org/dev/peps/pep-0504/
.. [17] http://legacy.python.org/dev/peps/pep-0504/
.. [17] http://php.net/manual/en/function.uniqid.php
.. [18] http://php.net/manual/en/function.uniqid.php
.. [18] http://php.net/manual/en/function.openssl-random-pseudo-bytes.php
.. [19] http://php.net/manual/en/function.openssl-random-pseudo-bytes.php
.. [19] Volunteers and patches are welcome.
.. [20] Volunteers and patches are welcome.
.. [20] http://ifsec.blogspot.fr/2012/05/cross-domain-mathrandom-prediction.html
.. [21] http://ifsec.blogspot.fr/2012/05/cross-domain-mathrandom-prediction.html
.. [21] http://ruby-doc.org/stdlib-2.1.2/libdoc/securerandom/rdoc/SecureRandom.html
.. [22] http://ruby-doc.org/stdlib-2.1.2/libdoc/securerandom/rdoc/SecureRandom.html
.. [22] https://mail.python.org/pipermail/python-ideas/2015-September/036254.html
.. [23] https://mail.python.org/pipermail/python-ideas/2015-September/036254.html
.. [23] https://pypi.python.org/pypi/secrets
.. [24] https://pypi.python.org/pypi/secrets
.. [24] https://jazzy.id.au/2010/09/22/cracking_random_number_generators_part_3.html
.. [25] https://jazzy.id.au/2010/09/22/cracking_random_number_generators_part_3.html
.. [25] https://mail.python.org/pipermail/python-ideas/2015-September/036077.html
.. [26] https://mail.python.org/pipermail/python-ideas/2015-September/036077.html
.. [26] https://media.blackhat.com/bh-us-12/Briefings/Argyros/BH_US_12_Argyros_PRNG_WP.pdf
.. [27] https://media.blackhat.com/bh-us-12/Briefings/Argyros/BH_US_12_Argyros_PRNG_WP.pdf
.. [27] https://mail.python.org/pipermail/python-ideas/2015-September/036157.html
.. [28] https://mail.python.org/pipermail/python-ideas/2015-September/036157.html
.. [28] https://mail.python.org/pipermail/python-ideas/2015-September/036476.html
.. [29] https://mail.python.org/pipermail/python-ideas/2015-September/036476.html
https://mail.python.org/pipermail/python-ideas/2015-September/036478.html
.. [29] https://mail.python.org/pipermail/python-ideas/2015-September/036488.html
.. [30] https://mail.python.org/pipermail/python-ideas/2015-September/036488.html
Copyright