this post was submitted on 16 Jun 2026
2 points (100.0% liked)
Cryptography @ Infosec.pub
651 readers
1 users here now
Questions, answers, discussions, and literature on the theory and practice of cryptography
Rules (longer version here)
- Stick to cryptography / infosec
- Be a good netizen - be kind, act in good faith, maintain high quality, don't mislead
- Link directly to original sources
- Don't use us to cheat on challenges or tests!
- Crypto review requests must show the algorithm
- CTF / challenges and puzzles must use modern crypto
- Avoid making duplicate posts
- All use of AI / LLM and their prompts MUST be disclosed in your submissions and comments
##Related resources;
- Reddit cryptography forums 1 & 2; /r/crypto /r/cryptography
- Cryptology ePrint archive
- Discussion site for ePrint papers
- Libera Chat's IRC:s #crypto - (IRC protocol URL)
- Metzdowd cryptography mailing list
- Randombit cryptography mailing list
- StackExchange cryptography community
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
The paper PDF by the IBM researchers: https://arxiv.org/pdf/2606.13445v1
From just the abstract, I'm a bit alarmed that the researchers believe that "cryptographic agility" is reducible to a software engineering problem, rather than a complex function of regulatory (eg PCI-DSS), governmental (eg FIPS), and availability (eg hardware acceleration/support and robust implementations) considerations.
But even before all of those stakeholders get involved, is cryptographic agility still an operational objective? Sure, there's the matter of transitioning to PQ crypto, for scenarios where HNDL is a serious concern over the time horizon of whatever's at stake. But is that perceived as a one-time event, or is the idea that all future upgrades should be abstracted?
I find the latter a bit difficult to credibly believe, as the last major attempt at cryptographic agility was so thoroughly bungled that JWT alg:none has a website to highlight the problem.
Agility is only useful if it's actually moving forward: if instead it's an excuse to stand in place, then it's worse than nothing. Best I can tell, this paper seems to deal with abstraction of specific implementations of cryptographic libraries. So this would be akin to not binding directly to OpenSSL vs BearSSL, but having the ability to swap one out for the other.
In that more narrow sense, a lateral move like that is probably fine to abstract. But I can't see how this would fair well if used to shoehorn newer cryptography into applications that either are firmly dependent or are brittle in other, in-abstractable ways.
The value in cryptographic agility comes entirely from the ability to deprecate insecure algorithms, it does not come from the ability to add new algorithms because we can always do that with a version bump anyway.
Also, on the note of interfaces, KEM constructions can not be swapped in for most generic ECC key exchange functions due to different requirements on message round-trips.
I recognize the term "cryptographic alacrity" to specifically include the deprecation of unsafe cryptography, to distinguish from "agility" that could may or may not deprecate old cryptography, thus allowing for fallback attacks to truly ancient cryptography. So yes, I think we're on the same page as to where the utility lays.