Mailman 3 - Cryptography-dev

PyCA cryptography 49.0.0 released
by Paul Kehrer June 12, 2026

June 12, 2026

PyCA cryptography 49.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.9+, and PyPy3 3.11. Changelog (https://cryptography.io/en/latest/changelog/#v49-0-0) * BACKWARDS INCOMPATIBLE: Support for x86_64 macOS has been removed. We now only publish arm64 wheels for macOS. * BACKWARDS INCOMPATIBLE: Support for 32-bit Windows has been removed. Users should move to a 64-bit Python installation. * BACKWARDS INCOMPATIBLE: Removed the deprecated PUBLIC_KEY_TYPES, PRIVATE_KEY_TYPES, CERTIFICATE_PRIVATE_KEY_TYPES, CERTIFICATE_ISSUER_PUBLIC_KEY_TYPES, and CERTIFICATE_PUBLIC_KEY_TYPES type aliases. Use PublicKeyTypes, PrivateKeyTypes, CertificateIssuerPrivateKeyTypes, CertificateIssuerPublicKeyTypes, and CertificatePublicKeyTypes instead. These were deprecated in version 40.0. * BACKWARDS INCOMPATIBLE: ChaCha20 now treats the first 4 bytes of the nonce as a 32-bit little-endian block counter (as defined in RFC 7539) and tracks the number of bytes processed. Attempting to encrypt or decrypt more data than the counter allows before it would overflow now raises a ValueError rather than silently diverging from RFC 7539. Setting the counter portion of the nonce to zero allows encrypting up to 256 GiB with a given nonce. * BACKWARDS INCOMPATIBLE: Loading an X.509 certificate whose ECDSA or DSA signature AlgorithmIdentifier contains encoded NULL parameters now raises a ValueError. Such certificates are invalid, but older versions of Java emitted them; previously they loaded with a deprecation warning. * Fixed cross-compilation of the CFFI bindings when PYO3_CROSS_LIB_DIR is set. The build now derives the Python include directory from PYO3_CROSS_LIB_DIR instead of querying the host interpreter, which previously caused the build to fail during cross-compilations for embedded systems, on hosts which have same-version Python development headers installed as the target Python. * Added support for signing and verifying X.509 certificates, certificate signing requests, and certificate revocation lists with ML-DSA signing keys, as well as loading certificates that contain ML-DSA public keys. * Added enc_length() to KEM so callers can split the encapsulated key from the ciphertext returned by encrypt(). * require_present(), may_be_present(), and require_not_present() now accept any extension type. Previously only a fixed set of extension types was supported, which made it impossible to account for otherwise unrecognized critical extensions during path validation. * Added support for using Certificate, CertificateSigningRequest, and CertificateRevocationList as field types in ASN.1 structures. * Added value_set(), a class decorator that registers an enum.Enum subclass as an ASN.1 value set: members are encoded as their underlying value, and decoding fails if the decoded value does not match one of the declared members. * Added from_bytes() for parsing a Name from DER bytes, the inverse of public_bytes(). * Added the rsa_padding keyword-only parameter to public_key(). Passing the PSS class (not an instance) encodes an RSA subject public key in the certificate’s subjectPublicKeyInfo with the id-RSASSA-PSS OID and no parameters. * Added external mu (message representative) support to ML-DSA signing via the sign_mu and verify_mu methods, which sign and verify a precomputed 64-byte mu as defined in FIPS 204. -Paul Kehrer (reaperhulk)

1 0

PyCA cryptography 48.0.1 released
by Paul Kehrer June 9, 2026

June 9, 2026

PyCA cryptography 48.0.1 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.9+, and PyPy3 3.11. Changelog (https://cryptography.io/en/latest/changelog/#v48-0-1) * Updated Windows, macOS, and Linux wheels to be compiled with OpenSSL 4.0.1. -Paul Kehrer (reaperhulk)

1 0

bc1qr8e6kmev99jxnk7hpyhex434t59ke5tpvmnyd3
by 172412067+mahdi99mi＠users.noreply.github.com May 10, 2026

May 10, 2026

b50a18c8f3d3ce87dea027a979df88998755fd915669ad86b7967477cb29d9e2

1 0

PyCA cryptography 48.0.0 released
by Paul Kehrer May 4, 2026

May 4, 2026

PyCA cryptography 48.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.9+, and PyPy3 3.11. Changelog (https://cryptography.io/en/latest/changelog/#v48-0-0) * BACKWARDS INCOMPATIBLE: Support for Python 3.8 has been removed. cryptography now requires Python 3.9 or later. * BACKWARDS INCOMPATIBLE: Loading an X.509 CRL whose inner TBSCertList.signature algorithm does not match the outer signatureAlgorithm now raises ValueError. Previously, such CRLs were parsed successfully and only rejected during signature validation. * Added support for ML-KEM key encapsulation and ML-DSA signing when using OpenSSL 3.5.0 or later, in addition to the existing AWS-LC and BoringSSL support. This means post-quantum algorithms are now available to users of our wheels. * Note: Going forward, we do not guarantee that all functionality in cryptography will be available when building against OpenSSL. See ( https://cryptography.io/en/latest/statements/state-of-openssl/) for more information. -Paul Kehrer (reaperhulk)

1 0

[PR] fix: -headerpad_max_install_names regression in macOS 15 wheels (46.0.4)
by washingtoneg＠gmail.com May 4, 2026

May 4, 2026

Hi all, Opened a PR to permanently fix the `-headerpad_max_install_names` regression that appeared in 46.0.4: https://github.com/pyca/cryptography/pull/14777 The short version: macOS 15 CI runners use Apple's new linker (ld_prime), which reserves much less Mach-O header padding than the old ld. Homebrew's install_name_tool needs that padding to rewrite dylib paths post-install. When it's absent, `brew install`/`brew upgrade` fails with: "Updated load commands do not fit in the header of _rust.abi3.so" The fix is three lines in src/rust/build.rs — emit -Wl,-headerpad_max_install_names via cargo:rustc-link-arg when targeting macOS. This is the same class of issue discussed in #7847 (2022). At the time, @reaperhulk noted there was no objection to adding the flag permanently. The symptom went away on its own then; the macos-13 → macos-15 runner migration brought it back for good. PR: https://github.com/pyca/cryptography/pull/14777 Thanksk Elena

1 1

PyCA cryptography 47.0.0 released
by Paul Kehrer April 24, 2026

April 24, 2026

PyCA cryptography 47.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/#v47-0-0) * Support for Python 3.8 is deprecated and will be removed in the next cryptography release. * BACKWARDS INCOMPATIBLE: Support for binary elliptic curves (SECT* classes) has been removed. These curves are rarely used and have additional security considerations that make them undesirable. * BACKWARDS INCOMPATIBLE: Support for OpenSSL 1.1.x has been removed. OpenSSL 3.0.0 or later is now required. LibreSSL, BoringSSL, and AWS-LC continue to be supported. * BACKWARDS INCOMPATIBLE: Dropped support for LibreSSL < 4.1. * BACKWARDS INCOMPATIBLE: Loading keys with unsupported algorithms or keys with unsupported explicit curve encodings now raises UnsupportedAlgorithm instead of ValueError. This change affects load_pem_private_key(), load_der_private_key(), load_pem_public_key(), load_der_public_key(), and public_key() when called on certificates with unsupported public key algorithms. * BACKWARDS INCOMPATIBLE: When parsing elliptic curve private keys, we now reject keys that incorrectly encode a private key of the wrong length because such keys are impossible to process in a constant-time manner. We do not believe keys with this problem are in wide use, however we may revert this change based on the feedback we receive. * Deprecated passing 64-bit (8-byte) and 128-bit (16-byte) keys to TripleDES. In a future release, only 192-bit (24-byte) keys will be accepted. Users should expand shorter keys themselves (e.g., for single DES: key + key + key, for two-key: key + key[:8]). * Updated the minimum supported Rust version (MSRV) to 1.83.0, from 1.74.0. * Support for x86_64 macOS (including publishing wheels) is deprecated and will be removed in the next release. We will switch to publishing an arm64 only wheel for macOS. * Support for 32-bit Windows (including publishing wheels) is deprecated and will be removed in the next release. Users should move to a 64-bit Python installation. public_bytes and private_bytes methods on keys now raise TypeError (instead of ValueError) if an invalid encoding is provided for the given format. * Moved CFB, OFB, and CFB8 into Decrepit cryptography and deprecated them in the modes module. They will be removed from the modes module in 49.0.0. * Moved Camellia into Decrepit cryptography and deprecated it in the cipher module. It will be removed from the cipher module in 49.0.0. * Added extract() to HKDF. The previous private implementation will be removed in 49.0.0. * Added support for loading elliptic curve keys that contain explicit encodings of the curves secp256r1, secp384r1, and secp521r1. * Added support for Argon2d and Argon2i when using OpenSSL 3.2.0+. * Added derive_into methods to HKDF, HKDFExpand, ConcatKDFHash, ConcatKDFHMAC, Argon2id, PBKDF2HMAC, KBKDFHMAC, KBKDFCMAC, Scrypt, and X963KDF to allow deriving keys directly into pre-allocated buffers. * Added encrypt_into and decrypt_into methods to AESCCM, AESGCM, AESGCMSIV, AESOCB3, AESSIV, and ChaCha20Poly1305 to allow encrypting directly into a pre-allocated buffer. * Added support for PKCS1v15 signing without DigestInfo using NoDigestInfo. * Added hash(), a one-shot method for computing hashes. * Added HPKE (Hybrid Public Key Encryption) support implementing RFC 9180 for hybrid authenticated encryption. * Added new ML-KEM key encapsulation module with support for ML-KEM key encapsulation with AWS-LC and BoringSSL. * Note: Post-quantum algorithm support requires AWS-LC or BoringSSL. As we ship our wheels with OpenSSL, most users will not have access to these APIs yet. See ( https://cryptography.io/en/latest/statements/state-of-openssl/) for more information on OpenSSL support. * Added new ML-DSA signing module with support for ML-DSA signing and verification with AWS-LC and BoringSSL. * Note: Post-quantum algorithm support requires AWS-LC or BoringSSL. As we ship our wheels with OpenSSL, most users will not have access to these APIs yet. See ( https://cryptography.io/en/latest/statements/state-of-openssl/) for more information on OpenSSL support. * Added new ASN.1 module with support for declaratively defining custom ASN.1 types and encoding/decoding them. * Fixed compilation when using LibreSSL 4.3.0 and OpenSSL 4.0.0. * Updated Windows, macOS, and Linux wheels to be compiled with OpenSSL 4.0.0. -Paul Kehrer (reaperhulk)

1 0

PyCA cryptography 46.0.7 released
by Paul Kehrer April 8, 2026

April 8, 2026

PyCA cryptography 46.0.7 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-7) * **SECURITY ISSUE**: Fixed an issue where non-contiguous buffers could be passed to APIs that accept Python buffers, which could lead to buffer overflow. **CVE-2026-39892** * Updated Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.5.6. -Paul Kehrer (reaperhulk)

1 0

Help needed
by LUCKMAN WORLD March 20, 2026

March 20, 2026

Hello, I’m currently building a web application that includes user authentication (signup/login) with email verification. I’m using bcrypt for password hashing and considering additional safeguards around verification codes and input validation. I came across a discussion regarding PBKDF2 edge cases (such as invalid iteration values causing unexpected behavior), and it made me reconsider how much validation should be handled at the application level versus relying on library safeguards. My questions are: 1. What are the recommended best practices for password hashing in modern web applications? 2. Should developers always enforce strict validation on cryptographic parameters (e.g., iteration counts), even when using well-maintained libraries? 3. Are there preferred approaches for securely handling verification codes (email/SMS) in terms of storage and expiration? I would appreciate any guidance or references. Thank you.

1 0

Help needed
by LUCKMAN WORLD March 20, 2026

March 20, 2026

Hello, I’m currently building a web application that includes user authentication (signup/login) with email verification. I’m using bcrypt for password hashing and considering additional safeguards around verification codes and input validation. I came across a discussion regarding PBKDF2 edge cases (such as invalid iteration values causing unexpected behavior), and it made me reconsider how much validation should be handled at the application level versus relying on library safeguards. My questions are: 1. What are the recommended best practices for password hashing in modern web applications? 2. Should developers always enforce strict validation on cryptographic parameters (e.g., iteration counts), even when using well-maintained libraries? 3. Are there preferred approaches for securely handling verification codes (email/SMS) in terms of storage and expiration? I would appreciate any guidance or references. Thank you.

1 0

Help needed
by LUCKMAN WORLD March 20, 2026

March 20, 2026

Hello, I’m currently building a web application that includes user authentication (signup/login) with email verification. I’m using bcrypt for password hashing and considering additional safeguards around verification codes and input validation. I came across a discussion regarding PBKDF2 edge cases (such as invalid iteration values causing unexpected behavior), and it made me reconsider how much validation should be handled at the application level versus relying on library safeguards. My questions are: 1. What are the recommended best practices for password hashing in modern web applications? 2. Should developers always enforce strict validation on cryptographic parameters (e.g., iteration counts), even when using well-maintained libraries? 3. Are there preferred approaches for securely handling verification codes (email/SMS) in terms of storage and expiration? I would appreciate any guidance or references. Thank you.

1 0