Mailman 3 - Cryptography-dev

[Security] cryptography — PBKDF2HMAC(iterations=0) triggers uncatchable PanicException (DoS)
by Amartya Jha March 10, 2026

March 10, 2026

To the Python Cryptographic Authority / cryptography maintainers, I am a security researcher at CodeAnt AI. I have discovered a denial-of-service vulnerability in the cryptography package's PBKDF2HMAC key derivation function. When iterations=0 is passed, the Rust backend raises a pyo3_runtime.PanicException, a direct subclass of BaseException, not Exception — which silently escapes all standard Python exception handlers and can crash the application process. Package: cryptography Affected Versions: All modern versions (36.x through 46.x) using the PyO3/Rust backend Tested Version: 46.0.5 CVSS: 5.3 MEDIUM (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L) CWE: CWE-703 (Improper Check or Handling of Exceptional Conditions), CWE-20 (Improper Input Validation) --- What is the Issue? PBKDF2HMAC.__init__() in cryptography/hazmat/primitives/kdf/pbkdf2.py stores the iterations parameter directly without any bounds validation: def __init__(self, algorithm, length, salt, iterations, backend=None): ... self._iterations = iterations # stored directly, no bounds check When derive() is called with iterations=0, this value is passed to the Rust layer in src/rust/src/backend/kdf.rs:30, which calls .unwrap() on the OpenSSL error rather than propagating it via map_err. This causes a Rust panic: thread '<unnamed>' panicked at src/rust/src/backend/kdf.rs:30:87: called `Result::unwrap()` on an `Err` value: ErrorStack([Error { code: 478150779, library: "Provider routines", function: "kdf_pbkdf2_set_ctx_params", reason: "invalid iteration count", file: "providers/implementations/kdfs/pbkdf2.c", line: 305 }]) PyO3 surfaces Rust panics as pyo3_runtime.PanicException. This class inherits from BaseException, NOT Exception: pyo3_runtime.PanicException → BaseException → object --- What is the Impact? 1. Process crash via DoS: Any application that accepts a user-controlled iterations value and passes it to PBKDF2HMAC (e.g., via JSON API payload, config file, URL parameter, or database-stored value) can be crashed by a single request with iterations=0. 2. Silent bypass of all error handling: The universally expected Python idiom "except Exception:" does NOT catch BaseException subclasses. Every standard web framework error handler, request handler, and try/except block in the application stack silently fails to catch this crash: try: kdf = PBKDF2HMAC(algorithm=hashes.SHA256(), length=32, salt=b"salt", iterations=0) result = kdf.derive(b"password") except Exception as e: print("Caught:", e) # <-- NEVER REACHED 3. Contrast with iterations=-1: Passing -1 correctly raises OverflowError (a subclass of Exception) and IS catchable. Only iterations=0 hits the Rust panic path. --- Proof of Concept: from cryptography.hazmat.primitives.kdf.pbkdf2 import PBKDF2HMAC from cryptography.hazmat.primitives import hashes kdf = PBKDF2HMAC(algorithm=hashes.SHA256(), length=32, salt=b"salt", iterations=0) print("__init__ passed: no error raised here") try: result = kdf.derive(b"password") except Exception as e: print("Caught (Exception):", e) # NEVER REACHED Realistic attack vector (API endpoint accepting PBKDF2 parameters): @app.post("/derive-key") async def derive_key(params: KDFParams): try: kdf = PBKDF2HMAC( algorithm=hashes.SHA256(), length=params.key_length, salt=params.salt.encode(), iterations=params.iterations # user-controlled! ) return {"key": kdf.derive(params.password.encode()).hex()} except Exception as e: raise HTTPException(status_code=400, detail=str(e)) # PanicException bypasses the except Exception block above --- Recommended Fix: Option 1 — Python-level validation (fastest fix): def __init__(self, algorithm, length, salt, iterations, backend=None): ... if not isinstance(iterations, int) or iterations < 1: raise ValueError( "iterations must be a positive integer, got {!r}".format(iterations) ) self._iterations = iterations Option 2 — Rust-level fix (proper long-term fix): Replace .unwrap() in src/rust/src/backend/kdf.rs:30 with proper error propagation using map_err so that OpenSSL errors surface as catchable Python exceptions via PyO3's error conversion. Both fixes should be applied: the Python-level check as a fast guard with a clear error message, and the Rust-level fix to make the entire error path robust. --- I am happy to provide a complete test harness, coordinate a patch review, or adjust the disclosure timeline. --- Researcher: CodeAnt AI Security Research Team, part of https://www.codeant.ai/ Contact: securityresearch(a)codeant.ai

