pith. sign in

arxiv: 2606.13445 · v1 · pith:GISZDH2Znew · submitted 2026-06-11 · 💻 cs.CR

Intent-Based Cryptographic API Design for Cryptographic Agility

Navaneeth Rameshan , Gregoire Messmer This is my paper

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

classification 💻 cs.CR
keywords cryptographic agilitypost-quantum cryptographyintent-based APIscope-based decouplingkey evolutionalgorithm migrationstable key identifiers
0
0 comments X

The pith

An intent-based cryptographic API using scopes decouples key creation from algorithms to enable updates without rewriting application code.

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

Current cryptographic APIs bind applications to specific algorithms and lack support for policy-driven selection or key migration, complicating transitions such as those to post-quantum cryptography. The paper derives five design principles from architectural traits including abstraction, stability, temporal flexibility, separation, and extensibility, then shows their realization in Protocol Buffers patterns. Its core mechanism is a scope-based intent vocabulary that separates key creation from algorithm identities and permits transparent substitutions within each scope. Stable key identifiers plus evolution operations (rotation, transformation, migration) track history across providers and algorithms, while an abstract policy API handles governance without fixing any policy format. If the design works, organizations can treat algorithm changes as operational tasks rather than software rewrites.

Core claim

The paper presents a set of API design principles for cryptographic agility and demonstrates their use through an intent vocabulary grounded in scopes. This vocabulary decouples key creation from concrete algorithm identities, supports transparent algorithm substitutions inside the applicable scope, and pairs stable key identifiers with evolution operations that preserve original identity and history during rotation, transformation, or migration. Governance occurs through an abstract policy API that imposes no prescribed format, so that updating cryptography reduces to an operational process without application code changes.

What carries the argument

The scope-based intent vocabulary, which decouples key creation from algorithm identities to allow transparent substitutions and key evolution while tracking identity history.

If this is right

  • Algorithm transitions become operational tasks instead of code changes across large software portfolios.
  • Keys retain stable identifiers and full evolution history during migration between algorithms and providers.
  • Policy-driven selection works through an abstract API that remains independent of any specific policy format.
  • Transparent substitutions of algorithms occur automatically inside each defined scope.

Where Pith is reading between the lines

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

  • Enterprises with mixed legacy and new codebases could reduce migration effort by adopting the intent layer once rather than per-application.
  • The design would need empirical validation against usage patterns not anticipated by the five architectural characteristics.
  • Existing key-management and hardware-security-module interfaces would require mapping layers to expose the stable identifiers and evolution operations.

Load-bearing premise

The proposed intent vocabulary and scope-based decoupling will cover the full range of real-world cryptographic usage patterns without forcing developers to alter calling code when algorithms are substituted.

What would settle it

A production application containing a cryptographic call that cannot be expressed by any scope in the intent vocabulary, requiring source changes when the algorithm is replaced.

read the original abstract

As organizations move toward post-quantum cryptography, they face the major challenge of updating cryptographic algorithms across large, complex software portfolios. However, most cryptographic APIs in use today were designed around specific algorithms. These APIs expect explicit use of specific algorithms, provide little or no support for policy-based algorithm selection, and offer no straightforward way to migrate existing keys to newer algorithms. This makes the transition to post-quantum cryptography challenging. The companion assessment framework identifies the barriers to cryptographic agility and explains why algorithm transition is largely a software engineering problem. To address the limitations of current cryptographic APIs, we identify the principles necessary to design a cryptographically agile API. The design principles are derived from five fundamental architectural characteristics (Abstraction, Stability, Temporal Flexibility, Separation, and Extensibility). We also show how the design principles can be implemented using several examples of Protocol Buffers API design patterns. In particular, we present an intent vocabulary that is based on scopes which allows for decoupling key creation from algorithm identities. It also supports transparent substitutions of algorithms in the applicable scope. Cryptographic governance is enabled by an abstract policy API that does not prescribe the policy format. Keys are represented by stable identifiers and support key evolution operations (rotation, transformation, migration), facilitating migration between algorithms and providers while tracking both the original key identity and its evolution history. With this approach, updating cryptography becomes an operational process without the need to rewrite application code.

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 / 0 minor

