Crypto: Add OpenSSL elliptic curve algorithm instances and consumers

[bdrodes]

Adds algorithm instance and consumers for openssl elliptic curves.

[Copilot]

Pull Request Overview

This PR introduces support for OpenSSL elliptic curve algorithms by changing key size handling and adding new consumer/instance classes.

• Changed getKeySize return type from string to int in the common model and Java QL.
• Added EllipticCurveAlgorithmValueConsumer and its registration in the OpenSSL consumer list.
• Added KnownOpenSSLEllipticCurveAlgorithmConstant and KnownOpenSSLEllipticCurveConstantAlgorithmInstance to the OpenSSL instance list.

Reviewed Changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
shared/quantum/codeql/quantum/experimental/Model.qll	Changed getKeySize signature to return int and updated string conversion
java/ql/lib/experimental/quantum/JCA.qll	Updated getKeySize override to return int
cpp/ql/lib/experimental/quantum/OpenSSL/AlgorithmValueConsumers/OpenSSLAlgorithmValueConsumers.qll	Imported EllipticCurveAlgorithmValueConsumer
cpp/ql/lib/experimental/quantum/OpenSSL/AlgorithmValueConsumers/EllipticCurveAlgorithmValueConsumer.qll	Added consumer for EVP-based elliptic curve calls
cpp/ql/lib/experimental/quantum/OpenSSL/AlgorithmInstances/OpenSSLAlgorithmInstances.qll	Imported EllipticCurveAlgorithmInstance
cpp/ql/lib/experimental/quantum/OpenSSL/AlgorithmInstances/KnownAlgorithmConstants.qll	Added KnownOpenSSLEllipticCurveAlgorithmConstant
cpp/ql/lib/experimental/quantum/OpenSSL/AlgorithmInstances/EllipticCurveAlgorithmInstance.qll	Added constant-based elliptic curve instance resolver

Comments suppressed due to low confidence (1)

cpp/ql/lib/experimental/quantum/OpenSSL/AlgorithmValueConsumers/EllipticCurveAlgorithmValueConsumer.qll:1

• No tests found for the new EllipticCurveAlgorithmValueConsumer; consider adding unit tests to verify consumer detection logic with different curve name calls.

import cpp

[Copilot]

There's a typo in the class name: 'EVPEllipticCurveALgorithmConsumer' should be 'EVPEllipticCurveAlgorithmConsumer'.

Suggested change

	class EVPEllipticCurveALgorithmConsumer extends EllipticCurveValueConsumer {
	class EVPEllipticCurveAlgorithmConsumer extends EllipticCurveValueConsumer {

[Copilot]

Class name has a typo: 'KnownOpenSSLEllitpicCurveConstantAlgorithmInstance' should be 'KnownOpenSSLEllipticCurveConstantAlgorithmInstance'.

Suggested change

	class KnownOpenSSLEllitpicCurveConstantAlgorithmInstance extends OpenSSLAlgorithmInstance,
	Crypto::EllipticCurveInstance instanceof KnownOpenSSLEllipticCurveAlgorithmConstant
	{
	OpenSSLAlgorithmValueConsumer getterCall;
	KnownOpenSSLEllitpicCurveConstantAlgorithmInstance() {
	class KnownOpenSSLEllipticCurveConstantAlgorithmInstance extends OpenSSLAlgorithmInstance,
	Crypto::EllipticCurveInstance instanceof KnownOpenSSLEllipticCurveAlgorithmConstant
	{
	OpenSSLAlgorithmValueConsumer getterCall;
	KnownOpenSSLEllipticCurveConstantAlgorithmInstance() {

[Copilot]

[nitpick] Add a doc comment explaining the purpose and usage of EllipticCurveValueConsumer to improve maintainability.

Suggested change

	/**
	* An abstract base class for consumers of elliptic curve algorithm values.
	*
	* This class is designed to be extended by specific implementations that
	* handle elliptic curve-related cryptographic operations in OpenSSL.
	* It provides a common interface and shared functionality for such consumers.
	*
	* Subclasses should implement the necessary methods to process elliptic curve
	* algorithm values and integrate with the OpenSSL cryptographic library.
	*/

[nicolaswill]

Recommend going through all of these and doing a private import of OpenSSLAlgorithmInstanceBase (and other modules where possible).

[bdrodes]

Pushed

[nicolaswill]

Why is there a generic algorithm class here, and why does the algorithm itself bind itself to the AVC as opposed to what is actually using/related to the algorithm consumed?

[nicolaswill]

Am I correct in my reasoning below?

"An algorithm instance exists if and only if it is a string literal that flows to a consumer. Consequently, the definition of an algorithm instance is inherently constrained by the consumer to which it flows, establishing a dependent relationship between the instance and its consuming context."

[bdrodes]

basically a literal must flow to something that consumes it, if not, we aren't calling it an algorithm.

There is a flip side, the direct algorithms (functions like AES()), these... well we could say are algorithms in their own right, but I didn't model it that way. So if these don't flow to something, they also don't exist as an algorithm. We may need to re-address that.

[nicolaswill]

Those are indeed algorithms -- the instance where you define them would be be modeled by extending an algorithm, operation, and AVC (assuming AES() also performs some sort of operation using AES).