Package zeroecho.core.alg

package zeroecho.core.alg
Concrete cryptographic algorithms and small helpers used by algorithms.

This package hosts provider-specific and library-native implementations of algorithms along with lightweight utilities that assist those implementations. It focuses on binding algorithm roles to runtime contexts, publishing capabilities for discovery, and keeping construction logic concise and safe.

Scope and responsibilities

  • Provide concrete algorithm classes that can be discovered and registered by CryptoAlgorithms.
  • Offer a convenience base class AbstractCryptoAlgorithm to standardize capability declaration and runtime factory binding.
  • Publish structured metadata (capabilities) for higher layers to inspect and select suitable algorithms.

Key concepts

  • Algorithm model: Implementations conform to CryptoAlgorithm, exposing canonical identifiers, provider names, priorities, and role bindings.
  • Roles and contexts: Roles are enumerated by KeyUsage and map to concrete runtime contexts that implement CryptoContext.
  • Capabilities: Each declared role produces a Capability descriptor describing family (AlgorithmFamily), role, context type, accepted key type, and optional specification type.

Capability binding

Implementations typically extend AbstractCryptoAlgorithm and use its capability(...) method to perform two actions atomically:

  • Runtime binding: register a factory that constructs the role specific context from a key and optional ContextSpec.
  • Metadata publication: add a Capability to the algorithm so that higher layers can discover supported features.

Construction and safety

  • Algorithm instances are expected to be immutable and safe to share across threads once constructed.
  • Factories must return a context assignable to the declared context type; a mismatch is a programming error and should result in a failure during creation.
  • Null checks and basic type validation are performed eagerly to fail fast on misconfiguration.

Extensibility

  • New algorithms should prefer extending AbstractCryptoAlgorithm to reduce boilerplate and keep capability descriptions consistent.
  • Additional roles can be introduced by declaring further capability bindings that share the same canonical algorithm id.
  • Provider specific implementations should keep provider details encapsulated behind context factories.
Since:
1.0