Restructure the List: cryptoClass and cryptoSubClass

[toscalix]

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 cryptoSubClass proposal to adapt to the new cryptoClass property description #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 cryptoSubClass values associated to the new cryptoClass values #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: Restructure the List: cryptoClass and cryptoSubClass #68 (comment)
• Link to the PR: cryptoClass and cryptoSubClass properties description #71
• Link to the reformed crypto-algorithms-list-properties-description.md including the new categorization
• Link to the affected algorithms

[toscalix]

Now

Please check the current property description at crypto-algorithms-list-properties-description.md as well as the proposal made by @metaeffekt

cryptoClass

• Description: cryptographic algorithms are categorized in classes. The classes are defined by the number of cryptographic keys that are used in conjunction with the algorithm.
  • Cryptographic hash functions do not require keys for their basic operation.
  • Symmetric-key algorithms transform data in a way that is fundamentally difficult to undo without knowledge of a secret key. The key is “symmetric” because the same key is used for a cryptographic operation and its inverse
  • Asymmetric-key algorithms, commonly known as public-key algorithms, use two related keys (i.e., a key pair) to perform their functions: a public key and a private key. The public key may be known by anyone; the private key should be under the sole control of the entity that “owns” the key pair. Even though the public and private keys of a key pair are related, knowledge of the public key cannot be used to determine the private key.
• Cardinality: [1]
• Values: "Cryptographic-Hash-Function" , "Symmetric-Key-Algorithm" or "Asymmetric-Key-Algorithm"

Note: the subclasses has been added to the cryptoClass property, separated by a "/" character from the class. This specific way to structure the subclasses is WIP.

Proposal

cryptoClass

• Description: cryptographic algorithms are categorized in classes. The classes are defined by the number of cryptographic keys that are used in conjunction with the algorithm, their functional nature, or their resistance to specific computational threats.
  • Cryptographic-Hash-Function: Cryptographic hash functions do not require keys for their basic operation.
  • Symmetric-Key-Algorithm: Symmetric-key algorithms transform data in a way that is fundamentally difficult to undo without knowledge of a secret key. The key is “symmetric” because the same key is used for a cryptographic operation and its inverse.
  • Asymmetric-Key-Algorithm: Asymmetric-key algorithms, commonly known as public-key algorithms, use two related keys (i.e., a key pair) to perform their functions: a public key and a private key. The public key may be known by anyone; the private key should be under the sole control of the entity that “owns” the key pair. Even though the public and private keys of a key pair are related, knowledge of the public key cannot be used to determine the private key.
  • Post-Quantum-Cryptography: These algorithms are designed to remain secure against the unique computational capabilities of future quantum computers, specifically resisting attacks based on Shor's or Grover's algorithms. They typically rely on mathematical structures such as lattices, codes, or multivariate equations that are believed to be quantum-resistant.
  • Message-Authentication-Code: These algorithms provide data origin authentication and integrity protection by requiring a shared secret key between the sender and receiver to generate a tag. Unlike simple hash functions, they ensure that a message cannot be tampered with by an attacker who does not possess the secret key.
  • Key-Derivation-Function: These functions derive one or more secret keys from a master secret, password, or other entropy source through a process of stretching or compression. They are essential for transforming human-readable passwords or raw keying material into secure, fixed-length keys suitable for other cryptographic operations.
  • Random-Number-Generator: These mechanisms produce sequences of bits or numbers that lack any predictable pattern and are used to ensure the unpredictability of cryptographic keys and nonces. They include both hardware-based true random number generators and deterministic algorithms that expand a small entropy seed into a larger sequence.
• Cardinality: [1]
• Values: "Cryptographic-Hash-Function", "Symmetric-Key-Algorithm", "Asymmetric-Key-Algorithm", "Post-Quantum-Cryptography", "Message-Authentication-Code", "Key-Derivation-Function", or "Random-Number-Generator"

[toscalix]

Do the current algorithms fit in the proposed cryptoClass ?

I have gone through the exercise to evaluate all the algorithms and structure them into the above seven categories. Here are some results that might require analysis. Please bare in mind that I am no expert in the field:

