Why I built a cloud that can't read your files

I built Hoodik because I wanted somewhere to keep my files that nobody could force open. Not a hosting company, not a government, not even me. Here is why that matters more every year, and then, for anyone who wants it, how the encryption actually works.

Why

Most cloud storage asks you to trust a company. They promise not to look at your files, and most of them mean it. But a promise only holds until someone with more power tells them otherwise. A court order, a new law, sometimes just a quiet request. If a company is able to read your files, then sooner or later someone can make them.

I didn't want to make that kind of promise, because I didn't want to be able to break it. Hoodik is built so that I can't read your files even if I wanted to. Everything is locked on your own device before it ever reaches the server. What arrives at the server is a sealed box, and the server never gets the key. If someone takes over my server, buys the project, or turns up with a warrant, all they get is the same sealed box a stranger would get. There is nothing useful they can do with it.

This isn't paranoia. Look at what has been happening in Europe. For years now, under the name "Chat Control," lawmakers have kept trying to require services to scan people's private messages and files, before they are encrypted, in the name of catching criminals. It gets rejected and it comes back under a new name. And it isn't only Europe. Every so often, somewhere, a government decides it wants a way into everyone's private data, and the big providers go along with it, because they can and because they are told to.

The trick is to make sure there is nothing readable to hand over, no matter who is holding it. That part never changes. Whoever runs the server only ever holds sealed boxes, and the key that opens them never leaves your device. Run it yourself on a cheap box at home and there is no company in the middle at all. Prefer to have someone host it for you? Even then it is still sealed boxes, because a host never gets your key either. Either way there is no readable data to seize and no key to demand, because nobody in the chain ever had it. That is what I mean when I call it essentially ungovernable. Not lawless, just built so there is nothing anyone can be forced to reveal.

That is the why. The rest is the how, for people who like that sort of thing.

How it works

Hoodik's key exchange is now post-quantum. Every file key is wrapped with a hybrid of X25519 and ML-KEM-768, and login moved to OPAQUE, which means your password never leaves your device at all. Existing accounts upgrade automatically on their next login. Here is what changed, what it actually protects against, and why I did it now instead of waiting.

The threat is called "harvest now, decrypt later"

There is no quantum computer today that can break RSA or elliptic curve cryptography. That's not the problem.

The problem is that encrypted data has a lifetime. An attacker who records your ciphertext today doesn't need to decrypt it today. They can store it and wait. If a sufficiently large quantum computer exists in 10 or 15 years, everything they recorded becomes readable retroactively, because Shor's algorithm breaks the classical asymmetric cryptography that protected the keys.

For a chat message about lunch, who cares. For medical records, tax documents, contracts, private photos, and anything else people actually put in encrypted storage, a 15-year decryption delay is not much comfort. If your files should still be private in 2040, the key exchange protecting them needs to survive until 2040.

That's the threat post-quantum cryptography addresses. Not a quantum computer existing today, but ciphertext captured today being decrypted by one later.

What actually breaks, and what doesn't

Quantum computers don't break all cryptography equally.

Asymmetric key exchange breaks badly. Shor's algorithm solves the math problems underneath RSA and elliptic curves (like X25519) efficiently on a quantum computer. This is the part that needs replacing.

Symmetric ciphers hold up well. Grover's algorithm halves the effective key length, and that's the extent of the known damage. AEGIS-128L, which encrypts your actual file content in Hoodik, is not the weak link. The weak link is the asymmetric wrap around the file key: crack that, and you get the symmetric key for free.

So the fix targets exactly one spot: the key wrapping. File content encryption stays AEGIS-128L, same as before (and if you want a 256-bit symmetric margin, AEGIS-256 is supported as an optional cipher).

ML-KEM-768, and why I pair it with X25519

ML-KEM is the key encapsulation mechanism NIST standardized in 2024 (FIPS 203), based on the CRYSTALS-Kyber design that won the NIST post-quantum competition. It's built on lattice problems, which have no known efficient quantum attack. ML-KEM-768 is the middle parameter set, the one most of the industry has converged on for TLS and messaging.

Hoodik doesn't use it alone, though. Every file key is wrapped with a hybrid: X25519 and ML-KEM-768 together, and an attacker has to break both to recover the key.

The reasoning is straightforward. X25519 has two decades of cryptanalysis behind it and is only threatened by quantum computers that don't exist yet. ML-KEM is quantum-resistant but young by cryptographic standards. Pairing them means a future quantum computer doesn't help (ML-KEM holds), and an unexpected flaw in the newer lattice math doesn't help either (X25519 holds). This is the same construction Signal, Chrome, and Apple use for their post-quantum rollouts. Nobody serious ships post-quantum crypto unhybridized today, and neither do I.

Your password never leaves your device anymore

The same upgrade replaced password login with OPAQUE, a PAKE (password-authenticated key exchange). The short version: the server verifies you know your password without ever receiving it. Not even in hashed form, not even during registration. It never arrives.

That closes a class of problems that has nothing to do with quantum computers. A password the server never sees can't end up in a request log by accident, and it can't leak in a server breach. There is nothing to leak. Combined with the existing model where your private key only ever exists on the server as an encrypted blob, the server ends up knowing remarkably little about you: no plaintext files, no file names, no search terms, and now no password.

Account identity signing also moved to Ed25519, the modern standard for signatures, used for things like the tamper-evident share activity log.

What you have to do

Nothing. Legacy accounts using the previous RSA-2048 scheme are upgraded automatically the next time they log in: the client generates the new keys and re-wraps what needs re-wrapping. Old files keep decrypting, because Hoodik stores the cipher used for each file and never breaks old data to adopt new defaults.

That's the pattern I care about. Cryptography ages, and a storage system you trust for decades has to be able to move to better primitives without asking you to re-upload your life. This upgrade is the proof that the machinery for that works.