pith. sign in

arxiv: 2606.13425 · v1 · pith:NMFQ5DA7new · submitted 2026-06-11 · 💻 cs.CR

An Assessment Framework for Application-Level Cryptographic Agility

Navaneeth Rameshan , Gregoire Messmer This is my paper

Pith reviewed 2026-06-27 06:16 UTC · model grok-4.3

classification 💻 cs.CR
keywords cryptographic agilitypost-quantum cryptographyAPI assessmentalgorithm migrationcryptographic APIskey managementapplication securitysoftware engineering
0
0 comments X

The pith

Existing cryptographic APIs all lack three capabilities required for agile post-quantum migration.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper introduces a framework to evaluate how readily applications can replace their cryptographic algorithms when standards change. It decomposes agility into seven orthogonal dimensions that track code coupling to specific algorithms and providers, a cross-cutting decoupling mechanism, governance authority, and two migration enablers. When the framework is applied to six representative APIs, every system fails on the same three points: intent-based key creation, policy-driven algorithm selection separate from access control, and dedicated operations to transform existing keys to new algorithms. Each of these absences by itself blocks a complete migration without application changes. This accounts for why the coming post-quantum transition continues to demand substantial software engineering effort.

Core claim

Application-level cryptographic agility can be characterized along seven orthogonal dimensions—three coupling dimensions measuring what application code knows about algorithms and providers, a cross-cutting decoupling mechanism, a governance authority dimension, and two agility enablers measuring actual migration capability—and evaluation of PKCS#11, OpenSSL 3.0, JCA, Google Tink, AWS KMS, and HashiCorp Vault Transit against this framework shows that no system supports intent-based key creation, policy-driven algorithm selection as distinct from access control, or dedicated first-class operations for algorithm transformation of existing keys, with each gap individually sufficient to prevent

What carries the argument

Seven-dimensional component-based assessment framework that produces non-linear, non-hierarchical profiles of coupling, decoupling, governance, and enablers.

If this is right

  • No evaluated system can replace algorithms without rewriting application code that hard-codes algorithm or provider knowledge.
  • Algorithm selection cannot be driven by external security policy independent of access-control rules.
  • Existing keys and material cannot be updated to new algorithms through first-class operations, forcing custom and error-prone transformation code.
  • The post-quantum transition will require significant software engineering work beyond what current APIs supply.
  • New APIs can be scored on the same seven dimensions to detect similar gaps before deployment.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Future cryptographic libraries should add first-class support for intent-based key creation and algorithm transformation to reduce migration cost.
  • The same dimensional approach could expose agility shortfalls in adjacent areas such as authentication protocols or data-protection mechanisms.
  • Organizations could apply the framework when choosing libraries to match their expected migration frequency and policy needs.
  • The decomposition supplies a checklist that could be used in the initial design of new cryptographic APIs.

Load-bearing premise

The seven chosen dimensions form a complete and non-redundant decomposition of application-level cryptographic agility.

What would settle it

An API that lacks one or more of the three gaps yet still permits full algorithm replacement across an application without code changes, or a system that possesses all three capabilities yet cannot complete an agile migration.

Figures

Figures reproduced from arXiv: 2606.13425 by Gregoire Messmer, Navaneeth Rameshan.

Figure 1
Figure 1. Figure 1: The Cryptographic Agility Assessment Framework: seven orthogonal components organized into coupling dimensions [PITH_FULL_IMAGE:figures/full_fig_p005_1.png] view at source ↗
read the original abstract