1. Cryptographic-Hash-Function

Algorithms with no keys, producing a fixed-length digest.

ID	Full Name	Current cryptoClass
blake2	BLAKE2	Cryptographic-Hash-Function/Hash-Function
blake3	BLAKE3	Cryptographic-Hash-Function/Hash-Function
blakex	BLAKE Hash Function	Cryptographic-Hash-Function/Hash-Function
haval	HAVAL Hash Function	Cryptographic-Hash-Function/Hash-Function
keccak	Keccak Hash Function	Cryptographic-Hash-Function/Hash-Function
md160	RACE Integrity Primitives Evaluation Message Digest	Cryptographic-Hash-Function/Hash-Function
md2	Message-Digest Algorithm 2	Cryptographic-Hash-Function/Hash-Function
md4	Message-Digest Algorithm 4	Cryptographic-Hash-Function/Hash-Function
md5	Message-Digest Algorithm 5	Cryptographic-Hash-Function/Hash-Function
md6	Message-Digest Algorithm 6	Cryptographic-Hash-Function/Hash-Function
mdc2	Modification Detection Code 2	Cryptographic-Hash-Function/Hash-Function
ripemd	RIPEMD Hash Function	Cryptographic-Hash-Function/Hash-Function
shax	SHA-x (SHA-1, SHA-256, etc.)	Cryptographic-Hash-Function/Hash-Function
shs	Secure Hash Standard	Cryptographic-Hash-Function/Hash-Function
skein	Skein Hash Function	Cryptographic-Hash-Function/Hash-Function
snerfu	SNERFU Hash Function	Cryptographic-Hash-Function/Hash-Function
ssha	Salted Secure Hash Algorithm	Cryptographic-Hash-Function/Hash-Function
tiger	Tiger Hash Function	Cryptographic-Hash-Function/Hash-Function
whirlpool	Whirlpool Hash Function	Cryptographic-Hash-Function/Hash-Function
dcc	Direct Code Construction	Cryptographic-Hash-Function/Hash-Function
crc16	Cyclic Redundancy Check 16-bit	Cryptographic-Hash-Function/Checksum
crc32	Cyclic Redundancy Check 32-bit	Cryptographic-Hash-Function/Checksum
fletcher	Fletcher's Checksum	Cryptographic-Hash-Function/Checksum

---

2. Symmetric-Key-Algorithm

Block ciphers and stream ciphers that use a single shared secret key.

