SPDX Cryptography Funding Request Document

[toscalix]

Background

The work done by the Cryptography Group is mostly done on based-effort basis, except the effort sponsored by SCANOSS first, during a few month in 2025, and STF during the last quarter of 2025 and the first half of 2026. In order to speed up the current efforts and complement the current team with people with required skills, we would need funding and/or sponsorship to take the SPDX Cryptographic Algorithms List to a maturity point where it is useful to several use cases.

Rationale

Description

Action

DoD

[toscalix]

SPDX Cryptographic Algorithm List - Funding Request Document

Table of Contents

Funding period requested: Q4 2026 and full year 2027.

1. Rationale

• State why the Cryptography Group wants to speed up work on the List now, linking to geopolitics, AI risk, PQC and new supply chain legislation.
• List the four external pressure factors (trade compliance, AI driven cybersecurity risk, post quantum readiness, supply chain legislation) as drivers for demand.
• Explain why an accurate, complete List with stable identifiers is a precondition for machine readable SBOM/CBOM based cryptography audits.
• Explain why building this List inside SPDX, rather than elsewhere, removes friction for tools that already consume SPDX data.

2. Scope

2.1 What the List covers today

• Describe the object of the List: a curated set of cryptographic algorithm identifiers, modeled on the SPDX License List.
• List the core properties captured per algorithm: id, oid, name, cryptoClass, cryptoSubClass, commonkeySize, specifiedkeySize, reference.
• State the current size and composition of the algorithm set (symmetric, asymmetric, hash, MAC, KDF, RNG) and note that Post Quantum algorithms are not yet included.

2.2 Two repository and website model

• Describe the working repository (yaml source, parser, governance documents) and the data repository (generated JSON output only).
• Describe the website as the human readable publication point, generated automatically from the data repository at each release.
• State that no manual edits are ever made to generated artifacts, only to the yaml source.

2.3 Relationship to SPDX and other standards

• Explain how SPDX profiles, such as Security and Operations, depend on the List as a shared reference.
• Reference the standards bodies whose specifications the List already draws on (NIST, IETF, ISO/IEC, ETSI, IEEE).

3. Status

3.1 Governance and process maturity

• Summarise what governance is already in place: issue first discussion, PR review, group consensus, inclusion and removal criteria.
• State what remains incomplete in the release process itself: pre release preparation and release workflow sections are still marked to be completed.
• Note that the List has not yet had a first public release, so all current changes are treated as corrections rather than breaking changes.

3.2 Algorithm coverage progress

• State how many algorithms are documented today and which families are represented or missing, referencing external coverage benchmarks such as metaeffekt's classification.
• List candidate additions under discussion, such as Magma, Kuznyechik, and NIST PQC finalists, Ascon, SM3/SM4/SM9, and modern MACs and AEADs.

3.3 Structural work in progress

• Summarise the parameter description proposal for algorithm parameters such as operation mode, and its current review stage.
• Summarise the Post Quantum Cryptography structure decision, an orthogonal property rather than a new class, and its two phase plan.
• Summarise the cryptoSubClass alignment work and the open questions still pending group decision.
• Summarise the open work on composite algorithm classification, such as HMAC or AES-GCM, tracked but not yet resolved.

4. Existing team and resources

• Describe the Cryptography Group as a volunteer, part time group operating through weekly meetings and asynchronous GitHub discussion.
• State the current roles in the group and how release responsibilities, such as Release Coordinator, rotate among members.
• List the tooling currently used or planned, including the cryptalg-parser, GitHub Actions, and MkDocs for the website.
• State the current reliance on volunteer time as the single resource funding this work today.

5. Gap

5.1 Gap between current scope and target scope

• Describe what a complete, production ready List should contain that is missing today, such as full PQC coverage and composite algorithm classification.
• Describe the gap between the current manual, discussion heavy pace and the pace needed to respond to the drivers in the Rationale section.

5.2 Gap in tooling and automation

• Describe what parts of the release pipeline and parser are not yet built or automated, referencing the incomplete sections of the release process document.
• Describe the absence of dedicated, funded engineering time to build and maintain this tooling.

