[issue9216] FIPS support for hashlib

miss-islington added the comment: New changeset a08b7c3bb0ef9da32400d23b13f78245cd7a9541 by Miss Islington (bot) in branch '3.9': bpo-9216: hashlib usedforsecurity fixes (GH-20258) https://github.com/python/cpython/commit/a08b7c3bb0ef9da32400d23b13f78245cd7a9541 --

[issue9216] FIPS support for hashlib

Change by miss-islington : -- pull_requests: +19589 pull_request: https://github.com/python/cpython/pull/20320 ___ Python tracker ___

[issue9216] FIPS support for hashlib

miss-islington added the comment: New changeset 909b5714e1303357868bc5e281c1cf508d5d5a17 by Christian Heimes in branch 'master': bpo-9216: hashlib usedforsecurity fixes (GH-20258) https://github.com/python/cpython/commit/909b5714e1303357868bc5e281c1cf508d5d5a17 --

[issue9216] FIPS support for hashlib

Change by Christian Heimes : -- pull_requests: +19544 pull_request: https://github.com/python/cpython/pull/20258 ___ Python tracker ___

[issue9216] FIPS support for hashlib

Christian Heimes added the comment: Memo to me: Add whatsnew -- versions: +Python 3.10, Python 3.9 -Python 3.6, Python 3.7 ___ Python tracker ___

[issue9216] FIPS support for hashlib

STINNER Victor added the comment: > _hashlib.get_fips_mode() is not compatible with new FIPS design in OpenSSL > 3.0.0: I suggest to modify the code so the private function becomes unavailable in _hashlib on OpenSSL 3.0 and newer. What do you think? --

[issue9216] FIPS support for hashlib

Christian Heimes added the comment: _hashlib.get_fips_mode() is not compatible with new FIPS design in OpenSSL 3.0.0: The function calls 'FIPS_mode()' and 'FIPS_mode_set()' are present in OpenSSL 3.0 but always fail. You should rewrite your application to not use them.

[issue9216] FIPS support for hashlib

miss-islington added the comment: New changeset e3dfb9b967c560f4d094092dcae4a16fc9634681 by Victor Stinner in branch 'master': bpo-9216: Expose OpenSSL FIPS_mode() as _hashlib.get_fips_mode() (GH-19703) https://github.com/python/cpython/commit/e3dfb9b967c560f4d094092dcae4a16fc9634681

[issue9216] FIPS support for hashlib

STINNER Victor added the comment: Christian Heimes: "Instead if doing a FIPS test, users and applications should perform a feature test and handle the error. The approach is future-proof and can also cover crypto policies restriction like minimum key sizes." Alright, I see. Thanks for your

[issue9216] FIPS support for hashlib

Christian Heimes added the comment: I'm against exposing the function as hashlib.get_fips_mode() because it is an internal implementation detail. I don't want to confuse users or make users think that "if hashlib.get_fips_mode()" is sufficient for feature tests. For starters there are

[issue9216] FIPS support for hashlib

STINNER Victor added the comment: Petr Viktorin and Christian Heimes convinced me that it's a bad idea to expose OpenSSL FIPS_mode() as a public hashlib.get_fips_mode() function. It is too specific to OpenSSL. For example, FIPS_mode() result is a number which is specific to OpenSSL. Other

[issue9216] FIPS support for hashlib

STINNER Victor added the comment: I'm trying to understand how "portable" is it to expose OpenSSL FIPS_mode() as hashlib.get_fips_mode() which would return a boolean (True or False). It seems like FIPS is more complex than that. Other crypto libraries which implement FIPS have a different

[issue9216] FIPS support for hashlib

STINNER Victor added the comment: > I'm fine with a used_for_security flag and functions to get/set FIPS state. > Something like hashlib.get_fips_mode() is useful for testing. I proposed PR 19703 to expose OpenSSL FIPS_mode() as hashlib.get_fips_mode(). FIPS support was introduced in

[issue9216] FIPS support for hashlib

Change by STINNER Victor : -- pull_requests: +19021 pull_request: https://github.com/python/cpython/pull/19703 ___ Python tracker ___

[issue9216] FIPS support for hashlib