ID	Full Name	Current cryptoClass
3des	Triple Data Encryption Standard	Symmetric-Key-Algorithm/Block-Cipher
3way	3-Way Block Cipher	Symmetric-Key-Algorithm/Block-Cipher
aes	Advanced Encryption Standard	Symmetric-Key-Algorithm/Block-Cipher
aria	Aria Block Cipher	Symmetric-Key-Algorithm/Block-Cipher
blowfish	Blowfish Cipher	Symmetric-Key-Algorithm/Block-Cipher
camellia	Camellia Cipher	Symmetric-Key-Algorithm/Block-Cipher
cast	Carlisle Adams and Stafford Tavares	Symmetric-Key-Algorithm/Block-Cipher
chacha	ChaCha Stream Cipher	Symmetric-Key-Algorithm/Stream-Cipher
cmea	Cellular Message Encryption Algorithm	Symmetric-Key-Algorithm/Stream-Cipher
cobra	Cobra Cipher	Symmetric-Key-Algorithm/Block-Cipher
des	Data Encryption Standard	Symmetric-Key-Algorithm/Block-Cipher
desede	Data Encryption Standard – Encrypt-Decrypt-Encrypt	Symmetric-Key-Algorithm/Block-Cipher
f8	F8 Confidentiality Mode (F8 Mode)	Symmetric-Key-Algorithm/Stream-Cipher
fcrypt	Fast DES	Symmetric-Key-Algorithm/Block-Cipher
feal	Fast Data Encipherment Algorithm	Symmetric-Key-Algorithm/Block-Cipher
gea0-x	GPRS Encryption Algorithm version 0	Symmetric-Key-Algorithm/Stream-Cipher
gost	GOST Block Cipher	Symmetric-Key-Algorithm/Block-Cipher
grain	Grain Stream Cipher	Symmetric-Key-Algorithm/Stream-Cipher
hc128	Hongjun Wu's Cipher 128	Symmetric-Key-Algorithm/Stream-Cipher
hc256	Hongjun Wu's Cipher 256	Symmetric-Key-Algorithm/Stream-Cipher
ice	Information Concealment Engine	Symmetric-Key-Algorithm/Block-Cipher
idea	International Data Encryption Algorithm	Symmetric-Key-Algorithm/Block-Cipher
juniper	Juniper Cipher	Symmetric-Key-Algorithm/Block-Cipher
kazumi	Kazumi Cipher	Symmetric-Key-Algorithm/Block-Cipher
khazad	Khazad Block Cipher	Symmetric-Key-Algorithm/Block-Cipher
loki91	LOKY91 Block Cipher	Symmetric-Key-Algorithm/Block-Cipher
lucifer	Lucifer Cipher	Symmetric-Key-Algorithm/Block-Cipher
misty1	MISTY1 Block Cipher	Symmetric-Key-Algorithm/Block-Cipher
multi2	MULTI2 Cipher	Symmetric-Key-Algorithm/Block-Cipher
nimbus	Nimbus Cipher	Symmetric-Key-Algorithm/Block-Cipher
noekeon	NOEKEON Block Cipher	Symmetric-Key-Algorithm/Block-Cipher
quad	Quad Cipher	Symmetric-Key-Algorithm/Stream-Cipher
rabbit	Rabbit Stream Cipher	Symmetric-Key-Algorithm/Stream-Cipher
rc2	Rivest Cipher 2	Symmetric-Key-Algorithm/Block-Cipher
rc4	Rivest Cipher 4	Symmetric-Key-Algorithm/Stream-Cipher
rc5	Rivest Cipher 5	Symmetric-Key-Algorithm/Block-Cipher
rc6	Rivest Cipher 6	Symmetric-Key-Algorithm/Block-Cipher
rijndael	Rijndael - AES Candidate Algorithm	Symmetric-Key-Algorithm/Block-Cipher
salsa10	Salsa10 Stream Cipher	Symmetric-Key-Algorithm/Stream-Cipher
salsa20	Salsa20 Stream Cipher	Symmetric-Key-Algorithm/Stream-Cipher
sapphire	SAPPHIRE Cipher	Symmetric-Key-Algorithm/Stream-Cipher
seal	Software-Optimized Encryption Algorithm Cipher	Symmetric-Key-Algorithm/Stream-Cipher
seed	SEED Block Cipher	Symmetric-Key-Algorithm/Block-Cipher
serpent	Serpent Block Cipher	Symmetric-Key-Algorithm/Block-Cipher
shacal	SHACAL Block Cipher	Symmetric-Key-Algorithm/Block-Cipher
shark	SHARK Block Cipher	Symmetric-Key-Algorithm/Block-Cipher
skipjack	Skipjack Block Cipher	Symmetric-Key-Algorithm/Block-Cipher
sms4	SMS4 Block Cipher	Symmetric-Key-Algorithm/Block-Cipher
snow	SNOW Stream Cipher	Symmetric-Key-Algorithm/Stream-Cipher
sober	SOBER Stream Cipher	Symmetric-Key-Algorithm/Stream-Cipher
sosemanuk	SOSEMANUK Stream Cipher	Symmetric-Key-Algorithm/Stream-Cipher
tcrypt	TCRYPT Encryption	Symmetric-Key-Algorithm/Block-Cipher
tdes	Triple Data Encryption Standard	Symmetric-Key-Algorithm/Block-Cipher
tea	Tiny Encryption Algorithm	Symmetric-Key-Algorithm/Block-Cipher
threefish	Threefish Block Cipher	Symmetric-Key-Algorithm/Block-Cipher
tnepres	TNEPRES Block Cipher (Reverse Serpent)	Symmetric-Key-Algorithm/Block-Cipher
twofish	Twofish Block Cipher	Symmetric-Key-Algorithm/Block-Cipher
vmpc	VMPC Stream Cipher	Symmetric-Key-Algorithm/Stream-Cipher
wake	WAKE Stream Cipher	Symmetric-Key-Algorithm/Stream-Cipher
xtea	eXtended Tiny Encryption Algorithm	Symmetric-Key-Algorithm/Block-Cipher
zipcrypt	ZipCrypt Encryption	Symmetric-Key-Algorithm/Block-Cipher
zuc	ZUC Stream Cipher	Symmetric-Key-Algorithm/Stream-Cipher

