Augment Research Foundry Asks:
What If Your Cloud Had No Idea What It Was Storing?

SAN FRANCISCO, CA Augment Research Foundry today released tgcryptfs, an encrypted FUSE filesystem backed by Telegram cloud storage. The project is explicitly framed as a proof of concept and a supplemental layer not a replacement for cloud storage providers but its central demonstration is both technically sound and philosophically pointed: it is possible to use a major cloud infrastructure provider as a storage medium while ensuring, cryptographically, that the provider has no ability to read, identify, or act on any stored data.

Telegram did not participate in the development of tgcryptfs. Telegram did not need to.

The Question This Project Answers

The standard model of cloud storage assumes a bilateral relationship: you store data, the provider holds it, and the provider's terms of service and technical controls determine what happens to that data. The provider can read it. Governments can subpoena it. Breaches expose it. The provider's business model may involve indexing it. You've accepted these terms by uploading.

tgcryptfs inverts this relationship. Files are encrypted on the user's device before they leave. The ciphertext is uploaded to Telegram's infrastructure as message attachments Telegram sees a sequence of encrypted blobs. Telegram cannot decrypt them. Telegram's servers cannot read the filenames, the file sizes (they're padded), the access patterns (they're obfuscated), or any metadata beyond "an attachment was stored." The cloud is just a highly available, globally distributed bucket that happens to have excellent uptime and a generous free tier.

"We asked ourselves the simplest possible question," said the Augment Research Foundry. "What if the storage provider genuinely couldn't read your files? Not because they promised not to, but because they literally couldn't. We built the answer."

What tgcryptfs Is (And Isn't)

tgcryptfs is a proof of concept. It is not a production-ready replacement for iCloud, Dropbox, Google Drive, or any other cloud storage service. Those services provide features real-time sync, collaborative editing, mobile clients, bandwidth optimization that tgcryptfs does not and is not designed to replicate.

tgcryptfs is designed for data you want truly controlled. Sensitive documents. Cryptographic keys. Configurations that should never be in any provider's hands. Research data subject to regulatory restrictions. It is a supplemental layer, mounted alongside your normal cloud storage, for the specific subset of data where you want mathematical guarantees rather than contractual ones.

It is also, frankly, a demonstration of a principle: that modern cryptographic primitives are strong enough that you don't need to trust the infrastructure. You can use untrusted infrastructure. You can use Telegram. The key management is yours. The data is yours.

The Cryptography

tgcryptfs uses ML-KEM-768 (Module Learning With Errors, NIST post-quantum standard, formerly CRYSTALS-Kyber) for key encapsulation. This makes the stored data resistant to cryptanalytic attacks from quantum computers an adversary who harvests today's ciphertext and waits for a quantum computer powerful enough to attack RSA or ECDH will not be able to decrypt tgcryptfs-protected data.

File content is encrypted with a per-file symmetric key derived using the ML-KEM-768 shared secret combined with BLAKE3. The Telegram message attachment contains only ciphertext no filename, no size, no content type. Filenames and metadata are stored in an encrypted index, also stored on Telegram, that is itself encrypted and only decryptable by the key holder.

The 22-word sentence key backup system provides human-memorable key recovery: the master key can be encoded as a grammatically valid English sentence from a curated wordlist, printed on paper, and stored offline. No hardware security module required for backup. No seed phrase that looks like a seed phrase the backup is a sentence.

Forward Secrecy and the Dead Man's Switch

tgcryptfs implements per-session forward secrecy: each mount session generates a new ephemeral keypair. Even if the master key is later compromised, sessions that have already been sealed cannot be decrypted with the compromised key. Past reads are safe.

The dead man's switch is a configurable feature for high-security deployments. If the filesystem is not accessed within a configurable window from hours to days the local key material is wiped. The ciphertext remains on Telegram. Without the key, neither Telegram nor an adversary with physical access to the device can access the data. Re-mounting requires the 22-word backup sentence or a multi-user quorum.

Multi-user sharing is supported through public-key-based access grants: the filesystem owner can grant read or read/write access to other users by encrypting the file key to their public key and storing the encrypted grant in the index. Revoking access requires a key rotation the index is re-encrypted and new file keys are issued for forward-secrecy compliance.

"The argument that you should trust cloud providers with your sensitive data because they have good security practices is an argument about their intentions, not their capabilities. We wanted to build something where intentions are irrelevant. The math doesn't care what Telegram intends."
- Augment Research Foundry

Transparent FUSE Mounting

From the user's perspective, tgcryptfs is a mounted directory. Files appear and behave normally. Read a file it's decrypted transparently. Write a file it's encrypted transparently and uploaded to Telegram. The FUSE layer handles all encryption and decryption in the user process; the operating system sees a normal filesystem. Any application that reads and writes files can use tgcryptfs-backed storage without modification.

Supported platforms are macOS (via macFUSE) and Linux (via libfuse). Windows support via WinFsp is planned for a future release. The implementation is written in Rust.

An Honest Assessment

tgcryptfs relies on Telegram's infrastructure for availability. If Telegram is down, your files are inaccessible. If Telegram changes its API in a breaking way, tgcryptfs needs to be updated. If Telegram's storage limits change, your capacity changes. These are real dependencies on a third party, and users should understand them.

tgcryptfs also operates outside Telegram's terms of service in the sense that it uses the platform in a way not intended or sanctioned by Telegram. Users deploy it at their own discretion. The Foundry takes no position on the terms of service question; the technical question of whether the cryptography holds is what was worth answering.

The answer is yes. The cryptography holds. Telegram or anyone who obtained Telegram's data cannot read your files. That is the proof this project provides.

Built in Rust.

tgcryptfs is written in Rust. All cryptographic primitives are from audited Rust crates: ml-kem for ML-KEM-768, blake3 for hashing and key derivation, chacha20poly1305 for symmetric encryption. The source is available at github.com/arf-io/tgcryptfs.

The Foundry encourages independent security review of the implementation. The cryptography is only as strong as the implementation Rust's memory safety properties reduce but do not eliminate implementation risks. Review is welcome.

Availability

tgcryptfs is available now on GitHub and crates.io. Documentation and setup instructions are at arf.io/tgcryptfs. Pre-built binaries for macOS and Linux are available from the GitHub releases page.

This is what controlled data looks like. The cloud is just a hard drive you don't own and now it can't read your files.