Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ensure builtin hashlib implementations honor usedforsecurity=True when _hashlib is in FIPS mode #127298

Open
xnox opened this issue Nov 26, 2024 · 3 comments
Labels
extension-modules C modules in the Modules dir topic-SSL type-feature A feature request or enhancement type-security A security issue

Comments

@xnox
Copy link

xnox commented Nov 26, 2024

Feature or enhancement

Proposal:

When OpenSSL is not available, or is not in FIPS mode:

  • no change of behaviour

When OpenSSL is available and is in FIPS mode:

  • ensure that only OpenSSL implementations are used when usedforsecurity=True
  • ensure that all built-in (fallback) implementations require usedforsecurity=False

This addresses all needs of FIPS users that expect approved only cryptography from hashlib by default.
It satisfies Python guarantees of always available algorithms, as built-in fallbacks remain accessible with an explicit consent from the user that unapproved (an FIPS/ISO term) implementation is acceptable to the user.

In FIPS mode it means that all users can gain access to blake2/shake/md5, even when these algorithms are either blocked or unavailable from the runtime OpenSSL in FIPS mode. As long as usedforsecurity=False is used.

This also removes need to recompile or configure python somehow different for a non-fips & fips build, specifically one can safely compile python with all with-builtin-hashlib-hashes enabled.

Diagrams and full details of the current state of hashlib; and FIPS user desires are documented in this issue is opened as a reference for potential implementations to resolve all needs and desires listed there.

This issue will be used as a reference for potential implementations.

Has this already been discussed elsewhere?

I have already discussed this feature proposal on Discourse

Links to previous discussion of this feature:

Discuss:

(note there are some off-topic messages there)

Linked PRs

@xnox xnox added the type-feature A feature request or enhancement label Nov 26, 2024
@picnixz
Copy link
Contributor

picnixz commented Nov 26, 2024

Didn't we have a similar feature request for that? cc @encukou (I can't find it on mobile but I remember you participated in a similar discussion)

@xnox
Copy link
Author

xnox commented Nov 26, 2024

Didn't we have a similar feature request for that? cc @encukou (I can't find it on mobile but I remember you participated in a similar discussion)

I previously opened #118224 but this issue is related; but is a different approach / design / end-goal. I don't know if you meant that one or something else.

xnox added a commit to xnox/cpython that referenced this issue Nov 26, 2024
…edforsecurity=False

When _hashlib/OpenSSL is available, and OpenSSL is in FIPS mode,
ensure that builtin (fallback) hash implementations are wrapped with a
check for usedforsecurity=False. It is likely that buitin
implementations are FIPS unapproved (either algorithm disallowed; or
the implementation not certified by NIST).

This enables strict approved-only compliance when usedforsecurity=True
on FIPS systems only.

And yet it also enables fallback access with usedforsecurity=False for
any missing (historical, disallowed or missing certified
implementation) algorithms (i.e. blake2, md5, shake/sha3) depending on
the runtime configuration of OpenSSL.
xnox added a commit to xnox/cpython that referenced this issue Nov 26, 2024
…edforsecurity=False

When _hashlib/OpenSSL is available, and OpenSSL is in FIPS mode,
ensure that builtin (fallback) hash implementations are wrapped with a
check for usedforsecurity=False. It is likely that buitin
implementations are FIPS unapproved (either algorithm disallowed; or
the implementation not certified by NIST).

This enables strict approved-only compliance when usedforsecurity=True
on FIPS systems only.

And yet it also enables fallback access with usedforsecurity=False for
any missing (historical, disallowed or missing certified
implementation) algorithms (i.e. blake2, md5, shake/sha3) depending on
the runtime configuration of OpenSSL.
xnox added a commit to xnox/cpython that referenced this issue Nov 26, 2024
…edforsecurity=False

When _hashlib/OpenSSL is available, and OpenSSL is in FIPS mode,
ensure that builtin (fallback) hash implementations are wrapped with a
check for usedforsecurity=False. It is likely that buitin
implementations are FIPS unapproved (either algorithm disallowed; or
the implementation not certified by NIST).

This enables strict approved-only compliance when usedforsecurity=True
on FIPS systems only.

And yet it also enables fallback access with usedforsecurity=False for
any missing (historical, disallowed or missing certified
implementation) algorithms (i.e. blake2, md5, shake/sha3) depending on
the runtime configuration of OpenSSL.
xnox added a commit to xnox/cpython that referenced this issue Nov 26, 2024
…edforsecurity=False

When _hashlib/OpenSSL is available, and OpenSSL is in FIPS mode,
ensure that builtin (fallback) hash implementations are wrapped with a
check for usedforsecurity=False. It is likely that buitin
implementations are FIPS unapproved (either algorithm disallowed; or
the implementation not certified by NIST).

This enables strict approved-only compliance when usedforsecurity=True
on FIPS systems only.

And yet it also enables fallback access with usedforsecurity=False for
any missing (historical, disallowed or missing certified
implementation) algorithms (i.e. blake2, md5, shake/sha3) depending on
the runtime configuration of OpenSSL.
xnox added a commit to xnox/cpython that referenced this issue Nov 26, 2024
…edforsecurity=False

When _hashlib/OpenSSL is available, and OpenSSL is in FIPS mode,
ensure that builtin (fallback) hash implementations are wrapped with a
check for usedforsecurity=False. It is likely that buitin
implementations are FIPS unapproved (either algorithm disallowed; or
the implementation not certified by NIST).

This enables strict approved-only compliance when usedforsecurity=True
on FIPS systems only.

And yet it also enables fallback access with usedforsecurity=False for
any missing (historical, disallowed or missing certified
implementation) algorithms (i.e. blake2, md5, shake/sha3) depending on
the runtime configuration of OpenSSL.
xnox added a commit to xnox/cpython that referenced this issue Nov 26, 2024
…edforsecurity=False

When _hashlib/OpenSSL is available, and OpenSSL is in FIPS mode,
ensure that builtin (fallback) hash implementations are wrapped with a
check for usedforsecurity=False. It is likely that buitin
implementations are FIPS unapproved (either algorithm disallowed; or
the implementation not certified by NIST).

This enables strict approved-only compliance when usedforsecurity=True
on FIPS systems only.

And yet it also enables fallback access with usedforsecurity=False for
any missing (historical, disallowed or missing certified
implementation) algorithms (i.e. blake2, md5, shake/sha3) depending on
the runtime configuration of OpenSSL.
xnox added a commit to xnox/cpython that referenced this issue Nov 26, 2024
…edforsecurity=False

When _hashlib/OpenSSL is available, and OpenSSL is in FIPS mode,
ensure that builtin (fallback) hash implementations are wrapped with a
check for usedforsecurity=False. It is likely that buitin
implementations are FIPS unapproved (either algorithm disallowed; or
the implementation not certified by NIST).

This enables strict approved-only compliance when usedforsecurity=True
on FIPS systems only.

And yet it also enables fallback access with usedforsecurity=False for
any missing (historical, disallowed or missing certified
implementation) algorithms (i.e. blake2, md5, shake/sha3) depending on
the runtime configuration of OpenSSL.
@picnixz picnixz added type-security A security issue extension-modules C modules in the Modules dir topic-SSL labels Nov 27, 2024
@picnixz
Copy link
Contributor

picnixz commented Nov 27, 2024

Yes, I think that's the issue I had in mind. Good to know it's not a duplicate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
extension-modules C modules in the Modules dir topic-SSL type-feature A feature request or enhancement type-security A security issue
Projects
None yet
Development

No branches or pull requests

2 participants