Define how we are going to deal with compositions of algorithms, describe it and adapt the affected algorithms descriptions

Background

The current cryptographic algorithm list focuses primarily on individual primitives (e.g., hash functions, ciphers, signature schemes). However, many widely used algorithms are compositions of multiple primitives, forming a higher-level construction that is treated as a distinct algorithm in practice.

Examples include constructions such as:

• AEAD schemes (e.g., combining encryption + authentication)
• Hybrid or composite signature schemes
• KDFs built from hash or HMAC primitives

At present, there is no clear guidance on how these composed algorithms should be classified, represented, or related to their underlying primitives in the dataset.

Rationale

We need a consistent approach to:

• Define what constitutes a composed cryptographic algorithm
• Decide whether and how these constructions should be:
  • Included as first-class entries?
  • Linked to their underlying primitives?
• Avoid ambiguity or duplication in the dataset

Without this, different contributors may classify or model these algorithms inconsistently.

Description

This issue focuses on:

• Algorithms that are explicit compositions of two or more primitives
• Constructions that are recognized and named as standalone algorithms in standards or practice

Out of scope:

• Simple parameterizations of a single primitive
• Implementation-specific combinations that are not standardized or widely recognized

The following questions should be addressed:

• Definition
  • What criteria determine when a composition becomes a “new algorithm” vs. just a usage pattern?
• Classification
  • Should composed algorithms have their own category/type?
  • How do they fit into the existing taxonomy?
• Representation
  • How should relationships be expressed? Ideas:
    • composed_of
    • depends_on
    • other? No relation?
• Naming conventions
  • Should composed algorithms follow standardized names only?
  • How to handle variants?

Actions

Definition of "composed cryptographic algorithm"

• Create a definition proposal
• Discuss it within the Cryptography Group
• Agreed definition of “composed cryptographic algorithm”

Proposal

• Create a proposal for the crypto algorithm parameters description document including
  • Clear modeling rules for inclusion in the dataset
  • Documented relationship structure between composed algorithms and primitives
• Provide a set of initial examples implemented following the agreed approach
• Discuss the proposal within the Cryptography Group
• Reach out consensus

PR

• Create a PR including the properties description changes to address the composite algorithms
• Approve the PR

DoD

• Link to the definition:
• Link to the agreed proposal:
• Link to the PR:
• Link to the properties description document including the properties related to the composite algorithms:

Start by reviewing the existing crypto algorithm parameters description and prepare a definition proposal for composed cryptographic algorithms. Discuss the definition and modeling rules with the Cryptography Group, including relationships, naming, and examples. Done means the proposal reaches consensus and links to the definition, proposal, PR, and updated properties description are available.