On Tue, Mar 13, 2018 at 12:45 AM, Nick Coghlan <ncogh...@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 _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
