[Python-ideas] PEP 506: some thoughts on the output length of token_bytes (and why I think it should be split in half)

Chris Angelico rosuav at gmail.com
Mon Mar 12 10:07:50 EDT 2018


On Tue, Mar 13, 2018 at 12:45 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> As it is though, I think you've made the case for a docs change to make it
> explicit that 16 bytes of entropy is almost certainly going to be fine for
> practical purposes (which will benefit all users of 3.6+), but not for a
> reduction in the actual default (which would require invoking the "Hey, we
> said we might change it at any time!" caveat on the default length, and we
> included that caveat because we weren't sure of the potential future
> security implications of quantum computing, not because 32 byte tokens are
> harder to read than 16 byte ones)

+1 on the docs change.

Is there value in exposing a couple of guiding constants
secrets.DEFAULT_ENTROPY and secrets.MINIMUM_ENTROPY ? The former is
already present (and would simply be documented as public), and the
latter would be "whatever seems like a basic minimum", such that MIN
<= DEFAULT, and the two of them could be increased at any time
(together or independently). For applications where readability and
practicality are more important than absolute best quality security,
secrets.token_hex(secrets.MINIMUM_ENTROPY) would be future-proofed
while still being shorter than secrets.token_hex().

Unlike the pure docs change, this would only benefit users of 3.8+ (or
maybe 3.7+ if this is considered a trivial change), but it'd give a
way to avoid hardcoding a length that might later be considered weak.

ChrisA


More information about the Python-ideas mailing list