Summary. The paper proposes a set of design principles for cryptographically agile APIs, derived from five architectural characteristics (Abstraction, Stability, Temporal Flexibility, Separation, and Extensibility). It illustrates the principles via Protocol Buffers patterns, an intent vocabulary based on scopes that decouples key creation from algorithm identities, an abstract policy API, and stable key identifiers supporting evolution operations (rotation, transformation, migration). The central claim is that these elements enable transparent algorithm substitution and key migration as operational changes, without requiring application code rewrites, thereby easing transitions such as to post-quantum cryptography.

Significance. If the proposed intent-based decoupling and scope mechanisms can be validated to cover typical cryptographic call sites without forcing application changes, the work would address a recognized software-engineering barrier to cryptographic agility. The emphasis on stable identifiers, policy abstraction, and key evolution provides a coherent forward-looking framework that could inform API standards and migration tooling.

major comments (2)
  1. Abstract: The claim that 'updating cryptography becomes an operational process without the need to rewrite application code' rests on the unverified assumption that the scope-based intent vocabulary covers the full range of real-world usage patterns (e.g., algorithm-specific parameters, protocol negotiation, HSM bindings, performance knobs, legacy key formats). No systematic mapping or coverage argument against actual call sites is supplied, leaving the central decoupling claim unsubstantiated.
  2. Abstract and design sections: The manuscript presents the principles and patterns as a logical design proposal but supplies no implementation, no evaluation against existing APIs (such as PKCS#11, OpenSSL, or cloud KMS interfaces), and no demonstration that the patterns prevent code changes in practice. This absence prevents assessment of whether the five characteristics actually deliver the claimed agility.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive comments, which correctly identify that the manuscript is a design proposal without empirical validation or implementation. We respond point-by-point below and indicate revisions to better scope the claims.

read point-by-point responses

  1. Referee: Abstract: The claim that 'updating cryptography becomes an operational process without the need to rewrite application code' rests on the unverified assumption that the scope-based intent vocabulary covers the full range of real-world usage patterns (e.g., algorithm-specific parameters, protocol negotiation, HSM bindings, performance knobs, legacy key formats). No systematic mapping or coverage argument against actual call sites is supplied, leaving the central decoupling claim unsubstantiated.

    Authors: We agree the claim assumes the vocabulary's coverage and that no systematic mapping of call sites is provided. The design is derived from the five architectural characteristics with illustrative Protocol Buffers examples. In revision we will qualify the abstract claim, add an explicit limitations paragraph on coverage assumptions, and note that empirical mapping against production call sites remains future work. revision: partial

  2. Referee: Abstract and design sections: The manuscript presents the principles and patterns as a logical design proposal but supplies no implementation, no evaluation against existing APIs (such as PKCS#11, OpenSSL, or cloud KMS interfaces), and no demonstration that the patterns prevent code changes in practice. This absence prevents assessment of whether the five characteristics actually deliver the claimed agility.

    Authors: The manuscript is intentionally a design proposal identifying principles and patterns; it contains no implementation or comparative evaluation. This scope is appropriate for the contribution. We will revise the abstract, introduction, and conclusion to state explicitly that the work is conceptual, that practical validation against existing APIs is outside its remit, and that implementation studies are planned future work. revision: partial

Circularity Check

0 steps flagged

No circularity: forward-looking design proposal with no derivations or fitted claims

full rationale

The paper is a design proposal that identifies principles from five architectural characteristics (Abstraction, Stability, Temporal Flexibility, Separation, Extensibility) and illustrates them via Protocol Buffers patterns and an intent vocabulary. No equations, predictions, parameter fits, or self-citations to prior work by the same authors appear as load-bearing steps. The central claim is a prescriptive recommendation rather than a derived result that reduces to its inputs by construction. This matches the default expectation for non-circular papers; the work is self-contained as a proposal without any of the enumerated circular patterns.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 1 invented entities

The proposal rests on standard software-engineering assumptions about API stability and the feasibility of transparent algorithm substitution; no free parameters or invented physical entities appear.

axioms (2)
  • domain assumption Applications can be written against abstract cryptographic intents rather than concrete algorithm choices without loss of required functionality.
    Stated in the description of the intent vocabulary and scope mechanism.
  • domain assumption Stable key identifiers plus evolution history are sufficient to track keys across algorithm migrations.
    Appears in the section on key representation and migration operations.
invented entities (1)
  • Intent vocabulary based on scopes no independent evidence
    purpose: Decouple key creation and operation requests from specific algorithm identities
    New construct introduced to enable transparent substitutions.

pith-pipeline@v0.9.1-grok · 5783 in / 1351 out tokens · 16133 ms · 2026-06-27T06:14:35.088476+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

32 extracted references · 14 canonical work pages

  1. [1]

    Java Cryptography Architecture (JCA) Reference Guide

    Sun Microsystems. Java Cryptography Architecture (JCA) Reference Guide. Sun Microsystems, Inc., 1997. Updated by Oracle Corporation. https://docs.oracle.com/en/java/javase/21/security/java-cryptography- architecture-jca-reference-guide.html

    1997

  2. [2]

    EVP: High-Level Cryptographic Functions

    OpenSSL Software Foundation. EVP: High-Level Cryptographic Functions. OpenSSL 3.x Documentation. https://www.openssl.org/docs/man3.0/man7/evp. html. Accessed 2025

    2025

  3. [3]

    Google Tink Cryptographic Library

    Duong, T., Nguyen, Q. Google Tink Cryptographic Library. Google, 2018. https: //github.com/tink-crypto/tink

    2018

  4. [4]

    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. DOI: 10.17487/RFC7696

    work page doi:10.17487/rfc7696 2015

  5. [5]

    Barker, Recommendation for key management:: part 1 - general, Tech

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

    work page doi:10.6028/nist.sp.800-57pt1r5 2020

  6. [6]

    Module-Lattice-Based Key-Encapsulation Mechanism Standard

    NIST. Module-Lattice-Based Key-Encapsulation Mechanism Standard. FIPS 203, August 13, 2024. DOI: 10.6028/NIST.FIPS.203

    work page doi:10.6028/nist.fips.203 2024

  7. [7]

    Module-Lattice-Based Digital Signature Standard

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

  8. [8]

    Federal Information Pro- cessing Standards Publication 204

    DOI: 10.6028/NIST.FIPS.204. Rameshan and Messmer

    work page doi:10.6028/nist.fips.204

  9. [9]

    Stateless Hash-Based Digital Signature Standard

    NIST. Stateless Hash-Based Digital Signature Standard. FIPS 205, August 13, 2024. DOI: 10.6028/NIST.FIPS.205

    work page doi:10.6028/nist.fips.205 2024

  10. [10]

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

    Green, M., Smith, M. Developers are Not the Enemy!: The Need for Usable Secu- rity APIs.IEEE Security & Privacy, 14(5):40–46, 2016. DOI: 10.1109/MSP.2016.108

    work page doi:10.1109/msp.2016.108 2016

  11. [11]

    PKCS #11 Cryptographic Token Interface Base Specification Version 3.0

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

    2020

  12. [12]

    Key Management Interoperability Protocol Specification Version 2.1

    OASIS. Key Management Interoperability Protocol Specification Version 2.1. OASIS Standard, 2020

    2020

  13. [13]

    eXtensible Access Control Markup Language (XACML) Version 3.0

    OASIS. eXtensible Access Control Markup Language (XACML) Version 3.0. OA- SIS Standard, January 2013

    2013

  14. [14]

    Open Policy Agent: Policy-Based Control for Cloud-Native Environments

    Open Policy Agent Project. Open Policy Agent: Policy-Based Control for Cloud-Native Environments. Cloud Native Computing Foundation. https://www. openpolicyagent.org/

  15. [15]

    Gatekeeper: Policy Controller for Kubernetes

    Open Policy Agent Project. Gatekeeper: Policy Controller for Kubernetes. Cloud Native Computing Foundation. https://github.com/open-policy-agent/ gatekeeper

  16. [16]

    CycloneDX Specification v1.6: Cryptography Bill of Mate- rials (CBOM)

    OWASP Foundation. CycloneDX Specification v1.6: Cryptography Bill of Mate- rials (CBOM). 2024. https://cyclonedx.org/capabilities/cbom/

    2024

  17. [17]

    Lazar, H

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

    work page doi:10.1145/2637166.2637237 2014

  18. [18]

    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. DOI: 10.1109/SP.2017.52

    work page doi:10.1109/sp.2017.52 2017

  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. 2, March 2019. DOI: 10.6028/NIST.SP.800- 131Ar2. (Rev. 3 draft in progress.)

    work page doi:10.6028/nist.sp.800- 2019

  20. [20]

    Migration to Post-Quantum Cryptography

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

    2024

  21. [21]

    Post-Quantum Use in Protocols (PQUIP)

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

    2023

  22. [22]

    eUCRITE 1.0—Towards a Usable Crypto- graphic Interface

    Zeier, A., Wiesmaier, A., Heinemann, A. eUCRITE 1.0—Towards a Usable Crypto- graphic Interface. In:Proc. 15th International Conference on A vailability, Reliability and Security (ARES), pp. 70:1–70:8, 2020. DOI: 10.1145/3407023.3409184

    work page doi:10.1145/3407023.3409184 2020

  23. [23]

    Considerations for Achieving Crypto Agility

    Barker, E., et al. Considerations for Achieving Crypto Agility. NIST Interagency Report (IR), 2025

    2025

  24. [24]

    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. In:Proc. ACM CCS Workshop on Software Supply Chain Offensive Research and Ecosystem Defenses (SCORED), 2024

    2024

  25. [25]

    High-Level Cryptographic Abstractions

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

    work page doi:10.1145/3338504.3357340 2019

  26. [26]

    CARAF: Crypto Agility Risk Assess- ment Framework.Journal of Cybersecurity, 7(1):tyab013, 2021

    Ma, C., Colon, L., Dera, J., Rashidi, B., Garg, V. CARAF: Crypto Agility Risk Assess- ment Framework.Journal of Cybersecurity, 7(1):tyab013, 2021. DOI: 10.1093/cyb- sec/tyab013

    work page doi:10.1093/cyb- 2021

  27. [27]

    Toward a Common Understanding of Cryptographic Agility—A Systematic Review.ACM Computing Surveys, 2025

    Näther, C., Herzinger, D., Steghöfer, J.-P., Gazdag, S.-L., Hirsch, E., Loebenberger, D. Toward a Common Understanding of Cryptographic Agility—A Systematic Review.ACM Computing Surveys, 2025. (To appear.)

    2025

  28. [28]

    HopSkipJumpAttack: A Query-Efficient Decision-Based Attack,

    Protzenko, J., Parno, B., Fromherz, A., Hawblitzel, C., Polubelova, M., Bhar- gavan, K., Beurdouche, B., Zinzindohoue, J., Ramananandro, T., Wang, 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. DOI: 10.1109/SP40000.2020.00114

    work page doi:10.1109/sp40000.2020.00114 2020

  29. [29]

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

    Sikeridis, D., Kampanakis, P., Devetsikiotis, M. ELCA: Introducing Enterprise- Level Cryptographic Agility for a Post-Quantum Era. In:Proc. USENIX Security Symposium Poster Session, 2023

    2023

  30. [30]

    Building Cryptographic Agility in the Financial Sector

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

    2024

  31. [31]

    Towards a Maturity Model for Crypto- Agility Assessment

    Hohm, J., Heinemann, A., Wiesmaier, A. Towards a Maturity Model for Crypto- Agility Assessment. In:Proc. Foundations and Practice of Security (FPS). Springer LNCS, pp. 104–119, 2023. DOI: 10.1007/978-3-031-57540-2_8

    work page doi:10.1007/978-3-031-57540-2_8 2023

  32. [32]

    A Component-Based Assessment Framework for Application-Level Cryptographic Agility

    Rameshan, N., Messmer, G. A Component-Based Assessment Framework for Application-Level Cryptographic Agility. IBM Research Europe, 2026. [Compan- ion paper.]

    2026