aleksis/AlekSIS-App-Kompjuter

Watch

Fork 0

Update dependency pycryptodome to v4 #111

Open

teckids_renovate_bot wants to merge 1 commit from renovate/pycryptodome-4.x into master

teckids_renovate_bot commented

2026-10-14 13:21:06 +02:00

Member

This PR contains the following updates:

Package	Type	Update	Change
pycryptodome (changelog)	dependencies	major	`^3.20.0` → `^4.0.0`

Release Notes

Legrandin/pycryptodome (pycryptodome)

New features

Added the elliptic curve secp256k1 to Crypto.PublicKey.ECC: key generation,
import and export, ECDSA with Crypto.Signature.DSS, and ECDH with
Crypto.Protocol.DH.
Added the mode 'sec1' to Crypto.Signature.DSS.new, for randomized ECDSA on all Weierstrass
curves. Mode 'fips-186-3' does not accept secp256k1, which is not a curve of that standard.
GH#759: Added the parameter low_s to Crypto.Signature.DSS.new, for ECDSA signatures
in the low-S form (for all curves): signing normalizes s, and verifying rejects a high s.
ECDSA signatures in DER encoding are about 5-8x faster.

Resolved issues

ECC.import_key raised TypeError instead of ValueError for an OpenSSH public key
with an unsupported curve or key type, or with a malformed body.
ECC.import_key accepted an OpenSSH key (public or private) whose curve did not match its key type.
GH#960: In HPKE, a message rejected by unseal() consumed a sequence number, so all later
messages of that context failed too. The sequence number now only advances when unseal()
succeeds (RFC 9180, Section 5.2). Thanks to Zulfareen Shaikh.
In HPKE, a seal() that raised an exception also consumed a sequence number,
so the receiver could not unseal the messages that followed.

`v4.3.0`: - Kourou

Compare Source

New features

CTR mode is 2.5-3.5x faster on large data (and GCM about 2x),
on all platforms.
On 64-bit ARM CPUs (Linux, macOS and Windows), AES and GHASH use the instructions
of the ARMv8 Cryptography Extensions (AES and PMULL), when available.
On a Graviton3, AES-ECB is about 35x faster, GCM 7x, OCB 10-12x,
and CTR, CBC, CFB and OFB 3-6x.
Integer.random_range() is about 2x faster when the bounds are public,
with the same output: ECDSA signatures are about 13% faster (P-256),
DSA signatures about 4%, and ECC key generation about 35%.
The RSA modulus and the DSA subgroup order are now public Integer objects.
Faster RSA: on x86-64, signatures and decryption are 35-40% faster
(RSA-2048 to RSA-4096), verification and encryption 2-2.7x.
Modular exponentiation with a public exponent (like the RSA public exponent)
no longer uses the slower constant-time algorithm, which is only needed for
secret exponents, and the Montgomery context of a modulus is kept with it.
The RSA blinding factor is squared between uses (a new one every 32 uses,
and after a fork).
The Montgomery multiplication for x86-64 CPUs with BMI2 and ADX is about 20%
faster: DSA signatures and verification are about 25% faster.
ECDSA signatures are 3-6% faster for P-256 and P-384: the field inversion
uses the faster power for public exponents (the exponent p - 2 is public).
On 64-bit ARM CPUs, SHA-224 and SHA-256 use the SHA-256 instructions
of the ARMv8 Cryptography Extensions, and SHA-384 and SHA-512 the SHA-512
instructions of ARMv8.2, when available.
On a Graviton3, SHA-256 is about 3.8x faster, and SHA-512 2x.
On 64-bit ARM CPUs, KangarooTwelve, ML-KEM and ML-DSA compute 4 Keccak states at once
(2 with scalar code and 2 with NEON).
On a Graviton3, KangarooTwelve is 1.9x faster, ML-DSA 7-20% and ML-KEM 7-8%.
PKCS#1 v1.5 decryption (Crypto.Cipher.PKCS1_v1_5) performs implicit rejection,
as defined in section 7.2 of draft-irtf-cfrg-rsa-guidance,
when decrypt() is called without a sentinel (which is now optional):
when the padding of a ciphertext is not correct, it returns a pseudo-random
message, which only depends on the private key and on the ciphertext.
With a sentinel, decrypt() behaves as before.

