class ara::crypto::cryp::CryptoContext

The interface serves as a common base class for mutable cryptographic contexts that are not strictly bound to a single crypto object. Via the pure virtual method GetAlgId(), it enables thread-safe querying of the algorithm identifier as ara::core::Result [SWS_CRYPT_20411]. To prevent unintended state duplication, copy and move operations are completely prohibited [SWS_CRYPT_41003]. Destruction is performed deterministically and safely via a virtual default destructor.

more ›

Context

Interface ara::crypto::cryp::CryptoContext defines the basic abstraction for mutable cryptographic contexts within the crypto module of the AUTOSAR Adaptive Platform. In contrast to static crypto objects, such a context is not rigidly bound to a single cryptographic object. Rather, it serves as a common base class for various cryptographic processing contexts whose internal state can change during the execution of cryptographic operations.

The pure virtual member function GetAlgId() acts as the central element of this base interface. It enables interaction partners to query the identifier of the cryptographic algorithm currently configured in the context [SWS_CRYPT_20411]. Concrete cryptographic calculation and transformation contexts, such as for hash, signature, or encryption services, are likely derived from CryptoContext in the system to provide specific algorithm functionalities. Question Q-203d40209cd355fa (open)

Lifecycle

The lifecycle of CryptoContext is characterized by a unique identity and strict ownership semantics. To prevent uncontrolled duplication or inconsistent transfers of context states at compile time, semantic copy operations are completely prohibited. Both copy constructor [SWS_CRYPT_41003] and copy assignment operator [SWS_CRYPT_30214] are explicitly declared as deleted (=delete).

In the same way, the interface definition prevents moving contexts: Both move constructor [SWS_CRYPT_41004] and move assignment operator [SWS_CRYPT_30215] are deleted (=delete). Instances of derived classes therefore remain permanently at their original storage location. Destruction and resource deallocation take place deterministically via the virtual destructor, which is defined as default and noexcept [SWS_CRYPT_20401]. This ensures that derived context objects can be deallocated safely and without resource leaks via pointers to the base interface.

Regarding concurrency, the requirement for GetAlgId() explicitly specifies thread safety [SWS_CRYPT_20411]. Multiple threads can thus read the algorithm identifier of the same context concurrently and without external synchronization.

Usage Path

Since CryptoContext is a pure virtual interface, application developers cannot create direct instances. Instances of specialized context classes are typically likely to be instantiated via factory functions or provider components of the crypto stack and provided to the caller via pointers or references. Question Q-728a7b6dd526eb64 (open) The typical usage sequence at the base interface level includes the following phases:

• Provisioning: A caller receives a reference or a pointer to a configured context from a crypto provider.
• Algorithm check: Calling GetAlgId() queries and evaluates the algorithm identifier [SWS_CRYPT_20411] to ensure that the context fulfills the required specifications.
• Operation and cleanup: After the algorithm-specific operations have been performed via the derived interface, the context is automatically released via the virtual destructor [SWS_CRYPT_20401].

Error Scenarios

The error handling concept of CryptoContext follows the general fail-safe design of the AUTOSAR Adaptive Platform and dispenses with C++ exceptions. The method GetAlgId() is specified as exception-safe (exception safe) and returns its result in an ara::core::Result<ara::crypto::AlgIdString> [SWS_CRYPT_20411]. If an error occurs when determining the algorithm ID, it is transported in the error channel of the Result object.

According to the specification, GetAlgId() defines no standardized error codes [SWS_CRYPT_20411]. Callers must therefore primarily check whether the Result contains a valid value before accessing the string of the algorithm ID. When destructing the object, the virtual destructor declared with noexcept ensures that no exceptions are propagated during destruction and that cleanup is always reliably completed [SWS_CRYPT_20401].