---

3. Asymmetric-Key-Algorithm

Algorithms using a public/private key pair.

ID	Full Name	Current cryptoClass
blum-goldwasser	Blum-Goldwasser Probabilistic Encryption	Asymmetric-Key-Algorithm/Public-Key-Cipher
dhe	Diffie-Hellman Ephemeral	Asymmetric-Key-Algorithm/Key-Exchange-Mechanism
dhies	Diffie-Hellman Integrated Encryption Scheme	Asymmetric-Key-Algorithm/Hybrid-Cipher
diffiehellman	Diffie-Hellman Key Exchange	Asymmetric-Key-Algorithm/Key-Exchange-Mechanism
dsa	Digital Signature Algorithm	Asymmetric-Key-Algorithm/Digital-Signature
ecdh	Elliptic-Curve Diffie-Hellman	Asymmetric-Key-Algorithm/Key-Exchange-Mechanism
ecmqv	Elliptic Curve Menezes-Qu-Vanstone	Asymmetric-Key-Algorithm/Key-Exchange-Mechanism
elgamal	ElGamal Encryption System	Asymmetric-Key-Algorithm/Public-Key-Cipher
luc	LUC Public Key System	Asymmetric-Key-Algorithm/Public-Key-Cipher
mqv	Menezes-Qu-Vanstone	Asymmetric-Key-Algorithm/Key-Exchange-Mechanism
rabin	Rabin Encryption Algorithm	Asymmetric-Key-Algorithm/Public-Key-Cipher
rsa	Rivest–Shamir–Adleman Algorithm	Asymmetric-Key-Algorithm/Public-Key-Cipher
xtr	XTR Public Key System	Asymmetric-Key-Algorithm/Public-Key-Cipher
mceliece	McEliece Cryptosystem	Asymmetric-Key-Algorithm/Public-Key-Cipher (see also §4)
ntruencrypt	N-th degree TRuncated polynomial Ring Units	Asymmetric-Key-Algorithm/Public-Key-Cipher (see also §4)

4. Post-Quantum-Cryptography

Algorithms designed to resist attacks from quantum computers (Shor's / Grover's algorithms). Both entries below also appear in §3, as they are asymmetric algorithms that happen to be quantum-resistant. Whether they should carry a single class or both is a key open question for the group.

ID	Full Name	Current cryptoClass	Quantum-resistance basis
mceliece	McEliece Cryptosystem	Asymmetric-Key-Algorithm/Public-Key-Cipher	Code-based (error-correcting codes)
ntruencrypt	N-th degree TRuncated polynomial Ring Units	Asymmetric-Key-Algorithm/Public-Key-Cipher	Lattice-based

---

5. Message-Authentication-Code

Algorithms that combine a shared secret key with a hash to guarantee both integrity and data origin.

ID	Full Name	Current cryptoClass
cmac	Cipher-based Message Authentication Code	Cryptographic-Hash-Function/Message-Authentication-Code

---

6. Key-Derivation-Function

Functions that derive cryptographic keys from a password, master secret, or entropy source.

