Skip to content

v4.3.0 - Kourou

Latest

Choose a tag to compare

@Legrandin Legrandin released this 02 Nov 22:18

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.