Other changes

Updated the Wycheproof test vectors (new Ed25519 tests and the new chacha20_counter_test.json).
XChaCha20 keeps the construction of draft-irtf-cfrg-xchacha (HChaCha20 and the ChaCha20
of RFC 8439), with a 32-bit block counter: the key stream ends after 256 GiB,
whereas libsodium and Wycheproof use a 64-bit counter.

Resolved issues

GH#481: PKCS#1 v1.5 decryption could be used as a Bleichenbacher oracle,
through the sentinel returned for ciphertexts with incorrect padding.
Calling decrypt() without sentinel (implicit rejection) is now
recommended. Thanks to tomato42 and eslerm.
PKCS#1 v1.5 decrypt() never returned a sentinel that is not a byte string
(such as None), and it returned an empty byte string instead.
GH#954: Crypto.Util.asn1.DerObjectId accepted an ASN.1 OBJECT IDENTIFIER where an arc
is encoded with the initial octet 0x80 (invalid, as that would violate the minimal
encoding rule for BER) or where the last octet encoding the last arc has bit 7 set
(invalid, and that arc would also be dropped). In those cases, decoding now fails.
Thanks to Zulfareen Shaikh.

New features

New module Crypto.PublicKey.MLKEM, for ML-KEM keys (FIPS 203).
It is based on the portable C code of
mlkem-native <https://github.com/pq-code-package/mlkem-native>_ (v2.0.0),
with the Keccak code of PyCryptodome, also compiled for AVX2 and BMI2 (with 4-way SHA-3).
The keys can be exported and imported as PKCS#8 DER or PEM files.
New module Crypto.PublicKey.Hybrid, to model hybrid keys (post-quantum + traditional).
It supports the hybrid KEM MLKEM768-X25519 (X-Wing), which combines ML-KEM-768 and X25519.
For now, hybrid keys can only be generated and used with HPKE: they cannot be exported or imported.
Crypto.Protocol.HPKE accepts ML-KEM keys and X-Wing keys,
for post-quantum HPKE (draft-ietf-hpke-pq), in the Base and PSK modes.

`v4.1.0`: - Issy-les-Moulineaux

Compare Source

New features

New module Crypto.PublicKey.MLDSA, for ML-DSA keys (FIPS 204).
It is based on the portable C code of mldsa-native <https://github.com/pq-code-package/mldsa-native>_ (v2.0.0), with the Keccak code of PyCryptodome. On CPUs with AVX2 and BMI2, a version compiled for them and with 4-way SHA-3 is used: compared to the portable version, key generation and verification are 30-45% faster, signing 15-30%.
New module Crypto.Signature.mldsa, for ML-DSA and HashML-DSA signatures (FIPS 204), hedged (default) or deterministic, with an optional context. The new MLDSAMuHash computes the message representative mu (external mu), to sign or verify a large message in pieces.
New function digest() in the modules of the SHA-2 and SHA-3 hashes, to hash a whole message with a single call, like Crypto.Hash.KangarooTwelve.digest(). For messages up to 1 KiB, it is 1.5x to 3.4x faster than new() followed by digest().
Crypto.IO.PKCS8.wrap() has a new parameter public_key, to create a OneAsymmetricKey version 2 (RFC 5958) with the field publicKey. Crypto.IO.PKCS8.unwrap() returns an UnwrappedKey: still a tuple (oid, private_key, params),
with the same items as attributes, plus public_key (the field publicKey, if present).
The scalar Keccak permutation (used by SHA-3, SHAKE, cSHAKE, KMAC, TupleHash, TurboSHAKE and KangarooTwelve) processes the state one plane at a time, two rounds per iteration, which needs fewer registers: SHA-3 and SHAKE are 5-10% faster.

Resolved issues

