René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Unify recognization of message digest names for `_hashlib` and `_hmac`","articleBody":"# Feature or enhancement\n\nWhen calling `hmac.new(key, digestmod=HASH)`, the `HASH` can be:\n\n- a named algorithm recognized by `hashlib.new`, (e.g., `sha256`); \n- a digest constructor (e.g., `hashlib.openssl_sha256`);\n- an object supporting PEP-247.\n\nIn #130157, I've only supported named algorithms as HACL* only supports named algorithms. When using OpenSSL HMAC instead of HACL* HMAC, determining which hash function to use from HASH is left to the `hashlib` C implementation, which itself delegates this task to OpenSSL based on NIDs.\n\nI'm creating this issue so that we can brainstorm and decide how we should make HACL* HMAC able to also possibly detect objects supporting PEP-247. I plan to first upgrade the HMAC documentation:\n\n\u003e Return a new hmac object. *key* is a bytes or bytearray object giving the secret key. If *msg* is present, the method call *update(msg)* is made. *digestmod* is the digest name, digest constructor or module for the HMAC object to use. It may be any name suitable to [hashlib.new()](https://docs.python.org/3/library/hashlib.html#hashlib.new). Despite its argument position, it is required.\n\nAs you may see, the terms \"digest constructor\" and \"module\" are not well-defined. So I first plan to explain these two. In a second phase, I plan to extract the code in `_hashopenssl.c` responsible for determining whether a name is known or not in a separate module so that it can be shared with the HMAC C implementation later. The idea is to ease the future transition where we would drop OpenSSL (but this is still not planned nor decided, and this would likely require a PEP) and entirely rely on HACL* instead, both for speed and security.\n\nSome questions we need to address before letting HACL* HMAC support non-named algorithms:\n\n- Should we restrict digest constructors to HACL* ones only or not?\n- If not, should we consider `hashlib.openssl_sha256` equivalent to using HACL* SHA-256?\n- If not again, should we fallback to a generic implementation of HMAC which directly calls that callable\n\nCurrently, passing a digest constructor to the (OpenSSL) C implementation does not mean that we're using it. We're actually using it to recover the algorithm name, so it can regarded as an alias.\n\nOTOH, in the **Python** implementation of HMAC, any callable is considered a digest constructor and will be used as is. In some sense, it's a way to have HMAC implemented using an arbitrary hash function (HMAC is designed as such).\n\n\u003c!-- gh-linked-prs --\u003e\n### Linked PRs\n* gh-136995\n* gh-137301\n* gh-137307\n* gh-137319\n\u003c!-- /gh-linked-prs --\u003e\n","author":{"url":"https://github.com/picnixz","@type":"Person","name":"picnixz"},"datePublished":"2025-03-29T10:48:28.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":1},"url":"https://github.com/131876/cpython/issues/131876"}