The ASN.1 parser in Bouncy Castle Crypto (aka BC Java) 1.63 can trigger a
large attempted memory allocation, and resultant OutOfMemoryError error, via
crafted ASN.1 data. This is fixed in 1.64.
"Issue around primality tests for RSA key pair generation if done using only the low-level API."
"Lack of class checking in deserialization of XMSS/XMSS^MT private keys with BDS state information."
* CVE-2017-13098 ("ROBOT")
"A Bleichenbacher oracle in TLS when RSA key exchange is negotiated. This potentially affected BCJSSE servers and any other TLS servers configured to use JCE for the underlying crypto - note the two TLS implementations using the BC lightweight APIs are not affected by this."
"Strict encoding enforcement has been introduced for ASN1Integer."
"DSA does not fully validate ASN.1 encoding of signature on verification. It is possible to inject extra elements in the sequence making up the signature and still have it validate, which in some cases may allow the introduction of "invisible" data into a signed structure."
"AESFastEngine has a side channel leak if table accesses can be observed. The use of lookup large static lookup tables in AESFastEngine means that where data accesses by the CPU can be observed, it is possible to gain information about the key used to initialize the cipher. We now recommend not using AESFastEngine where this might be a concern. The BC provider is now using AESEngine by default."
"Static ECDH vulnerable to carry propagation bug. Carry propagation bugs in the implementation of squaring for several raw math classes have been fixed (org.bouncycastle.math.raw.Nat???). These classes are used by our custom elliptic curve implementations (org.bouncycastle.math.ec.custom.**), so there was the possibility of rare (in general usage) spurious calculations for elliptic curve scalar multiplications. Such errors would have been detected with high probability by the output validation for our scalar multipliers."
"DSA signature generation vulnerable to timing attack. Where timings can be closely observed for the generation of signatures, the lack of blinding in 1.55 or earlier, may allow an attacker to gain information about the signatures k value and ultimately the private value as well."
"ECDSA does not fully validate ASN.1 encoding of signature on verification. It is possible to inject extra elements in the sequence making up the signature and still have it validate, which in some cases may allow the introduction of "invisible" data into a signed structure."
"DSA key pair generator generates a weak private key if used with default values. If the JCA key pair generator is not explicitly initialised with DSA parameters, 1.55 and earlier generates a private value assuming a 1024 bit key size. In earlier releases this can be dealt with by explicitly passing parameters to the key pair generator."
"DHIES allows the use of unsafe ECB mode. This algorithm is now removed from the provider."
"DHIES/ECIES CBC mode vulnerable to padding oracle attack. For BC 1.55 and older, in an environment where timings can be easily observed, it is possible with enough observations to identify when the decryption is failing due to padding."
Description: "Other party DH public key not fully validated. This can cause issues as invalid keys can be used to reveal details about the other party's private key where static Diffie-Hellman is in use. As of this release the key parameters are checked on agreement calculation."
"ECIES allows the use of unsafe ECB mode. This algorithm is now removed from the provider."
Some of these were fixed in earlier versions. The latest fixed version is 2.6.1.
Given this is a cryptography library, I strongly recommend the maintainers update to the latest version. I did not comb through the changelog because I already found these CVEs.
(In reply to Sam James (sec padawan) from comment #1)
> Some of these were fixed in earlier versions. The latest fixed version is
> Given this is a cryptography library, I strongly recommend the maintainers
> update to the latest version. I did not comb through the changelog because I
> already found these CVEs.
@maintainer(s), please see this comment.