Change by miss-islington : -- pull_requests: +18874 pull_request: https://github.com/python/cpython/pull/19524 ___ Python tracker ___

[issue9216] FIPS support for hashlib

miss-islington added the comment: New changeset 4c0a31fb08407ba043688ad1c21102dd4cb99146 by Miro Hrončok in branch 'master': bpo-9216: Nobody expects the geohashing FIPS inquisition (GH-19520) https://github.com/python/cpython/commit/4c0a31fb08407ba043688ad1c21102dd4cb99146 -- nosy:

[issue9216] FIPS support for hashlib

Change by Miro Hrončok : -- nosy: +hroncok nosy_count: 17.0 -> 18.0 pull_requests: +18870 pull_request: https://github.com/python/cpython/pull/19520 ___ Python tracker ___

[issue9216] FIPS support for hashlib

Cheryl Sabella added the comment: Should this issue be closed as resolved? -- nosy: +cheryl.sabella ___ Python tracker ___ ___

[issue9216] FIPS support for hashlib

Christian Heimes added the comment: > FYI the multiprocessing module uses hmac.new(authkey, message, > 'md5').digest(). I don't think that using MD5 even for HMAC is allowed in > FIPS mode. MD5 us especially not allowed in FIPS mode. -- ___

[issue9216] FIPS support for hashlib

Gregory P. Smith added the comment: New changeset 7cad53e6b084435a220e6604010f1fa5778bd0b1 by Gregory P. Smith (Christian Heimes) in branch 'master': bpo-9216: Add usedforsecurity to hashlib constructors (GH-16044)

[issue9216] FIPS support for hashlib

Change by Christian Heimes : -- pull_requests: +15666 pull_request: https://github.com/python/cpython/pull/16044 ___ Python tracker ___

[issue9216] FIPS support for hashlib

STINNER Victor added the comment: FYI the multiprocessing module uses hmac.new(authkey, message, 'md5').digest(). I don't think that using MD5 even for HMAC is allowed in FIPS mode. -- nosy: +vstinner ___ Python tracker

[issue9216] FIPS support for hashlib

Charalampos Stratakis added the comment: Providing a simple keyword as a workaround for bypassing the FIPS restrictions, could potentially violate the standard, as there is no way from the python side to verify if the code in question is used for security purposes or not. Thus I would close

[issue9216] FIPS support for hashlib

Change by Charalampos Stratakis : -- pull_requests: +5374 ___ Python tracker ___ ___

[issue9216] FIPS support for hashlib

Charalampos Stratakis added the comment: @Andrew This has already been implemented downstream for RHEL and centos. -- ___ Python tracker ___

[issue9216] FIPS support for hashlib

Andrew DiPrinzio added the comment: I have been able to use this flag on RHEL and Centos. Is it possible that this has been completed? -- nosy: +Andrew DiPrinzio ___ Python tracker

[issue9216] FIPS support for hashlib

Changes by Charalampos Stratakis : -- nosy: +cstratak ___ Python tracker ___ ___

[issue9216] FIPS support for hashlib

Christian Heimes added the comment: PS: I'm also against a hashlib.fips module in stdlib. FIPS mode is irrelevant for majority of users and countries. I neither want to confuse people nor introduce more maintenance and documentation burden than necessary. Antoine gave another good reason

[issue9216] FIPS support for hashlib

Christian Heimes added the comment: Objection from hashlib maintainer: I will reject a used_for_security flag with default of False. I'm slowly moving Python to a secure-by-default policy. Therefore used_for_security must be an explicit opt-out. I'm aware that the policy will require

[issue9216] FIPS support for hashlib

Yolanda added the comment: @rbtcollins, even if we go with a FIPS aware module, we'd still need to detect if md5 was used for security purposes. If we build a system that detects FIPS enablement, call md5 say ... for generating a password, and then the python fips_md5 call is masking it, we'd

[issue9216] FIPS support for hashlib

Doug Hellmann added the comment: @Antoine - The idea behind introducing some API mechanism is exactly as you say, to let the developer say "this use of this algorithm is not related to security" to tell FIPS systems to not be pedantic. -- ___

[issue9216] FIPS support for hashlib

Doug Hellmann added the comment: @Robert, I thought you were proposing a hashlib.fips module that did not include md5() at all. If it does include the function, and the function does whatever is needed to disable the "die when using MD5" on a FIPS system, then I agree it would work. Your