Crypto.PublicKey.ECC.import_key() checks that the field publicKey of a PKCS#8 OneAsymmetricKey version 2 (RFC 5958), if present, matches the private key. Before, it was ignored.

`v4.0.1`: - Le Havre

Compare Source

New features

The Windows wheels for x86-64 are built with clang-cl (compatible with MSVC), so the
code for CPUs with AVX2, BMI2 and ADX is also used on Windows: SHA-3 and the other
Keccak-based functions, KangarooTwelve, ChaCha20, Salsa20, and the big integers of RSA,
DSA and the NIST curves. To build from source with clang-cl, set the environment
variable PYCRYPTODOME_CLANG_CL (see the installation instructions).

`v4.0.0`: - Grenoble

Compare Source

Major release, with some breaking changes. See Changelog.

Configuration

📅 Schedule: (UTC)

Branch creation
- At any time (no schedule defined)
Automerge
- At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate CLI.

This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [pycryptodome](https://github.com/Legrandin/pycryptodome) ([changelog](https://www.pycryptodome.org/src/changelog)) | dependencies | major | `^3.20.0` → `^4.0.0` | --- ### Release Notes <details> <summary>Legrandin/pycryptodome (pycryptodome)</summary> ### [`v4.4.0`](https://github.com/Legrandin/pycryptodome/releases/tag/v4.4.0): - Lyon [Compare Source](https://github.com/Legrandin/pycryptodome/compare/v4.3.0...v4.4.0) ## New features - Added the elliptic curve secp256k1 to `Crypto.PublicKey.ECC`: key generation, import and export, ECDSA with `Crypto.Signature.DSS`, and ECDH with `Crypto.Protocol.DH`. - Added the mode `'sec1'` to `Crypto.Signature.DSS.new`, for randomized ECDSA on all Weierstrass curves. Mode `'fips-186-3'` does not accept secp256k1, which is not a curve of that standard. - [GH#759](https://github.com/GH/pycryptodome/issues/759): Added the parameter `low_s` to `Crypto.Signature.DSS.new`, for ECDSA signatures in the low-S form (for all curves): signing normalizes `s`, and verifying rejects a high `s`. - ECDSA signatures in DER encoding are about 5-8x faster. ## Resolved issues - `ECC.import_key` raised `TypeError` instead of `ValueError` for an OpenSSH public key with an unsupported curve or key type, or with a malformed body. - `ECC.import_key` accepted an OpenSSH key (public or private) whose curve did not match its key type. - [GH#960](https://github.com/GH/pycryptodome/issues/960): In HPKE, a message rejected by `unseal()` consumed a sequence number, so all later messages of that context failed too. The sequence number now only advances when `unseal()` succeeds (RFC 9180, Section 5.2). Thanks to Zulfareen Shaikh. - In HPKE, a `seal()` that raised an exception also consumed a sequence number, so the receiver could not unseal the messages that followed. ### [`v4.3.0`](https://github.com/Legrandin/pycryptodome/releases/tag/v4.3.0): - Kourou [Compare Source](https://github.com/Legrandin/pycryptodome/compare/v4.2.0...v4.3.0) ## New features - CTR mode is 2.5-3.5x faster on large data (and GCM about 2x), on all platforms. - On 64-bit ARM CPUs (Linux, macOS and Windows), AES and GHASH use the instructions of the ARMv8 Cryptography Extensions (AES and PMULL), when available. On a Graviton3, AES-ECB is about 35x faster, GCM 7x, OCB 10-12x, and CTR, CBC, CFB and OFB 3-6x. - `Integer.random_range()` is about 2x faster when the bounds are public, with the same output: ECDSA signatures are about 13% faster (P-256), DSA signatures about 4%, and ECC key generation about 35%. The RSA modulus and the DSA subgroup order are now public `Integer` objects. - Faster RSA: on x86-64, signatures and decryption are 35-40% faster (RSA-2048 to RSA-4096), verification and encryption 2-2.7x. Modular exponentiation with a public exponent (like the RSA public exponent) no longer uses the slower constant-time algorithm, which is only needed for secret exponents, and the Montgomery context of a modulus is kept with it. The RSA blinding factor is squared between uses (a new one every 32 uses, and after a fork). - The Montgomery multiplication for x86-64 CPUs with BMI2 and ADX is about 20% faster: DSA signatures and verification are about 25% faster. - ECDSA signatures are 3-6% faster for P-256 and P-384: the field inversion uses the faster power for public exponents (the exponent p - 2 is public). - On 64-bit ARM CPUs, SHA-224 and SHA-256 use the SHA-256 instructions of the ARMv8 Cryptography Extensions, and SHA-384 and SHA-512 the SHA-512 instructions of ARMv8.2, when available. On a Graviton3, SHA-256 is about 3.8x faster, and SHA-512 2x. - On 64-bit ARM CPUs, KangarooTwelve, ML-KEM and ML-DSA compute 4 Keccak states at once (2 with scalar code and 2 with NEON). On a Graviton3, KangarooTwelve is 1.9x faster, ML-DSA 7-20% and ML-KEM 7-8%. - [PKCS#1](https://github.com/PKCS/pycryptodome/issues/1) v1.5 decryption (`Crypto.Cipher.PKCS1_v1_5`) performs implicit rejection, as defined in section 7.2 of `draft-irtf-cfrg-rsa-guidance`, when `decrypt()` is called without a `sentinel` (which is now optional): when the padding of a ciphertext is not correct, it returns a pseudo-random message, which only depends on the private key and on the ciphertext. With a `sentinel`, `decrypt()` behaves as before. ## Other changes - Updated the Wycheproof test vectors (new [`Ed25519`](https://github.com/Legrandin/pycryptodome/commit/Ed25519) tests and the new `chacha20_counter_test.json`). XChaCha20 keeps the construction of draft-irtf-cfrg-xchacha (HChaCha20 and the ChaCha20 of RFC 8439), with a 32-bit block counter: the key stream ends after 256 GiB, whereas libsodium and Wycheproof use a 64-bit counter. ## Resolved issues - [GH#481](https://github.com/GH/pycryptodome/issues/481): [PKCS#1](https://github.com/PKCS/pycryptodome/issues/1) v1.5 decryption could be used as a Bleichenbacher oracle, through the `sentinel` returned for ciphertexts with incorrect padding. Calling `decrypt()` without `sentinel` (implicit rejection) is now recommended. Thanks to tomato42 and eslerm. - [PKCS#1](https://github.com/PKCS/pycryptodome/issues/1) v1.5 `decrypt()` never returned a `sentinel` that is not a byte string (such as `None`), and it returned an empty byte string instead. - [GH#954](https://github.com/GH/pycryptodome/issues/954): `Crypto.Util.asn1.DerObjectId` accepted an ASN.1 OBJECT IDENTIFIER where an arc is encoded with the initial octet 0x80 (invalid, as that would violate the minimal encoding rule for BER) or where the last octet encoding the last arc has bit 7 set (invalid, and that arc would also be dropped). In those cases, decoding now fails. Thanks to Zulfareen Shaikh. ### [`v4.2.0`](https://github.com/Legrandin/pycryptodome/releases/tag/v4.2.0): - Jura [Compare Source](https://github.com/Legrandin/pycryptodome/compare/v4.1.0...v4.2.0) ## New features - New module `Crypto.PublicKey.MLKEM`, for ML-KEM keys (FIPS 203). It is based on the portable C code of `mlkem-native <https://github.com/pq-code-package/mlkem-native>`\_ (v2.0.0), with the Keccak code of PyCryptodome, also compiled for AVX2 and BMI2 (with 4-way SHA-3). The keys can be exported and imported as [PKCS#8](https://github.com/PKCS/pycryptodome/issues/8) DER or PEM files. - New module `Crypto.PublicKey.Hybrid`, to model hybrid keys (post-quantum + traditional). It supports the hybrid KEM MLKEM768-X25519 (X-Wing), which combines ML-KEM-768 and X25519. For now, hybrid keys can only be generated and used with HPKE: they cannot be exported or imported. - `Crypto.Protocol.HPKE` accepts ML-KEM keys and X-Wing keys, for post-quantum HPKE (draft-ietf-hpke-pq), in the Base and PSK modes. ### [`v4.1.0`](https://github.com/Legrandin/pycryptodome/releases/tag/v4.1.0): - Issy-les-Moulineaux [Compare Source](https://github.com/Legrandin/pycryptodome/compare/v4.0.1...v4.1.0) ## New features - New module `Crypto.PublicKey.MLDSA`, for ML-DSA keys (FIPS 204). It is based on the portable C code of `mldsa-native <https://github.com/pq-code-package/mldsa-native>`\_ (v2.0.0), with the Keccak code of PyCryptodome. On CPUs with AVX2 and BMI2, a version compiled for them and with 4-way SHA-3 is used: compared to the portable version, key generation and verification are 30-45% faster, signing 15-30%. - New module `Crypto.Signature.mldsa`, for ML-DSA and HashML-DSA signatures (FIPS 204), hedged (default) or deterministic, with an optional context. The new `MLDSAMuHash` computes the message representative mu (external mu), to sign or verify a large message in pieces. - New function `digest()` in the modules of the SHA-2 and SHA-3 hashes, to hash a whole message with a single call, like `Crypto.Hash.KangarooTwelve.digest()`. For messages up to 1 KiB, it is 1.5x to 3.4x faster than `new()` followed by `digest()`. - `Crypto.IO.PKCS8.wrap()` has a new parameter `public_key`, to create a `OneAsymmetricKey` version 2 (RFC 5958) with the field `publicKey`. `Crypto.IO.PKCS8.unwrap()` returns an `UnwrappedKey`: still a tuple `(oid, private_key, params)`, with the same items as attributes, plus `public_key` (the field `publicKey`, if present). - The scalar Keccak permutation (used by SHA-3, SHAKE, cSHAKE, KMAC, TupleHash, TurboSHAKE and KangarooTwelve) processes the state one plane at a time, two rounds per iteration, which needs fewer registers: SHA-3 and SHAKE are 5-10% faster. ## Resolved issues - `Crypto.PublicKey.ECC.import_key()` checks that the field `publicKey` of a [PKCS#8](https://github.com/PKCS/pycryptodome/issues/8) `OneAsymmetricKey` version 2 (RFC 5958), if present, matches the private key. Before, it was ignored. ### [`v4.0.1`](https://github.com/Legrandin/pycryptodome/releases/tag/v4.0.1): - Le Havre [Compare Source](https://github.com/Legrandin/pycryptodome/compare/v4.0.0...v4.0.1) ## New features - The Windows wheels for x86-64 are built with `clang-cl` (compatible with MSVC), so the code for CPUs with AVX2, BMI2 and ADX is also used on Windows: SHA-3 and the other Keccak-based functions, KangarooTwelve, ChaCha20, Salsa20, and the big integers of RSA, DSA and the NIST curves. To build from source with `clang-cl`, set the environment variable `PYCRYPTODOME_CLANG_CL` (see the installation instructions). ### [`v4.0.0`](https://github.com/Legrandin/pycryptodome/releases/tag/v4.0.0): - Grenoble [Compare Source](https://github.com/Legrandin/pycryptodome/compare/v3.24.1...v4.0.0) Major release, with some breaking changes. See Changelog. </details> --- ### Configuration 📅 **Schedule**: (UTC) - Branch creation - At any time (no schedule defined) - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate CLI](https://github.com/renovatebot/renovate).

teckids_renovate_bot added 1 commit

2026-10-14 13:21:06 +02:00

Update dependency pycryptodome to v4

CI / lock (push) Successful in 44s

Details

CI / lint (push) Successful in 1m13s

Details

CI / tests-done (push) Successful in 4s

Details

CI / build (push) Successful in 1m38s

Details

CI / publish (push) Successful in 11s