5.3 Projected progress with current effort

• State what the group realistically expects to complete by the end of Q4 2026 at the current volunteer pace, with no added funding.
• State what the group realistically expects to complete during 2027 at the current volunteer pace, and why this timeline lags behind external demand.

6. Close the gap

6.1 Required resources

• List the non human resources needed, such as dedicated infrastructure, CI capacity, and website hosting guarantees.

6.2 Required skills

• State that no single cryptographer can cover the full range of cryptography skills the List needs, so the funding request covers several distinct cryptographer profiles.
• State that funding is requested only for cryptographer roles; project and release management, and taxonomy and SPDX structural work, stay on a best effort, volunteer basis and are not part of this funding ask.

Funded cryptographer roles

• Classical cryptography specialist: covers symmetric and asymmetric algorithms, hash functions, MACs, and key derivation functions already on the List, needed to review and correct entries such as cryptoClass and key size.
• Post Quantum Cryptography specialist: covers lattice, code based, hash based, multivariate, and isogeny schemes, needed to complete the isPostQuantum flag and the postQuantumProperties structure.
• Cryptographic protocol and composite construction specialist: covers combined constructions such as AEAD, HMAC, or hybrid ciphers, needed to resolve the open composite algorithm classification work.
• Regional and national algorithm specialist: covers algorithms defined by non Western standards bodies, such as GOST, SM2, SM3, SM4, and SM9, needed to verify OIDs and references correctly.
• Security and cryptanalysis tracker: covers monitoring which algorithms are broken, deprecated, or affected by new security events, needed to keep entries factually current without violating the no removal policy.

Best effort roles, not funded through this request

• Data and taxonomy modeler: covers schema and property design work, such as the parameter description format and the cryptoClass and cryptoSubClass hierarchy, kept within the existing volunteer group.
• Project and release coordinator: covers scheduling, consensus building, and driving the monthly release cadence, kept within the existing volunteer group.

Roles needing a decision

• Standards and specification analyst: covers reading and correctly citing standards documents from NIST, ISO/IEC, IETF, ETSI, and national bodies, close to cryptographer work but not stated as funded or best effort, needs a decision.
• Software engineer for the parser and release pipeline: covers development of the cryptalg-parser and the GitHub Actions release workflow, not a cryptographer role, needs a decision on whether it stays out of scope for this request or is added as a separate, non cryptographer funding line.
• Technical writer and governance editor: covers drafting and maintaining governance documents, changelogs, and release notes, not a cryptographer role, needs a decision on whether it stays out of scope for this request or is added as a separate, non cryptographer funding line.

6.3 Required team

• State that the existing Cryptography Group continues on a best effort, volunteer basis for project and release coordination and for taxonomy and SPDX structural work.
• State that funding is requested specifically for the cryptographer roles listed in section 6.2, not to replace or pay the existing volunteer team.
• Describe how funded cryptographers would plug into the existing best effort group, reporting into the same open governance process rather than working separately.
• State the estimated time commitment needed per funded cryptographer role to meet the Q4 2026 and 2027 targets.
• Flag the three roles still needing a decision in section 6.2 (standards analyst, software engineer, technical writer) and whether they are excluded from this request or added separately.

7. Proposal for funding

7.1 What should be funded

• State clearly that funding is requested for the cryptographer roles in section 6.2, while project and release coordination and taxonomy work keep operating on a best effort basis.
• List the concrete deliverables each funded cryptographer would produce: algorithm review and correction, PQC structural work, composite classification, regional algorithm verification, and security status tracking.

7.2 How funding would be used

• Describe the funding mechanism requested, such as direct grants, sponsored maintainer time, or in kind engineering contribution.
• Describe how funded work would be integrated into the existing open governance process, without bypassing group review.

7.3 Milestones tied to funding

• List milestones funding would unlock for Q4 2026, mapped to the gap items in section 5.
• List milestones funding would unlock across 2027, mapped to the gap items in section 5.

7.4 Expected impact

• Describe the expected impact for organizations and tools once the funded gaps are closed, tied back to the drivers in the Rationale section.