2 1

PyCA cryptography 46.0.5 released
by Paul Kehrer Feb. 10, 2026

Feb. 10, 2026

PyCA cryptography 46.0.0 has been released to PyPI. cryptography includes both high level recipes and low level interfaces to common cryptographic algorithms such as symmetric ciphers, asymmetric algorithms, message digests, X.509, key derivation functions, and much more. We support Python 3.8+, and PyPy3 3.11. Changelog (https://cryptography.io/en/latest/changelog/#v46-0-5) * An attacker could create a malicious public key that reveals portions of your private key when using certain uncommon elliptic curves (binary curves). This version now includes additional security checks to prevent this attack. This issue only affects binary elliptic curves, which are rarely used in real-world applications. Credit to **XlabAI Team of Tencent Xuanwu Lab and Atuin Automated Vulnerability Discovery Engine** for reporting the issue. **CVE-2026-26007** * Support for SECT binary elliptic curves is deprecated and will be removed in the next release. -Paul Kehrer (reaperhulk)

1 0

PyCA cryptography 46.0.4 released
by Paul Kehrer Jan. 28, 2026

Jan. 28, 2026

PyCA cryptography 46.0.4 has been released to PyPI. cryptography includes both high level recipes and low level interfaces to common cryptographic algorithms such as symmetric ciphers, asymmetric algorithms, message digests, X.509, key derivation functions, and much more. We support Python 3.8+, and PyPy3 3 .11. Changelog (https://cryptography.io/en/latest/changelog/#v46-0-4) * Dropped support for win_arm64 wheels. * Updated Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.5.5. -Paul Kehrer (reaperhulk)

3 3

Invitation: Brief interview on (partially) migrating pyca/cryptography to Rust (TU Delft study)
by Jort van Driel Jan. 20, 2026

Jan. 20, 2026

Dear maintainers of pyca/cryptography, I hope you are well. I am reaching out to ask if you would be open to having a brief conversation about (partially) migrating your cryptography project to Rust. To quickly introduce my work: my name is Jort van Driel, and I am a master's student at Delft University of Technology. I am currently researching how the quality of open-source projects changes when they (partially) migrate to Rust. I came across your project on GitHub and noticed that it underwent such a migration. I would greatly appreciate the opportunity to learn more about your experience. If you are not the right person to speak to, please feel free to forward this email to a colleague who was involved. The conversation will be a short 20-minute interview about your reasons for migrating, the process itself, and the observed effects. It is important to note that: * The anonymised results will be used for research purposes and may be published in the TU Delft Repository and elsewhere. * All data will be handled confidentially. The interview will focus solely on your open-source project and will not ask for any personal details. I will use the transcription feature in Microsoft Teams to take pseudonymized notes and I will analyse your repository. No additional data will be collected. * Participation in this study is entirely voluntary, and you may withdraw at any time. You can skip any questions and exclude your answers entirely until they are fully anonymised, which will happen two weeks after the interview. If you are interested in participating, you can select a time here: https://app.cal.eu/jrvandriel/interview. If not, no worries at all, and thank you for your time. Best regards, Jort van Driel Master student, Delft University of Technology

1 0

Create a new thread in Cryptography-dev
by 68124630121＠lawasri.tru.ac.th Jan. 18, 2026

Jan. 18, 2026

Create a new thread in Cryptography-dev

1 0

The State of OpenSSL and pyca/cryptography
by Paul Kehrer Jan. 14, 2026

Jan. 14, 2026

We've published a statement (based on an invited talk we gave at the inauguarl OpenSSL conference in late 2025) on the pyca/cryptography project website about our deep concerns with OpenSSL's current trajectory and how we intend to move forward. https://cryptography.io/en/latest/statements/state-of-openssl/ -Paul (reaperhulk)

1 0

Is there a limitation on OIDs for x509.SubjectAlternativeName([x509.RegisteredID(value)])
by rgm＠htt-consult.com Dec. 9, 2025

Dec. 9, 2025

I have been having problems with what OIDs are allowed for RegisteredID. I do not see any limitation on OIDs here in rfc5280, yet an OID like 99.15854644 throws a; ValueError: error parsing asn1 value: ParseError { kind: InvalidValue } 1.15854644 fails but 1.3.15854644 works. Like there is some internal table, that I don't believe is in openssl is limiting what I put in here. Oh, 15854644 is F1EC34 which is a 24-bit Aircraft Number and RegisteredID seems a good place (other than cn=24anF1EC34). thank you

3 2

PyCA cryptography 46.0.3 released
by Alex Gaynor Oct. 15, 2025

Oct. 15, 2025

PyCA cryptography 46.0.3 has been released to PyPI. cryptography includes both high level recipes and low level interfaces to common cryptographic algorithms such as symmetric ciphers, asymmetric algorithms, message digests, X.509, key derivation functions, and much more. We support Python 3.8+, and PyPy3 3.11. Changelog (https://cryptography.io/en/latest/changelog/#v46-0-3) * Fixed compilation when using LibreSSL 4.2.0. Alex -- All that is necessary for evil to succeed is for good people to do nothing.

1 0

[ANN] M2Crypto 0.46.0
by Matěj Cepl Oct. 2, 2025

Oct. 2, 2025

New version of 0.46.0 of M2Crypto has been released to PyPI. M2Crypto is a comprehensive Python wrapper for OpenSSL on POSIX, macOS, and Windows platforms. It features RSA, DSA, DH, EC, HMACs, X.509 certificates (or digests if referring specifically to X.509 message digests), symmetric ciphers, and SSL functionality to implement clients and servers. It also includes HTTPS extensions to Python’s httplib, urllib, and xmlrpclib; unforgeable HMAC AuthCookies for web session management; FTP/TLS client and server; and S/MIME. M2Crypto can also provide SSL for Twisted. Note: Smartcard support via the Engine interface was removed in this version, and the preliminary support for OpenSSL Providers has started. This release is a significant milestone in the package's development. Multiple work-in-progress (WIP) branches were finally merged (with kind help from AI, particularly Gemini, which greatly assisted in untangling complicated issues), and long-term problems were resolved. Every effort was made to keep the API completely stable and the library's behavior toward its users unchanged. However, if any bugs slipped through, please do not hesitate to inform us via the email list: ~mcepl/m2crypto(a)lists.sr.ht. We welcome any volunteers willing to help! We are particularly looking for developers on non-Linux platforms (especially Windows and macOS) who would be willing to at least test and improve the documentation for the installation and testing of the package. Overview of the significant changes in the package: - Fix: M2Crypto now correctly closes the SSL connection when closing an HTTPS Connection, resolving related issues (#203, #278). - Modernization: C API updated by eliminating deprecated PyBytes_AsStringAndSize and related functions, now using the Python Buffer Protocol (#375). - Type Hints/Formatting: The whole project is now completely covered with type hints and checked by mypy (and has been formatted with black) (#344). - Feature: Added logging support to the C extension code, sending messages to the Python logging system. - Breaking change: Support for the long deprecated Engine object was removed (#229). - Feature: Introduced initial efforts to support the OpenSSL providers. - Fix: Reworked and fixed the M2Crypto.m2xmlrpclib module (#163). - Documentation: Improved S/MIME documentation (#377). - Fix: Package is now compatible with OpenSSL ≥3.4 (no longer relies on LEGACY crypto-policies). - Reverted removal of demo/ subdirectory - Some other minor bugs, improvements, and removal of dead code The package has been tested on Python versions between 3.6 and 3.14.0rc3. All users are strongly encouraged to upgrade. Binary wheels for various versions of Windows are available. Blessigns, Matěj -- http://matej.ceplovi.cz/blog/, @mcepl@en.osm.town GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Whoever does not have the courage to make history, becomes its poor object. Let’s do it! -- Alfred Delp SJ, The Prison Writings

1 0

PyCA cryptography 46.0.2 released
by Alex Gaynor Oct. 1, 2025

Oct. 1, 2025

PyCA cryptography 46.0.2 has been released to PyPI. cryptography includes both high level recipes and low level interfaces to common cryptographic algorithms such as symmetric ciphers, asymmetric algorithms, message digests, X.509, key derivation functions, and much more. We support Python 3.8+, and PyPy3 3.11. Changelog (https://cryptography.io/en/latest/changelog/#v46-0-2) * Updated Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.5.4. Alex -- All that is necessary for evil to succeed is for good people to do nothing.

1 0