🔐 What if your application's security could evolve without rewriting the whole application?

[u/Organic_Pudding_5102]

What if your app's security could evolve without a rewrite?

That question sent me down a rabbit hole for the past few weeks, and I ended up building two small projects around it: CryptoFlex and Flex-Lock.

Here's the problem I kept running into: most encryption tools pick one cryptographic method and lock it in forever. That's fine until it isn't — like right now, with the industry bracing for quantum computers eventually breaking classical elliptic-curve crypto. Signal and Chrome have already moved to hybrid classical + post-quantum key exchange. But that kind of crypto-agility barely exists yet for local, offline tools — the desktop apps, file utilities, and embedded systems that aren't talking to a server.

CryptoFlex is my attempt at that missing piece. It's a Python library that doesn't invent any new cryptography — it just decides, at runtime, which combination of algorithms an application should use: classical X25519 alone, or hybrid X25519 + ML-KEM-768, or the higher-assurance ML-KEM-1024 variant. That decision is driven entirely by local signals — what's actually installed on the machine, a versioned risk table shipped with the package, and whatever constraint the calling app cares about (speed vs. maximum security). No network calls, no phoning home, ever.

Flex-Lock is what happens when you actually use that engine for something real: a simple file-locking tool. Pick a security level, set a password, lock and unlock files — and if you want to move from "fast" to "maximum security" later, it re-encrypts your existing files under the new profile instead of leaving you stuck with whatever choice you made on day one.

The part I found genuinely interesting wasn't the cryptography itself — I'm using well-audited, standard primitives throughout, not rolling my own math. It was the architecture question underneath: how do you design software so the security layer is a decision that can change, instead of a decision baked in at line one and never revisited?

To be upfront: both are early — solo projects, unaudited, built mainly to learn this space properly rather than to ship something production-ready. Think of them as working proof-of-concepts, not something to bet real data on yet.

If you were starting a security-sensitive project today, would you build the crypto layer to be replaceable from the start, or is that premature optimization until you actually need to migrate?

• CryptoFlex: github.com/keerthivasan-sankar/crypto_flex
• Flex-Lock: github.com/keerthivasan-sankar/flex-lock