The impending post-quantum transition to new cryptography will require complete replacement of algorithms within all software. The cryptographic APIs used today make this transition challenging because they were not designed with agility as a concern. There is no method for systematically assessing cryptographic agility as an overall ability. In addition to this, the term itself refers to multiple independent capabilities. Specifically, it includes replacing algorithms, selecting by policy, and substituting implementations. This lack of structured decomposition limits both the evaluation of systems and the development of cryptographically agile APIs. We introduce a component-based assessment framework that characterizes application-level cryptographic agility along seven orthogonal dimensions: three coupling dimensions that measure what the application code knows about algorithms and providers, a cross-cutting decoupling mechanism, a governance authority dimension, and two agility enablers that measure actual migration capability. The framework is non-linear and captures non-hierarchical profiles: a system may achieve high operation decoupling yet low creation decoupling, or strong versioning without externalized configuration. We evaluate six representative APIs (PKCS#11, OpenSSL~3.0, JCA, Google Tink, AWS KMS, and HashiCorp Vault Transit) against the framework, revealing three pervasive and independent gaps: no system supports intent-based key creation, none provides policy-driven algorithm selection (as distinct from access control), and none offers dedicated/first-class operations for algorithm transformation of existing keys. These gaps are individually sufficient to prevent agile migration, explaining why the post-quantum transition remains a software engineering problem despite decades of API progress.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 1 minor

Summary. The paper introduces a component-based assessment framework for application-level cryptographic agility decomposed along seven orthogonal dimensions (three coupling dimensions measuring application knowledge of algorithms/providers, one cross-cutting decoupling mechanism, a governance authority dimension, and two agility enablers measuring migration capability). The framework is non-linear and supports non-hierarchical profiles. It evaluates six APIs (PKCS#11, OpenSSL 3.0, JCA, Google Tink, AWS KMS, HashiCorp Vault Transit) and identifies three pervasive gaps—no support for intent-based key creation, no policy-driven algorithm selection distinct from access control, and no dedicated/first-class operations for algorithm transformation of existing keys—claiming these gaps are individually sufficient to prevent agile migration and explaining the persistent software-engineering challenges of the post-quantum transition.

Significance. If the seven-dimensional decomposition is shown to be exhaustive and the gap assessments are reproducible, the framework would supply a structured, profile-based method for evaluating and comparing cryptographic APIs on agility, potentially informing the design of APIs that better support algorithm replacement. The explicit separation of coupling, decoupling, governance, and enablers, together with the non-linear characterization, is a constructive contribution that moves beyond informal notions of agility. The significance is limited by the absence of external validation that the chosen axes capture all material capabilities.

major comments (2)
  1. [Abstract; Framework Definition] The central claim that the three identified gaps are individually sufficient to prevent agile migration depends on the seven dimensions forming a complete, non-redundant characterization of application-level cryptographic agility. The manuscript asserts this completeness by construction when defining the dimensions and applying them to the six APIs, but supplies no independent argument, external evidence, or falsification test showing that capabilities outside these axes (for example, runtime performance isolation during swaps, legacy ciphertext re-encryption semantics, or build-time static-analysis integration) are irrelevant. Without such justification the sufficiency conclusion does not follow from the framework alone.
  2. [Evaluation of Six APIs] The API evaluations that produce the three gaps are presented without reported validation data, inter-rater reliability statistics, or step-by-step derivation of how each API was scored on each dimension. This makes it impossible to verify consistency of application or to assess whether the gaps are artifacts of the chosen dimensions rather than intrinsic limitations.
minor comments (1)
  1. [Abstract] The abstract states that cryptographic agility 'refers to multiple independent capabilities. Specifically, it includes replacing algorithms, selecting by policy, and substituting implementations,' yet the framework expands this to seven dimensions; a brief mapping or justification for the expansion would improve clarity.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive and detailed comments. We address each major comment below, indicating where we will revise the manuscript to strengthen the justification for the framework and improve the transparency of the evaluations.

read point-by-point responses

  1. Referee: [Abstract; Framework Definition] The central claim that the three identified gaps are individually sufficient to prevent agile migration depends on the seven dimensions forming a complete, non-redundant characterization of application-level cryptographic agility. The manuscript asserts this completeness by construction when defining the dimensions and applying them to the six APIs, but supplies no independent argument, external evidence, or falsification test showing that capabilities outside these axes (for example, runtime performance isolation during swaps, legacy ciphertext re-encryption semantics, or build-time static-analysis integration) are irrelevant. Without such justification the sufficiency conclusion does not follow from the framework alone.

    Authors: We agree that an explicit motivation for the seven dimensions would strengthen the paper. The dimensions were derived from a systematic decomposition of the three core capabilities required for application-level cryptographic agility (algorithm replacement via creation, policy-based selection, and transformation of existing keys), together with the coupling, decoupling, governance, and enabler aspects needed to support them. This decomposition is introduced in Section 2 and applied in Section 3. In the revised manuscript we will insert a new subsection (3.1) that motivates each dimension from the requirements stated in the introduction, cites supporting literature on cryptographic API design, and explains why the listed examples (performance isolation, legacy re-encryption semantics, static-analysis integration) lie outside the scope of an application-level API assessment framework. We will also revise the abstract and conclusion to state that the sufficiency claim holds with respect to the proposed decomposition rather than asserting completeness by construction alone. revision: yes

  2. Referee: [Evaluation of Six APIs] The API evaluations that produce the three gaps are presented without reported validation data, inter-rater reliability statistics, or step-by-step derivation of how each API was scored on each dimension. This makes it impossible to verify consistency of application or to assess whether the gaps are artifacts of the chosen dimensions rather than intrinsic limitations.

    Authors: The evaluations in Section 4 are the result of the authors' detailed review of each API's official documentation, specifications, and (where publicly available) source code. Because the work is a conceptual application of the framework rather than a multi-rater empirical study, conventional inter-rater reliability statistics are not applicable. To address the reproducibility concern we will add a new appendix that supplies a dimension-by-dimension scoring table for all six APIs, with explicit citations to the API features or absences that produced each rating. This will allow readers to trace and verify the derivations independently. revision: yes

Circularity Check

0 steps flagged

No significant circularity; framework is a constructive definition with external evaluation.

full rationale

The paper defines its seven-dimensional framework explicitly as a new construction and applies the dimensions to six external APIs to identify gaps. No equations, fitted parameters, or predictions reduce to inputs by construction. No self-citations are load-bearing for the central claims, and the evaluation measurements are independent of the framework's internal definitions. The completeness of the decomposition is a modeling choice, not a self-referential reduction.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The central contribution is a newly defined framework resting on domain assumptions about the structure of agility rather than on fitted parameters or new physical entities.

axioms (1)
  • domain assumption Cryptographic agility decomposes into seven orthogonal dimensions (three coupling, one cross-cutting decoupling mechanism, one governance authority, two agility enablers) that can be measured independently.
    This decomposition is the load-bearing premise introduced by the paper and is not derived from prior equations or data.

pith-pipeline@v0.9.1-grok · 5804 in / 1253 out tokens · 20606 ms · 2026-06-27T06:16:17.377760+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

31 extracted references

  1. [1]

    Java Cryptography Architecture (JCA) Reference Guide

    Sun Microsystems. Java Cryptography Architecture (JCA) Reference Guide

  2. [2]

    https://docs.oracle.com/en/java/javase/21/security/java-cryptography- architecture-jca-reference-guide.html

  3. [3]

    EVP: High-Level Cryptographic Functions

    OpenSSL Project. EVP: High-Level Cryptographic Functions. https://www. openssl.org/docs/man3.0/man7/evp.html

  4. [4]

    Google Tink: A Multi-Language, Cross-Platform Crypto- graphic Library

    Duong, T., Nguyen, Q. Google Tink: A Multi-Language, Cross-Platform Crypto- graphic Library. Google, 2018. https://developers.google.com/tink

    2018

  5. [5]

    Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms

    Housley, R. Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms. RFC 7696, IETF, November 2015. An Assessment Framework for Application-Level Cryptographic Agility

    2015

  6. [6]

    Recommendation for Key Management: Part 1—General

    Barker, E. Recommendation for Key Management: Part 1—General. NIST SP 800- 57 Rev. 5, May 2020

    2020

  7. [7]

    Module-Lattice-Based Key-Encapsulation Mechanism Standard

    NIST. Module-Lattice-Based Key-Encapsulation Mechanism Standard. FIPS 203, August 2024

    2024

  8. [8]

    Module-Lattice-Based Digital Signature Standard

    NIST. Module-Lattice-Based Digital Signature Standard. FIPS 204, August 2024

    2024

  9. [9]

    Stateless Hash-Based Digital Signature Standard

    NIST. Stateless Hash-Based Digital Signature Standard. FIPS 205, August 2024

    2024

  10. [10]

    Developers are Not the Enemy!: The Need for Usable Security APIs.IEEE Security & Privacy, 14(5):40–46, 2016

    Green, M., Smith, M. Developers are Not the Enemy!: The Need for Usable Security APIs.IEEE Security & Privacy, 14(5):40–46, 2016

    2016

  11. [11]

    PKCS #11 Cryptographic Token Interface Base Specification Version 3.0

    OASIS. PKCS #11 Cryptographic Token Interface Base Specification Version 3.0. 2020

    2020

  12. [12]

    Key Management Interoperability Protocol (KMIP) Specification Ver- sion 2.1

    OASIS. Key Management Interoperability Protocol (KMIP) Specification Ver- sion 2.1. 2020

    2020

  13. [13]

    eXtensible Access Control Markup Language (XACML) Version 3.0

    OASIS. eXtensible Access Control Markup Language (XACML) Version 3.0. Jan- uary 2013

    2013

  14. [14]

    https://www.openpolicyagent.org/

    Open Policy Agent. https://www.openpolicyagent.org/

  15. [15]

    Cryptography Bill of Materials (CBOM) Standard, Version 1.6

    CycloneDX. Cryptography Bill of Materials (CBOM) Standard, Version 1.6. 2024. https://cyclonedx.org/

    2024

  16. [16]

    Why Does Cryptographic Software Fail? A Case Study and Open Problems

    Lazar, D., Chen, H., Wang, X., Zeldovich, N. Why Does Cryptographic Software Fail? A Case Study and Open Problems. In:Proc. 5th Asia-Pacific Workshop on Systems (APSys), pp. 7:1–7:7. ACM, 2014

    2014

  17. [17]

    Comparing the Usability of Cryptographic APIs

    Acar, Y., Backes, M., Fahl, S., Kim, D., Mazurek, M.L., Stransky, C. Comparing the Usability of Cryptographic APIs. In:Proc. IEEE Symposium on Security and Privacy (S&P), pp. 154–171, 2017

    2017

  18. [18]

    Migration to Post-Quantum Cryptography

    NIST. Migration to Post-Quantum Cryptography. SP 1800-38 (Preliminary Draft), 2024

    2024

  19. [19]

    Transitioning the Use of Cryptographic Algorithms and Key Lengths

    Barker, E., Roginsky, A. Transitioning the Use of Cryptographic Algorithms and Key Lengths. NIST SP 800-131A Rev. 3 (Initial Public Draft), October 2024

    2024

  20. [20]

    Post-Quantum Use in Protocols (PQUIP)

    Kampanakis, P., Ounsworth, M. Post-Quantum Use in Protocols (PQUIP). IETF Working Group, 2023. https://datatracker.ietf.org/group/pquip/about/

    2023

  21. [21]

    eUCRITE 1.0 API—A Usable Crypto- graphic Interface

    Zeier, A., Wiesmaier, A., Heinemann, A. eUCRITE 1.0 API—A Usable Crypto- graphic Interface. In:Proc. Information Security Practice and Experience (ISPEC), 2020

    2020

  22. [22]

    Considerations for Achieving Cryptographic Agility

    Barker, E., et al. Considerations for Achieving Cryptographic Agility. NIST, 2025

    2025

  23. [23]

    Software-Defined Cryptography: A Design Feature of Cryptographic Agility

    Cho, J., Lee, C., Kim, E., Lee, J., Cho, B. Software-Defined Cryptography: A Design Feature of Cryptographic Agility. 2024

    2024

  24. [24]

    High-Level Cryptographic Abstractions

    Kane, C., Lin, B., Chand, S., Stoller, S.D., Liu, Y.A. High-Level Cryptographic Abstractions. In:Proc. 14th ACM SIGSAC Workshop on Programming Languages and Analysis for Security (PLAS), pp. 31–43, 2019

    2019

  25. [25]

    CARAF: Crypto Agility Risk Assessment Framework.Journal of Cybersecurity, 7(1), 2021

    Ma, C., Colon, L., Dera, J., Rashidi, B., Garg, V. CARAF: Crypto Agility Risk Assessment Framework.Journal of Cybersecurity, 7(1), 2021

    2021

  26. [26]

    Toward a Common Understanding of Cryptographic Agility

    Näther, C., Herzinger, D., Steghöfer, J.-P., Gazdag, S.-L., Hirsch, E., Loebenberger, D. Toward a Common Understanding of Cryptographic Agility. 2025

    2025

  27. [27]

    EverCrypt: A Fast, Verified, Cross-Platform Cryptographic Provider

    Protzenko, J., et al. EverCrypt: A Fast, Verified, Cross-Platform Cryptographic Provider. In:Proc. IEEE Symposium on Security and Privacy (S&P), pp. 983–1002, 2020

    2020

  28. [28]

    ELCA: Introducing Enterprise-Level Cryptographic Agility for a Post-Quantum Era

    Sikeridis, D., et al. ELCA: Introducing Enterprise-Level Cryptographic Agility for a Post-Quantum Era. 2023

    2023

  29. [29]

    Building Cryptographic Agility in the Financial Sector

    FS-ISAC PQC Working Group. Building Cryptographic Agility in the Financial Sector. FS-ISAC, 2024

    2024

  30. [30]

    Towards a Maturity Model for Crypto- Agility Assessment

    Hohm, J., Heinemann, A., Wiesmaier, A. Towards a Maturity Model for Crypto- Agility Assessment. In:Foundations and Practice of Security (FPS), pp. 104–119. Springer, 2023

    2023

  31. [31]

    Intent-Based Cryptographic API Design for Crypto- graphic Agility

    Rameshan, N., Messmer, G. Intent-Based Cryptographic API Design for Crypto- graphic Agility. IBM Research Europe, 2026. [Companion paper.]

    2026