[issue9216] FIPS support for hashlib

Yolanda added the comment: @rbtcollins, so you mean the apps using it, shall be "fips aware" ? That will be the point of your separate module? So... if fips_enabled then use fips.md5 else use normal.md5 -- ___ Python tracker

[issue9216] FIPS support for hashlib

Antoine Pitrou added the comment: AFAICT from David's patch, there isn't a new argument in all hashlib functions but only in the digest constructors. Someone might want to correct me. -- ___ Python tracker

[issue9216] FIPS support for hashlib

Ian Cordasco added the comment: So I see the argument on both sides of this discussion. Having those optional arguments for all the functions seems like an obvious blocker. If a submodule is a blocker, what if we provide a context-manager to signal this? -- nosy: +icordasc

[issue9216] FIPS support for hashlib

Antoine Pitrou added the comment: The separate module idea is an interesting one, though I wonder if it aligns with users' goals. Perhaps some users simply want to set the OPENSSL_FORCE_FIPS_MODE environment variable and then run existing Python code with it to ensure that code is

[issue9216] FIPS support for hashlib

Robert Collins added the comment: @doug - I don't see how a separate fips module *wouldn't* solve it: - code that uses md5 in security contexts wouldn't be able to call it from the fips module, which is the needed outcome - code that uses md5 and isn't fips compliant would be importing from

[issue9216] FIPS support for hashlib

Yolanda added the comment: I agree with Doug. From my understanding, the intention of the patch is to allow the usage of md5 for non-security purposes, without being blocked by FIPS. Right now, md5() calls running on a FIPS enabled kernel, are blocked without discrimination of the usage, that

[issue9216] FIPS support for hashlib

Doug Hellmann added the comment: @rbcollins, I don't think providing a hashlib.fips module without md5() solves the problem. The idea is to have a way to call md5() in non-secure situations, and to signal to the FIPS system that the call is OK. A separate module would work if it included an

[issue9216] FIPS support for hashlib

Robert Collins added the comment: A few thoughts; usedforsecurity=xxx seems awkward: I wouldn't want, as a user of hashlib, to have to put that in literally every use I make of it. If I understand the situation correctly, the goal is for both linters, and at runtime, identification of the

[issue9216] FIPS support for hashlib

Changes by Gregory P. Smith : -- nosy: -gregory.p.smith ___ Python tracker ___ ___

[issue9216] FIPS support for hashlib

Changes by Doug Hellmann : -- nosy: +doughellmann ___ Python tracker ___ ___

[issue9216] FIPS support for hashlib

Changes by Christian Heimes : -- versions: +Python 3.6, Python 3.7 -Python 3.4 ___ Python tracker ___

[issue9216] FIPS support for hashlib

Changes by Bohuslav Slavek Kabrda bkab...@redhat.com: -- nosy: +bkabrda ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9216 ___ ___

[issue9216] FIPS support for hashlib

Changes by Jan Pokorný pokorny_...@seznam.cz: -- nosy: +jpokorny ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9216 ___ ___ Python-bugs-list

[issue9216] FIPS support for hashlib

Christian Heimes added the comment: It's out of scope for 3.3 but I'd love to see the feature in 3.4. -- versions: -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9216 ___

[issue9216] FIPS support for hashlib

Roumen Petrov added the comment: Everything in this issue posted until now has to be managed as vendor patch. -- nosy: +rpetrov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9216 ___

[issue9216] FIPS support for hashlib

Changes by Christian Heimes li...@cheimes.de: -- nosy: +christian.heimes versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9216 ___

[issue9216] FIPS support for hashlib

Daniel Holth dho...@fastmail.fm added the comment: While you are at it, can you edit the docs to put md5() at the bottom of the page at the back of the list in a 2-point font and raise a DeprecationWarning(This function is totally lame, and it is slower than SHA-3, get with the program.) the

[issue9216] FIPS support for hashlib

Antoine Pitrou pit...@free.fr added the comment: While you are at it, can you edit the docs to put md5() at the bottom of the page at the back of the list in a 2-point font and raise a DeprecationWarning(This function is totally lame, and it is slower than SHA-3, get with the program.) the

