DEV Community

mango_mind
mango_mind

Posted on

From CTF Flags to Building a Python-Based Hybrid Encryption Tool for "Harvest Now, Decrypt Later"

#python #cyber #learning #security

A few months ago, I got really into cryptography. Started with CTF platforms: pwn.college, CryptoHack, picoCTF. At first I was just solving flags and moving on. Then that wasn't enough anymore. I wanted to actually build something with what I was learning.

That's how SecureVault was born.

The Problem That Motivated Me

One idea kept coming up in cryptography discussions:

"Harvest now, decrypt later."

The threat model is pretty straightforward but kind of scary:

Someone can grab your encrypted files today, store them, and wait. Can't break them now? No problem. Wait 10-20 years for quantum computers, then decrypt everything.

Shor's algorithm could eventually break RSA and elliptic-curve crypto. So I started thinking:

What would a practical file encryption tool look like if it tried to prepare for that future today?

What SecureVault Actually Does

SecureVault is a cross-platform file encryption tool that uses a hybrid cryptographic design.

The goal isn't to replace symmetric encryption. It's to protect the key exchange layer against long-term quantum risk while keeping file encryption efficient.

Hybrid Key Protection

SecureVault combines:

  • X25519 (classical elliptic-curve Diffie–Hellman)
  • ML-KEM-768 (a NIST-selected post-quantum key encapsulation mechanism)

The idea is simple:

Even if classical elliptic-curve key exchange is broken in the future, the post-quantum layer still protects the file key.

And vice versa.

How File Encryption Actually Works

One important clarification:

SecureVault does NOT encrypt files directly with post-quantum algorithms.

Here's what actually happens:

  1. A random symmetric file key is generated using Fernet.generate_key().
  2. The file contents are encrypted using Fernet (AES-128-CBC + HMAC-SHA256).
  3. That file key is then protected twice:
    • Once using a shared secret derived from X25519
    • Once using a shared secret derived from ML-KEM-768
  4. Each shared secret is used with AES-GCM to wrap the file key.

During decryption:

  • Both unwrap operations must produce the same file key
  • If they do not match, decryption fails

This prevents silent downgrade or tampering of the hybrid protection.

Envelope Signing and Fail-Closed Design

Another important design decision:

SecureVault signs the entire encrypted package, not just the ciphertext.

The envelope includes:

  • encrypted file data
  • wrapped keys
  • nonces
  • ephemeral public keys
  • metadata
  • format version
  • tool version

All of that is canonicalized and signed using:

  • Ed25519 (classical signature)
  • ML-DSA-65 (post-quantum signature via liboqs)

During decryption:

  • Both signatures must verify
  • If either fails, decryption stops immediately

This creates a fail-closed system.

If anything is modified (metadata, ciphertext, or wrapped keys), verification fails before decryption happens.

No silent corruption.
No partial decryption.

Versioning and Forward Safety

Vault files include:

  • format_version
  • tool_version

Before decryption begins, SecureVault checks whether the format version is supported.

If it isn't, it refuses to proceed.

This allows future upgrades without unsafe parsing behavior.

Key Management Decisions

Private key files are:

  • Serialized as JSON
  • Base64-encoded
  • Optionally encrypted with a password

When password-protected:

  • A 16-byte salt is generated
  • PBKDF2-HMAC-SHA256 (100,000 iterations) derives a key
  • The key file is encrypted using Fernet

Public key files are stored separately and are not password protected.

This separation reduces accidental key exposure risk.

Why Hybrid Instead of Choosing One System?

One thing I learned quickly:

Cryptography is about assumptions. No system is future-proof. Every design relies on hardness assumptions remaining valid.

Hybrid designs try to reduce risk.

Instead of betting everything on one cryptographic assumption, the idea is:

An attacker would need to break both independent systems to compromise the protected file key (I like to say defense in depth²).

That mindset strongly influenced this project.

Challenges I Faced

This was significantly harder than I expected.

Some of the biggest challenges:

Integrating Post-Quantum Libraries

Working with liboqs involved:

  • Platform-specific builds
  • Shared library issues
  • Version mismatches
  • Packaging challenges

Getting it to work consistently across Windows, macOS, and Linux was extremely difficult and required me to debug and test every time.

Making Different Crypto Libraries Work Together

Classical and post-quantum crypto libraries have very different interfaces.

Bridging:

  • raw byte formats
  • encapsulation outputs
  • signature verification flows

while keeping the architecture coherent took careful thought.

Designing Explicit Failure Paths

One key lesson:

Silent crypto failures are dangerous.

SecureVault explicitly:

  • Fails if signatures don't verify
  • Fails if hybrid unwrap keys don't match
  • Fails if format version is unsupported
  • Surfaces clear error messages

That behavior was intentional.

What I Learned

This project taught me that cryptography isn't just about algorithms.

It's about:

  • Key management
  • Failure behavior
  • Metadata integrity
  • Versioning
  • Packaging realities
  • Threat modeling

Even small architectural decisions change the security posture.

Community Feedback

After sharing the project, I received thoughtful feedback.

Some pointed out similarities to HPKE standards. Others highlighted cases in which simpler symmetric-only designs might be appropriate.

These discussions helped me better understand how standards-based constructions compare to custom hybrid designs.

I've started reading more about HPKE and their draft documentation, and I'll explore how SecureVault could better align with those standards.

Why I'm Sharing This

I'm still learning. This isn't meant to be a production-grade replacement for established tools.

It's an implementation exercise grounded in real cryptographic concepts.

My goal is to:

  • Apply theory in practice
  • Learn from community feedback
  • Document the journey
  • Improve over time

Try It Yourself

CLI version:
SecureVault CLI showing key generation and encryption
SecureVault CLI Demo

to try it yourself go to the Project page:
https://pypi.org/project/securevault-pqc/

GUI version
SecureVault GUI Loading Page
SecureVault GUI

GUI download page:
https://meganealexis.net/securevault

Final Thoughts

Cryptography is fascinating and very humbling. Just when you think you get it, there's another layer. That's part of why it's so interesting.

If you're learning crypto and wondering if you're ready to build something: you probably are. Just start small and be ready for feedback.

Top comments (0)