ID	Full Name	Current cryptoClass
argon2	Argon2	Key-Derivation-Function
bcrypt	OpenBSD Blowfish Password Hashing Scheme	Cryptographic-Hash-Function/Password-Hashing
mscash	MSCash Password Hashing	Cryptographic-Hash-Function/Password-Hashing
mscash2	MSCash2 Password Hashing	Cryptographic-Hash-Function/Password-Hashing
pbkdf1	Password-Based Key Derivation Function 1	Cryptographic-Hash-Function/Key-Derivation
pbkdf2	Password-Based Key Derivation Function 2	Cryptographic-Hash-Function/Key-Derivation
pbe	Password-Based Encryption	Symmetric-Key-Algorithm/Key-Derivation
pbes1	Password-Based Encryption Scheme 1	Symmetric-Key-Algorithm/Key-Derivation
pbes2	Password-Based Encryption Scheme 2	Symmetric-Key-Algorithm/Key-Derivation

---

7. Random-Number-Generator

Mechanisms that produce unpredictable bit sequences for use as keys, nonces, etc.

ID	Full Name	Current cryptoClass
fortuna	Fortuna Random Number Generator	Symmetric-Key-Algorithm/Random-Number-Generator
isaac	ISAAC Random Number Generator	Symmetric-Key-Algorithm/Random-Number-Generator
yarrow	Yarrow Random Number Generator	Symmetric-Key-Algorithm/Random-Number-Generator

---

The following algorithms require deeper analysis

8. Multiple or debatable fit

These algorithms raise classification ambiguity under the proposal and may require discussion before a single value can be assigned.

ID	Full Name	Current cryptoClass	Possible new classes	Reason for ambiguity
adler32	Adler-32	Cryptographic-Hash-Function/Hash-Function	Cryptographic-Hash-Function or no fit	Currently listed as a hash function, but Adler-32 is a checksum with no preimage or collision resistance
fasthash	FastHash Algorithm	Cryptographic-Hash-Function/Hash-Function	Cryptographic-Hash-Function or no fit	Non-cryptographic hash function; lacks standard security guarantees
fnv1	Fowler-Noll-Vo Hash Function	Cryptographic-Hash-Function/Hash-Function	Cryptographic-Hash-Function or no fit	Non-cryptographic hash; commonly used for hash tables, not security
panama	PANAMA Hash and Stream Cipher	Symmetric-Key-Algorithm/Stream-Cipher	Symmetric-Key-Algorithm and/or Cryptographic-Hash-Function	PANAMA was designed as both a stream cipher and a cryptographic hash function
rc4-hmac	RC4 with HMAC-MD5	Symmetric-Key-Algorithm/Stream-Cipher	Symmetric-Key-Algorithm and/or Message-Authentication-Code	Composite: RC4 stream cipher combined with HMAC-MD5 authentication
mceliece	McEliece Cryptosystem	Asymmetric-Key-Algorithm/Public-Key-Cipher	Asymmetric-Key-Algorithm and/or Post-Quantum-Cryptography	Asymmetric public-key cipher that is also quantum-resistant (code-based)
ntruencrypt	N-th degree TRuncated polynomial Ring Units	Asymmetric-Key-Algorithm/Public-Key-Cipher	Asymmetric-Key-Algorithm and/or Post-Quantum-Cryptography	Asymmetric public-key cipher that is also quantum-resistant (lattice-based)

9. Deeper evaluation required

These algorithms do not map cleanly to any of the seven proposed values. They are included in the current list but may require an explicit decision about whether they belong in this list at all or the structure needs to adapt.

