What does usedforsecurity=False do in hashlib.new("md5", usedforsecurity=False)?

### The problem the flag exists to solve CPython's `hashlib` is usually backed by the platform's OpenSSL. Some deployments — regulated environments, hardened distributions, images built for a compliance regime — configure that library to permit only approved digests. On such a build, constructing MD5 or SHA-1 fails at the constructor with a `ValueError`, before you hash a single byte. That policy is aimed at security uses, but a digest is not always a security control. MD5 shows up all over old code as a cheap non-cryptographic fingerprint: a cache key, an ETag, a shard selector, a value some other system computed years ago and still compares against. Blocking those uses breaks working software without improving anyone's security posture. `usedforsecurity` is the way to tell the two apart. It is a keyword-only parameter accepted by `hashlib.new()` and by the named constructors: ```python h = hashlib.new("md5", usedforsecurity=False) h.update(b"tile-cache-key") h.hexdigest() ``` The default is `True` — meaning "assume this matters" — and passing `False` asserts that this particular digest is not a security control, allowing the implementation to route around the restriction, typically by using CPython's built-in implementation rather than the restricted provider. ### What it does not do The flag changes **policy**, not mathematics. MD5 with `usedforsecurity=False` is exactly as collision-prone as MD5 without it: practical collisions have been constructible for many years, and SHA-1 is in the same category. So the flag is safe on a cache key and indefensible on anything that answers "is this the file I expect" against an adversary, verifies a download, deduplicates content where a collision has security meaning, or feeds a signature. Two more misconceptions are worth naming. It does not silently substitute a stronger algorithm — the digest you get is a real MD5, byte-compatible with every other MD5, which is the whole point for legacy interop. And it is not a speed knob; any performance difference is an incidental consequence of which implementation ends up being used. ### algorithms_guaranteed and the limits of "guaranteed" `hashlib.algorithms_guaranteed` is a set of names the module promises to support on every platform: the SHA-2 family, the SHA-3 family, SHAKE, BLAKE2 — and, historically, `md5` and `sha1`. Its sibling `hashlib.algorithms_available` is the larger set this particular interpreter can construct, including whatever extra digests the linked OpenSSL provides. Configuration-driven code should validate an algorithm name against one of these sets rather than trusting a string from a file. The subtlety a senior is expected to know: membership in `algorithms_guaranteed` is a promise made by the stdlib, and a hardened vendor build can still refuse to construct one of those names. So `"md5" in hashlib.algorithms_guaranteed` being `True` does not guarantee `hashlib.md5()` succeeds on the host you are actually running on. Code that must survive both kinds of build handles the `ValueError`: ```python try: h = hashlib.new(name, usedforsecurity=False) except ValueError: h = hashlib.sha256() # or fail loudly, if the legacy value is required ``` ### The judgement call Reaching for this flag is nearly always a signal about an old code path, and the right response has three parts. First, decide honestly whether that digest is a security control — if the answer is "partly" or "I am not sure", it is, and the fix is a modern algorithm, not a flag. Second, if it genuinely is a checksum, prefer moving it to SHA-256 or BLAKE2 anyway; those are guaranteed everywhere, are not policy-restricted, and BLAKE2 is typically faster than MD5 on modern hardware, so the "legacy is cheaper" argument rarely survives measurement. Third, keep `usedforsecurity=False` only where the digest value itself must stay byte-compatible with a system you do not control — and comment it with *why*, because the next reader will otherwise assume it is a security bypass. Storing the algorithm name alongside every persisted digest is what makes that eventual migration possible: without it, you cannot tell which stored values still need rehashing. ### Choosing the replacement When a legacy digest can move, the replacement is rarely a hard call. SHA-256 is the boring default and is in `hashlib.algorithms_guaranteed`. BLAKE2 is the interesting one: `hashlib.blake2b` and `hashlib.blake2s` are also guaranteed, are typically faster than MD5 on 64-bit hardware, and take a `digest_size` argument, so `hashlib.blake2b(data, digest_size=16)` gives a real 16-byte digest when storage per row genuinely matters — a proper short digest, not a truncated long one. That removes the last honest argument for keeping a weak algorithm around: it was never the cheap option, only the familiar one.