Restructure the List: cryptoClass and cryptoSubClass

Background

The current structure applied to the List is based on the NIST SP 800-57 categorization, that primes simplicity. It defines three categories, which are the ones we have applied as attribute cryptoClass:

• Cryptographic-Hash-Function
• Symmetric-Key-Algorithm
• Asymmetric-Key-Algorithm

@metaeffekt suggests a different approach. You can find his suggestion attached to this issue: metaeffekt-cryptalg-proposal.md

For reference, check crypto-algorithms-list-properties-description

Key differences related to cryptoClass

This proposal suggest the extension to 7 different possible values for the cryptoClass:

• Cryptographic-Hash-Function
• Symmetric-Key-Algorithm
• Asymmetric-Key-Algorithm
• Message-Authentication-Code
• Post-Quantum-Algorithm
• Key-Derivation-Function
• Random-Number-Generators

The current CryptAlg groups:

1. PQC as a subclass of Asymmetric-Key-Algorithm. .
2. MACs under Cryptographic-Hash-Function. @metaeffekt gives MACs their own category.
3. Key-Derivation as a subclass of Symmetric-Key-Algorithm. @metaeffekt gives KDFs their own category.
4. Random-Number-Generator under Symmetric-Key-Algorithm. metaeffekt gives RNGs their own category

while @metaeffekt gives it its own top-level category (cryptoClass).

Key differences related to cryptoSubClass

There are more differences in this parameter than in the previous one, given their dependencies. Two require special attention:

• The current CryptAlgo does not include block cipher modes. The current approach is to include them in the near future as parameters, not as properties. @metaeffekt places them as a cryptoSubClass of Symmetric, with a further breakdown into AEAD modes, confidentiality-only modes, key wrapping modes, and the explicitly "disallowed" ECB mode.
• In the metaeffekt proposal, several subclasses explicitly distinguish between "Approved" and "Legacy / Deprecated" algorithms (e.g., under Block Ciphers and Hash Functions). At the moment, SPDX CryptAlg has no equivalent concept at the classification level.

The proposal also includes new algorithms, which should be a topic for #43

Rationale

Post-quantum readiness is a relevant use cases the SPDX Cryptography Group identified at the start of this effort. Elevating PQC to a top-level class signals its importance explicitly and makes it much easier for tooling to filter, query, or report on PQC algorithms in isolation – something that will be increasingly important as organizations migrate their systems ahead of post-quantum deadlines.

MACs are technically distinct from hash functions: they require a secret key, while hash functions do not.

• Grouping them together under "Cryptographic-Hash-Function" is a simplification that may confuse practitioners and tooling.
• Separating them is more technically accurate and aligns with how CycloneDX treats the distinction.
• On the other hand, NIST SP 800-57 – the stated basis for the current SPDX model – does not make this separation in the same way, which creates a tension the group will need to resolve.

KDFs such as PBKDF2, bcrypt, scrypt, and Argon2 are not really "symmetric-key algorithms" in the traditional sense – they derive keys from passwords or other inputs, and several of them (bcrypt, Argon2) are widely used for password hashing in contexts that have nothing to do with symmetric encryption. Grouping them under Symmetric-Key-Algorithm is technically imprecise and may lead to misclassification in SBOM tooling. The current SPDX list already reflects this tension.

This change reflects an important operational reality: RNGs are a distinct concern in cryptographic system design, with their own standards (NIST SP 800-90A), their own failure modes, and their own audit requirements.

This proposal is partly inspired in CycloneDX and @metaeffekt suggests to reduce the current gap among the two when it comes to the List structure

Description

The proposal is:

• To extend the number of cryptoClass values to 7, in the line of @metaeffekt proposal
• To evaluate how such proposal affect to the algorithms
• Once a decision on the cryptoClass is taken, we will need to define how cryptoSubClass property is affected and which algorithms would be affected #69
• To discuss the cryptoSubClass possible values considering:
  • There is a general agreement within the Cryptography Group in considering mode as parameter, not part of the categorization of an algorithm
  • The assessment of the validity of an algorithm is out of the scope of this list
  • This effort is tracked in the sub-issue #72

Actions

cryptoClass

• Provide a proposal to reform the current cryptoClass values in crypto-algorithms-list-properties-description
  • The proposal should include the cryptographic algorithms affected
• Discuss it within the weekly meeting
• Reach consensus within the Cryptography Group
• Create a PR including
  • The property values
  • The value assigned on each of the affected cryptographic algorithms
• PR reviewed
• PR merged

cryptoSubClass

Since this ticket is getting too complex, the work on cryptoSubClass is tracked in #69

The discussion about new subcryptoClass values for the new cryptoClass values is tracked in #72

DoD

• Link to the proposal: https://github.com/spdx/cryptographic-algorithm-list/issues/68#issuecomment-4342489475
• Link to the PR: #71
• Link to the reformed crypto-algorithms-list-properties-description.md including the new categorization: link
• Link to the affected algorithms: https://github.com/spdx/cryptographic-algorithm-list/pull/71/changes

Start with docs/crypto-algorithms-list-properties-description.md and review the proposal linked in the issue, then inspect PR #71 and its changes to the affected algorithms. The cryptoClass work is marked complete; cryptoSubClass work is explicitly moved to issues #69 and #72.