ID	Full Name	Current cryptoClass	Reason for no fit
asn1	Abstract Syntax Notation One	Symmetric-Key-Algorithm/Encoding	ASN.1 is a data encoding notation, not a cryptographic algorithm
ansix931	ANSI X9.31	Protocol-Standard	Protocol/standard document; could map to Random-Number-Generator (its PRNG component) or Asymmetric-Key-Algorithm (its digital signature component), but neither is precise
ansix942	ANSI X9.42	Protocol-Standard	Protocol standard for DH key agreement; no single class fits
ansix963	ANSI X9.63	Protocol-Standard	Protocol standard for EC-based key derivation; closest to Key-Derivation-Function but is a standard, not an algorithm
cms	Cryptographic Message Syntax	Asymmetric-Key-Algorithm/Protocol	Protocol/syntax standard that uses asymmetric algorithms but is not itself an algorithm
pkcs7	Public Key Cryptography Standards 7	Asymmetric-Key-Algorithm/Protocol	Protocol/container format, same issue as cms
pkcs12	Public Key Cryptography Standards 12	Asymmetric-Key-Algorithm/Protocol	Container format for keys/certificates, not an algorithm class
X509	ITU-T X.509 — Public Key Infrastructure Certificate Framework	Asymmetric-Key-Algorithm/Protocol	Certificate framework standard, not an algorithm
srp	Secure Remote Password Protocol	Asymmetric-Key-Algorithm/Protocol	Authentication protocol, not a standalone algorithm class

Personal note

Checksums

crc16 / crc32 / fletcher are currently under Cryptographic-Hash-Function We can address them through cryptoSubClass as Checksum, as they are right now

Consideration about Post-Quantum-Cryptography

As you can see, the following algorithms:

• mceliece: McEliece Cryptosystem
• ntruencrypt: N-th degree TRuncated polynomial Ring Units

are Asymmetric-Key-Algorithm and Post-Quantum-Cryptography. The same would apply, for instance, to these algorithms we do not have on our list yet:

• kyber: ml-kemCRYSTALS-Kyber (ML-KEM)
• dilithium: ml-dsaCRYSTALS-Dilithium (ML-DSA)
• falcon: fn-dsaFALCON (FN-DSA)
• sphincsplus: slh-dsaSPHINCS+ (SLH-DSA)
• bike: Bit Flipping Key Encapsulation
• hqc: Hamming Quasi-Cyclic
• frodokem: FrodoKEM
• xmss: eXtended Merkle Signature Scheme

Should we consider Post-Quantum-Cryptography something different than a cryptoClass? We discussed this question during a meeting of the Cryptography Group and we agreed that we would like to consider it a cryptoClass but the more I work with it as a cryptoClass, the more convinced I am that we should not.

I am more inclined to define another dimension in our classification for pre/post Quantum-Cryptography. For instance:

We can consider within this potentially new PQC property:

• quantum-resistant vs post-quantum
  • quantum-resistant — already safe against known quantum attacks (symmetric, hash-based)
  • post-quantum — specifically designed as a replacement for quantum-broken asymmetric schemes
• PQC type: functional type and math basis
  • KEMs and signatures
  • hash-based, code-based, lattice-based...

Considerations about Protocols and Standards

One of the consequences of reorganising the list is to address what do we do with:

• Protocols:
  • ansix931
  • ansix942
  • ansix963
  • cms
  • pkcs7
  • pkcs12
  • srp
• Standards
  • asn1
• Certificates
  • X509

This is a long standing question that can be addressed at this time. #49

Should we remove protocols, standards (notation) and certificates from the list?

Cryptographic Hash Functions with no cryptographic security properties

In the current version of the list we have not got into considering those cryptographic Hash Functions with no crypto security properties.

The following algorithms are affected:

• adler-32
• crc16 and crc32
• flathash
• fletcher
• fnv1

Are they cryptographic algorithms? Should we exclude them from the list?

Some algorithms the can fit more than one cryptoClass

The below statement would require confirmation from an expert:

• panama: PANAMA was designed as both a stream cipher and a cryptographic hash function
• rc4-hmac is a composition of more than one "primitive". It combines combines:
  • rc4: a symmetric stream cipher (encryption), which functionally provides confidentiality
  • hmac: message authentication, which functionally provides integrity and authentication

These two example challenge our structure. How can we solve them:

• For panama we can either:
  • Consider only one of the options or
  • Challenge the cardinality for these cases
• For rc4-hmac we can create a new cryptoClass composite cryoptographic constructions (or Composite) and address this and other cases.

The algorithms

• pbe
• pbes1
• pbes2

Could also belong to this new cryptoClass: Composite. Other options that are not currently on the list but we can consider are:

• ecies
• hkdf
• chacha20-poly1305
• aes-gcm

