This summer the SPDX Cryptography Group agreed on how to describe algorithm parameters, tightened its contribution and release processes, and opened the discussion on post-quantum cryptography.
Where this report comes from
This is an update of the work we do at the SPDX Cryptography Group. SPDX stands for Software Package Data Exchange. Our group is focused on creating and managing the SPDX Cryptographic Algorithms List, a shared vocabulary to identify cryptographic algorithms in a consistent way.
I publish a report every quarter, so anyone interested can follow the work without reading every issue and pull request. You can read the previous ones here:
This is the 2026 summer report. It covers the period between 28 May 2026 and the beginning of September 2026.
Parameters: the consensus of the quarter
The main accomplishment has been that, after a long and detailed discussion, the group reached a consensus on how to describe parameters within the algorithms.
The agreement rests on a distinction that sounds obvious once you write it down, but that took us a long discussion to settle. A property is an intrinsic characteristic of the algorithm itself. It does not change. A parameter is an operational or configuration element. It affects how the algorithm is used. The identifier of an algorithm is a property. The mode of operation you choose when you encrypt is a parameter.
That distinction is now written in the properties and parameters description file, which replaces the old properties description document.
Two parameters have been described as an example: operationMode and keyLength. We then applied them to the fifteen block ciphers already on the List: 3des, aes, aria, blowfish, camellia, cast, des, gostr3412-2015, idea, rc2, rc5, rc6, seed, serpent and twofish.
This is how it looks in aes:
parameters: operationMode: ['ECB','CBC','CFB','OFB','CTR','XTS','GCM','CCM','SIV', ...] keyLength: ['128','192','256']
And this is gostr3412-2015, an algorithm with a shorter set of modes.
The community can now add the values of these parameters to other algorithms. Contributions of new parameters are welcome. This is the kind of work that does not require you to be a cryptographer. It requires care and a good reference. Please check this comment and the description file to understand how to describe the new parameters you are interested in.
Contribution and release process
The second line of work this summer was less visible, but it matters as much.
The contribution process has been updated. The CONTRIBUTING.md file now includes a more detailed description about how to contribute to the SPDX CryptAlg List. It describes how to propose a new algorithm in four steps: open an issue, discuss it in the community, open a pull request, and then review and merge. It also describes how to propose a correction to an existing entry, how to propose the removal of an algorithm, and how all of that relates to the release cycle. This is one of those steps that will become increasingly relevant over time.
On the same line, the release process description has been improved. It now works together with the criteria to accept new algorithms, so a contributor can see both the rules and the path.
Having a solid contribution process description, as well as transparent criteria to decide whether any contributed algorithm should be on the List, are requirements to publish the first version of the list. Without them, every decision looks arbitrary to the person outside the group.
These requirements come from the experience with creating and managing the SPDX License List. That list is used by tools and companies all over the world. It works because the process behind it is predictable. We would like to reach the same point.
Corrections to the List
A few corrections have landed into the list. The clearest one is the gost entry. Its identifier and its name were generic. They are now aligned with the standard that defines the algorithm, and the file follows the same naming. There are more corrections to come.
Next step: post-quantum cryptography
The Cryptography Group has settled, for the time being, how to describe algorithm parameters. The next big step is to classify Post-Quantum Cryptography (PQC) algorithms. After months of discussion, there is a proposal we can review.
The proposal follows a decision the group took in April. Being post-quantum is not a class of algorithm. It is a different dimension. A signature can be classical or post-quantum. The same is true for a key encapsulation mechanism. So the proposal adds a new property, called pqcClass, next to the existing cryptoClass, instead of adding a new value inside it.
The property has a single level and describes only the mathematical basis of the algorithm. It says nothing about whether the algorithm is secure, standardised or recommended. The six values come from the NIST classification:
- Lattice-Based
- Code-Based
- Multivariate
- Hash-Based
- Isogeny-Based
- MPC-in-the-Head
Together with the classification and description taxonomy, the proposal includes the description of some of the PQC algorithms, as an example. Two algorithms already on the List are affected, mceliece and ntruencrypt. Ten candidate algorithms are then described the way they would look once included, among them ML-KEM, ML-DSA, SLH-DSA and Classic McEliece.
The proposal is work in progress. The parameters of these algorithms are deferred on purpose, one problem at a time. Several questions are still open. How do we treat a hybrid scheme that combines a classical and a post-quantum algorithm? How do we handle identifiers when one algorithm has many parameter sets? Do we need a new subclass value for key encapsulation mechanisms, which today we describe with a value that means something else? These questions will be a matter of discussion in the near future since they are not blockers for the current proposal. The examples also need review from cryptography experts before anything is merged.
The goal is to be able to merge both, the classification structure description and the candidate algorithms that serve as example. This way it will be easier for anyone to contribute new PQC algorithms including the correct description.
The main goal: publishing version one
Publishing the first version of the list in the SPDX site remains our main goal. Everything described above points there.
New topics have emerged as points for discussion and ToDos during this past few months, which is normal. But once we finish with the first iteration of the PQC cryptographic algorithms description, we will most likely focus on the release process of the first stable version of the list.
Open discussion points
Some of these discussion points are:
- The current syntax of the taxonomy should be revisited to add more coherence through stricter and more verbose rules. This is a point where we will look for compatibility with standardization bodies.
- The current operationMode parameter description can be extended, to reflect specific parameter configurations instead of generic ones. Today an entry says which modes an algorithm supports. It does not say under which conditions.
- How are we going to describe PQC algorithm parameters? Will the taxonomy be analogous to the classical one, or should we create a specific way of describing them, based on their characteristics? This is something we need to work on.
A thank you note
Most of 2025 my participation at the SPDX Cryptography Group was sponsored by SCANOSS directly. The it took over the Software Transparency Foundation, until this July 2026. I take the opportunity to thank SCANOSS and the STF for their invaluable contribution to kick-off and to mature the list as well as for trusting that I could make valuable contributions on their behalf to this project.
Now I am contributing on best-effort basis, which make the following section more relevant than ever.
Join us
As the List matures, the cognitive load increases, so does the need to count on more experts. If you are reading this and you know experts in cryptography, or developers willing to help us implement the release process, do not hesitate to contact me. The SPDX Cryptography Group welcomes new participants and contributors. Feel free to join our meetings and to follow our work in the repository. You do not need to commit to anything. Coming to a meeting and listening is a perfectly good first step.
Meetings take place weekly on Wednesdays at 14:00 UTC. You can join here.
Summary
During this summer the SPDX Cryptography Group agreed on how to describe parameters within algorithms, and applied that agreement to a first set of block ciphers. We also improved the documentation that governs how to contribute to the List and how to release it, which are conditions to publish the first version. The next step is to classify post-quantum cryptography algorithms. After that, we will focus on the release itself.
toscalix 