Cryptographic Agility Here's my take on cryptographic agility intended for application developers. -------------------------------------------------------------------------------- Cryptographic Agility ===================== 8 min read /[cendyne: anime-glasses]------------------------------------------------------\ | To start, let's review a definition of what cryptographic agility means or | | requires. | \------------------------------------------------------------------------------/ > Wikipedia > > A security system is considered crypto agile if its cryptographic algorithms > or parameters can be replaced with ease and is at least partly automated. > - Cryptographic agility [L1] /[cendyne: laptop-thinking]----------------------------------------------------\ | I believe there is a gradient of cryptographic agility: | | | | * You have no idea what crypto is in your system; | | * You have an idea of what crypto is in place but any changes require | | significant effort; | | * You have complete track of your crypto and you have reliable transition | | plans should any changes be required; | | * And any changes to your crypto can be managed with configuration to | | initiate and complete transitions between cryptographic algorithms. | | | | The inability to adjust your cryptography would be the opposite of agile. | \------------------------------------------------------------------------------/ /----------------------------------------------------------------[kyrmeso: wut]\ | What are the experts saying about crypto agility? | \------------------------------------------------------------------------------/ /[cendyne: music]--------------------------------------------------------------\ | Take a listen to Cryptographic Agility: Anticipating, Preparing for and | | Executing Change [L2] from RSA Conference 2020. From this I learned | | Microsoft found 50 distinct implementations of MD5 in the windows code base. | | Quite a few interesting recounts are described in this panel. | \------------------------------------------------------------------------------/ /------------------------------------------------------------------------------\ | RSA Conference | |------------------------------------------------------------------------------| | Youtube Video [L3] | | Cryptographic Agility: Anticipating, Preparing for and Executing Change [L2] | | 1/9/2023 | \------------------------------------------------------------------------------/ /---------------------------------------------------------------[kyrmeso: blep]\ | What do you have to say about crypto agility? | \------------------------------------------------------------------------------/ /[cendyne: public-speaking]----------------------------------------------------\ | I am only going to talk about what I have actually done. My recommendations | | come from my professional experience as a developer and now manager. None of | | this is armchair cryptography. | \------------------------------------------------------------------------------/ /[cendyne: proud]--------------------------------------------------------------\ | The application I am responsible for has ascended from crypto-ignorance to | | crypto-aware with interface points ready for any cryptographic migrations. | | Appropriate and correctly applied modern cryptography is deployed to | | production and I expect that no changes will be needed for a few years. | \------------------------------------------------------------------------------/ /[cendyne: i-dunno-man-im-just-a]----------------------------------------------\ | That said, I have not gotten application level cryptography to the point | | where migrations may be done through configuration. Unlike X.509, | | application cryptography has a wide set of use cases and solutions. I | | believe most changes require active human intervention to safely alter and | | to provide high availability of service during and after the change. | \------------------------------------------------------------------------------/ /-----------------------------------------------------------[kyrmeso: ych-boop]\ | What do I need to do to get as far as you have? | \------------------------------------------------------------------------------/ /[cendyne: i-am-looking]-------------------------------------------------------\ | The first step to being agile is to take an inventory of what you are using, | | for what purpose, and where. When you look, you might find out that the | | wrong technology is being applied in your code. For example, using RSA | | encryption for small messages that are encrypted and decrypted on the same | | server. A symmetric algorithm is more appropriate. | \------------------------------------------------------------------------------/ /[cendyne: the-more-you-know]--------------------------------------------------\ | The second step is to stay informed of what's going on in the field. Watch | | for updates to the tools available in your language of choice. Listen and | | watch for deprecated or broken algorithms just as you would with security | | vulnerabilities and see if you are using any of them. For example, JDK 16 | | added SHA3-256 support [L4] and JDK 18 disabled SHA-1 signed jars [L5]. | \------------------------------------------------------------------------------/ /[cendyne: press-f-to-pay-respects]--------------------------------------------\ | Oh and move away from the old dangerous stuff too! MD5 should not be touched | | with a 10 foot pole and SHA-1 is broken [L6]. Also Bleichenbacher's attack | | [L7] keeps coming back from the dead so stop using RSA. | \------------------------------------------------------------------------------/ /[cendyne: no-bad]-------------------------------------------------------------\ | Resist the urge to apply new algorithms for the sake of being new. You have | | limited resources and time. Focus on replacing what is broken and the | | threats you face. These migrations will consume you and your team's time and | | come with significant risk if done wrong. | \------------------------------------------------------------------------------/ /---------------------------------------------------------------[kyrmeso: math]\ | If I have to do it multiple times anyway, why don't I find a vendor that | | makes an extensible turnkey solution to handle every case I have? | \------------------------------------------------------------------------------/ /[cendyne: take-that-back]-----------------------------------------------------\ | You're likely falling for the most expensive snake oil out there. (No | | offense to snakes intended!) If you are not assessing what you are using | | cryptography for, then you will certainly fail to integrate a vendor's | | solution correctly. | \------------------------------------------------------------------------------/ /-------------------------------------------------------[kyrmeso: glassy-tears]\ | Okay, okay. I'll do it myself. | | | | I just added integrity checks to my encryption but someone says it looks | | wrong on the internet! | \------------------------------------------------------------------------------/ /------------------------------------------------------------------------------\ | Paul Moore @Paul_Reviews@twitter.com | |------------------------------------------------------------------------------| | Here's the latest #encryption [L8] code from #police [L9] #cyberAlarm [L10] | | It took me 5 seconds to spot the hilarious flaw. Now it's your turn. Welcome | | your thoughts @bascule [L11] @ProfWoodward [L12] @Sc00bzT [L13] | | @grittygrease [L14] @matthew_d_green [L15] @AlecMuffett [L16] @jedisct1 | | [L17] @CiPHPerCoder [L18] | | [I1: Photo included with tweet] | | | | [L19] [L20] 6/18/2022 | \------------------------------------------------------------------------------/ /[cendyne: ych-hug-sad]--------------------------------------------------------\ | Migrations are not easy. Here's some mistakes I see in this example: | | | | * The same function is being used for different versions; | | * It is subject to silent downgrade attacks because the signature can be | | removed; | | * The same key is used for both the old and new version; | | * AES-CBC is risky to implement in newer versions of anything; | | * And the data does not identify and is not bound to which version and | | key it is encrypted with. | \------------------------------------------------------------------------------/ /--------------------------------------------------------[kyrmeso: embarrassed]\ | If I did this over again, how should I approach it? | \------------------------------------------------------------------------------/ /[cendyne: ready]--------------------------------------------------------------\ | Modify your application in such a way that different versions are delivered | | and processed with different code paths and that the keys used are unique | | and not shared. Stop using OpenSSL directly and use a library like libsodium | | [L21] or Google Tink [L22]. Bind the fact that this is another version to | | the encrypted message with authenticated encryption with associated data | | [L23] (AEAD). Plan a timeline for when the old version is no longer accepted | | and add monitoring to find out how often the old and new code paths are | | used. And finally verify that the migration is taking place and that the new | | code path reaches expected levels of use before disabling the old code. For | | specific recommendations, see Cryptographic Agility Questions [L24]. | \------------------------------------------------------------------------------/ /--------------------------------------------------------------[soatok: typing]\ | If you're interested in another take about crypto agility, see: | | Cryptographic Agility and Superior Alternatives [L25]. | \------------------------------------------------------------------------------/ -------------------------------------------------------------------------------- [L1]: https://en.wikipedia.org/wiki/Cryptographic_agility [L2]: https://www.youtube.com/watch?v=8pGJVTekDyM [L3]: https://youtu.be/8pGJVTekDyM [L4]: https://seanjmullan.org/blog/2021/03/18/jdk16 [L5]: https://seanjmullan.org/blog/2022/03/23/jdk18 [L6]: https://shattered.io/ [L7]: https://en.wikipedia.org/wiki/Adaptive_chosen-ciphertext_attack#Practical _attacks [L8]: https://twitter.com/hashtag/encryption [L9]: https://twitter.com/hashtag/police [L10]: https://twitter.com/hashtag/cyberAlarm [L11]: https://twitter.com/bascule [L12]: https://twitter.com/ProfWoodward [L13]: https://twitter.com/Sc00bzT [L14]: https://twitter.com/grittygrease [L15]: https://twitter.com/matthew_d_green [L16]: https://twitter.com/AlecMuffett [L17]: https://twitter.com/jedisct1 [L18]: https://twitter.com/CiPHPerCoder [L19]: https://twitter.com/Paul_Reviews/status/1538114752651710465 [L20]: https://archive.ph/QQsxl [L21]: https://doc.libsodium.org/ [L22]: https://github.com/google/tink [L23]: https://en.wikipedia.org/wiki/Authenticated_encryption [L24]: /topics/crypto-agility-questions.html [L25]: https://soatok.blog/2022/08/20/cryptographic-agility-and-superior- alternatives/ [I1]: https://c.cdyn.dev/J2JHRp3U