Intent-Based Cryptographic API Design for Cryptographic Agility
This paper proposes an intent-based cryptographic API design framework that decouples key creation from specific algorithms through abstract policies and stable identifiers, thereby enabling seamless cryptographic agility and post-quantum migration without requiring application code rewrites.
Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
Imagine your organization's software is a massive, bustling city. In this city, cryptography (the art of locking and unlocking secrets) is the security system. For decades, the city's security guards (the software APIs) were hired with a very specific instruction: "You are a SHA-1 guard. Only you can open these specific locks."
Now, a new threat has arrived: Quantum Computers. These are like super-powered thieves that can pick any old lock in seconds. The city needs to switch to new, unbreakable locks (Post-Quantum algorithms).
The Problem:
In the current city, if you want to change the lock type, you have to fire every single guard, retrain them, rewrite their job descriptions, and rebuild every single door in the city. If you have 10,000 buildings, that's a nightmare. You have to find every line of code that says "Use SHA-1" and change it to "Use ML-DSA." This is slow, expensive, and prone to errors.
The Solution: The "Intent-Based" City
This paper proposes a new way to design the city's security system. Instead of hiring guards for specific locks, you hire them based on Intent.
Here is how the new system works, using simple analogies:
1. The "Order Form" vs. The "Menu"
- Old Way (The Menu): When you order a meal, you must say, "I want the Spicy Tuna Roll." If the kitchen runs out of tuna, you can't eat. You have to go back and change your order to "Salmon Roll." In software, this means the code explicitly says "Use Algorithm X."
- New Way (The Intent): You tell the kitchen, "I want a Spicy Roll." You don't care if it's tuna, salmon, or tofu, as long as it's spicy and a roll.
- The Paper's Term: Scope.
- How it works: The application says, "I need a digital signature that includes a 'context' (like a specific location)." It doesn't say "Use Ed25519" or "Use ML-DSA." It just says, "Give me a signature with a context." The system figures out which algorithm fits that description.
2. The "Universal Adapter" (Scopes)
You might think, "But what if the new lock needs a different shape of key?"
The paper introduces Scopes. Think of a Scope as a universal adapter plate on the wall.
- Some locks (algorithms) need a key with a flat head.
- Some need a key with a round head.
- The Scope ensures that all locks in that group accept the same key shape.
- The Magic: If the security team decides to swap the "Flat Head" lock for a "Quantum-Proof Flat Head" lock, the door doesn't need to be changed. The key shape (the input the app sends) stays exactly the same. The system just swaps the internal lock mechanism behind the scenes.
3. The "Rule Book" (Policy)
In the old city, the guard decided which lock to use. In the new city, a Policy Engine (a strict rule book) decides.
- The Analogy: Imagine a central security chief who holds the master list. The chief says, "For all 'Spicy Rolls' in the 'Finance District,' we are now using Tofu."
- The Paper's Claim: The application code doesn't need to know this. The application just asks for a "Spicy Roll." The Policy Engine checks the rules, picks the Tofu (the new algorithm), and hands it to the guard. If the rules change tomorrow to "Use Seaweed," the Policy Engine updates, and the next order gets Seaweed. The application code never changes.
4. The "Identity Card" (Key Abstraction)
This is crucial for moving between different security companies (Providers).
- Old Way: Your key is stamped with "Made by Company A, Model X." If you move to Company B, you have to throw away the key and get a new one.
- New Way: Your key has a Stable ID (like a Social Security Number). It doesn't matter if the key is made of steel, plastic, or quantum-foam. It is still "Key #12345."
- The Paper's Claim: The system allows you to Transform the key. You can take "Key #12345" (currently made of old steel) and magically turn it into "Key #12345" (made of new quantum-foam). The ID stays the same. The application still uses "Key #12345." No one notices the change.
5. The "Three-Step Upgrade" (Key Evolution)
The paper outlines three specific ways to upgrade the city without tearing it down:
- Rotation: Changing the key material (like changing the batteries in a remote) but keeping the same lock type.
- Transformation: Changing the lock type itself (e.g., from a mechanical lock to a digital one) but keeping the same ID. The application keeps using the same ID.
- Migration: Moving the key from one security company to another (e.g., from a local server to a cloud vault) without changing the ID.
The Result: A Seamless Transition
The paper demonstrates a "Post-Quantum Migration" scenario:
- Day 1: The app uses a key for "Context-Based Signing." The system picks an old algorithm (Ed25519).
- Day 2: The security team updates the Policy to say, "From now on, use the new Quantum-Proof algorithm (ML-DSA) for this scope."
- Day 3: An administrator runs a command to Transform the existing keys. The old keys are upgraded to the new algorithm.
- The Result: The application code? It didn't change a single line. It still just says "Sign this with Key #12345." The system handled the heavy lifting.
Summary
This paper argues that to survive the future (Quantum computing), we need to stop building software that is "hard-coded" to specific security locks. Instead, we should build software that asks for what it needs to do (Intent), and let a central Policy decide how to do it.
This turns a massive, expensive software engineering project (rewriting millions of lines of code) into a simple administrative task (updating a policy file and running a transformation command). It's the difference between rebuilding a city's roads every time a new car model comes out, versus just updating the traffic lights to handle the new cars.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.