We could describe Composite as: Indicates the algorithm is a construction combining multiple primitives, or algorithms from different cryptoClass

[toscalix]

After the meeting of the Cryptography Group held on 2026-04-22. the proposal for CryptoClass is the following

Now

Please check the current property description at crypto-algorithms-list-properties-description.md as well as the proposal made by @metaeffekt

cryptoClass

• Description: cryptographic algorithms are categorized in classes. The classes are defined by the number of cryptographic keys that are used in conjunction with the algorithm.
  • Cryptographic hash functions do not require keys for their basic operation.
  • Symmetric-key algorithms transform data in a way that is fundamentally difficult to undo without knowledge of a secret key. The key is “symmetric” because the same key is used for a cryptographic operation and its inverse
  • Asymmetric-key algorithms, commonly known as public-key algorithms, use two related keys (i.e., a key pair) to perform their functions: a public key and a private key. The public key may be known by anyone; the private key should be under the sole control of the entity that “owns” the key pair. Even though the public and private keys of a key pair are related, knowledge of the public key cannot be used to determine the private key.
• Cardinality: [1]
• Values: "Cryptographic-Hash-Function" , "Symmetric-Key-Algorithm" or "Asymmetric-Key-Algorithm"

Note: the subclasses has been added to the cryptoClass property, separated by a "/" character from the class. This specific way to structure the subclasses is WIP.

Proposal

cryptoClass

• Description: cryptographic algorithms are categorized in classes. The classes are defined by the number of cryptographic keys that are used in conjunction with the algorithm, their functional nature, or their resistance to specific computational threats.
  • Cryptographic-Hash-Function: Cryptographic hash functions do not require keys for their basic operation.
  • Symmetric-Key-Algorithm: Symmetric-key algorithms transform data in a way that is fundamentally difficult to undo without knowledge of a secret key. The key is “symmetric” because the same key is used for a cryptographic operation and its inverse.
  • Asymmetric-Key-Algorithm: Asymmetric-key algorithms, commonly known as public-key algorithms, use two related keys (i.e., a key pair) to perform their functions: a public key and a private key. The public key may be known by anyone; the private key should be under the sole control of the entity that “owns” the key pair. Even though the public and private keys of a key pair are related, knowledge of the public key cannot be used to determine the private key.
  • Message-Authentication-Code: These algorithms provide data origin authentication and integrity protection by requiring a shared secret key between the sender and receiver to generate a tag. Unlike simple hash functions, they ensure that a message cannot be tampered with by an attacker who does not possess the secret key.
  • Key-Derivation-Function: These functions derive one or more secret keys from a master secret, password, or other entropy source through a process of stretching or compression. They are essential for transforming human-readable passwords or raw keying material into secure, fixed-length keys suitable for other cryptographic operations.
  • Random-Number-Generator: These mechanisms produce sequences of bits or numbers that lack any predictable pattern and are used to ensure the unpredictability of cryptographic keys and nonces. They include both hardware-based true random number generators and deterministic algorithms that expand a small entropy seed into a larger sequence.
• Cardinality: [1]
• Values: "Cryptographic-Hash-Function", "Symmetric-Key-Algorithm", "Asymmetric-Key-Algorithm", "Message-Authentication-Code", "Key-Derivation-Function", or "Random-Number-Generator"

---

Quantum readiness

Finally the agreement is treating the Quantum element of the algorithm as a separate property, with its own definition and structure.

Algorithms that fall into two cryptoClass

panama: PANAMA was designed as both a stream cipher and a cryptographic hash function
[...]
For panama we can either:

• Consider only one of the options or
• Challenge the cardinality for these cases

With the panama algorithm case the consensus is to assign it to Stream Cipher cryptoClass. Challenging the list structure for a single algorithm is not worth it at the moment. If additional algorithm are proposed that challenge the current cryptoClass structure, in this case its cardinality, The Cryptography Group should reconsider this consensus.

Composite

Once the proposal is approved and deployed, and we deal with the new property for quantum ready algorithms, we will focus on the composite algorithms.