[issue9216] FIPS support for hashlib

Antoine Pitrou pit...@free.fr added the comment: _Please_ publicise the change a little better? Pretty please!? This changes haven't been committed in Python, so you probably want to post on the Fedora bug tracker instead. -- ___ Python tracker

[issue9216] FIPS support for hashlib

Luke Carrier h...@lukecarrier.me added the comment: I've not done enough digging on the issue I'm presently experiencing to draw any conclusions make any suggestions, but this change seems to break the present distribute module (version 0.6.27). It appears it will likely break a great deal of

[issue9216] FIPS support for hashlib

Antoine Pitrou pit...@free.fr added the comment: Patch 0002: - cached_info-error_msg doesn't seem deallocated anywhere? Patch 0003: - usedforsecurity is a poor name IMO; make it shorter and/or PEP8-ize it (used_for_security) - the 2-element context array thing is obscure: why not distinct

[issue9216] FIPS support for hashlib

Gregory P. Smith g...@krypto.org added the comment: My summary of our discussion was pretty terse. :) dmalcolm has more detailed TODO list notes that include things like the error cases and .rst documentation. As for how to commit it, i'd make 0001 its own commit as it is a useful

[issue9216] FIPS support for hashlib

Gregory P. Smith g...@krypto.org added the comment: quick summary of comments from pycon sprints discussion: this looks pretty good. i like the 0001 refactoring cleanup. a couple things to fix in error handling (better messages and some bogus handling in the test). dmalcolm has the notes on

[issue9216] FIPS support for hashlib

Dave Malcolm dmalc...@redhat.com added the comment: I've refreshed this patch against the latest version of the code in hg. In an attempt to make it easier to review, I've split it up into four (so far) thematic patches, which apply in sequence. -- Added file:

[issue9216] FIPS support for hashlib

Changes by Dave Malcolm dmalc...@redhat.com: Added file: http://bugs.python.org/file23173/0002-Add-error-handling-to-initialization-of-_hashlib.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9216

[issue9216] FIPS support for hashlib

Changes by Dave Malcolm dmalc...@redhat.com: Added file: http://bugs.python.org/file23174/0003-Add-optional-usedforsecurity-argument-in-various-pla.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9216

[issue9216] FIPS support for hashlib

Changes by Dave Malcolm dmalc...@redhat.com: Added file: http://bugs.python.org/file23175/0004-_hashlib-Add-selftest-for-FIPS-mode-and-usedforsecur.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9216

[issue9216] FIPS support for hashlib

Dave Malcolm dmalc...@redhat.com added the comment: [and yes, I used git to generate the 4 patches; sorry ] -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9216 ___

[issue9216] FIPS support for hashlib

Dave Malcolm dmalc...@redhat.com added the comment: The cumulative effect of the above patches (to _hashlib) are equivalent to what I've applied downstream to python 2 in RHEL 6.0 and Fedora 17 onwards, and python 3 in Fedora 17 onwards. In those environments I've additionally patched hashlib

[issue9216] FIPS support for hashlib

Changes by Antoine Pitrou pit...@free.fr: -- versions: +Python 3.3 -Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9216 ___ ___

[issue9216] FIPS support for hashlib

Changes by R. David Murray rdmur...@bitdance.com: -- type: - feature request ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9216 ___ ___

[issue9216] FIPS support for hashlib

Dave Malcolm dmalc...@redhat.com added the comment: Attached is a patch against the py3k branch which implements this. I've checked that it builds against openssl-0.9.8o.tar.gz, openssl-1.0.0a.tar.gz, and against Fedora 12 and 13's heavily-patched openssl-1.0.0. The bulk of my testing has

[issue9216] FIPS support for hashlib

Gregory P. Smith g...@krypto.org added the comment: That sounds fine to me and I do like the usedforsecurity annotation on the API. I'll gladly review any patches. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9216

[issue9216] FIPS support for hashlib

New submission from Dave Malcolm dmalc...@redhat.com: (taking the liberty of adding gregory.p.smith to the nosy list; hope that's OK) This is a higher-level take on issue 9146. Some versions of OpenSSL have a FIPS mode that can refuse the use of non-certified hashes. The idea is that FIPS