tgcryptfs · Encrypted Cloud Storage · Proof of Concept

YOUR KEYS. YOUR FILES. THEIR INFRA, BLIND.

Encrypted FUSE filesystem backed by Telegram cloud storage. Files leave your machine already opaque. Keys never leave your device. What Telegram holds is meaningless to anyone who asks.

TGCRYPTFS · VOLUME: research-notes · MOUNTED
$ tgcryptfs volume mount research-notes ~/secure
authenticating with Telegram…
✓ authenticated
deriving root key (Argon2id)…
✓ key derived · MFA: TOTP verified
mounting FUSE volume…
✓ mounted at ~/secure
deadman: armed · window: 24h
✓ volume accessible · post-quantum: ML-KEM-768
─────────────────────────────────
$ ls ~/secure/
api-keys.enc designs/ research/ credentials/
(all files transparent · encrypted at rest)
research-notes ● mounted ML-KEM-768 deadman ✓

tgcryptfs is a proof of concept and an additional layer of control not a replacement for iCloud, Dropbox, or whatever you already use. Think of it as a supplement: a second channel for data you want truly encrypted, controlled by you alone, stored somewhere no one expects to find it. Keep your backups. Keep your sync. Add tgcryptfs for the data that matters.

The subversion

Telegram stores
your files.
It has no idea what they are.

Telegram is a cloud storage provider with billions of users, persistent free storage, and infrastructure in jurisdictions around the world. tgcryptfs uses it as a dumb block store uploading content-defined, encrypted chunks that look like random noise to anyone inspecting them.

The metadata database has BLAKE3-hashed table names, column names, and index names so even the schema reveals nothing. Telegram's engineers could look directly at the data in your account and learn nothing about your files.

This isn't a clever trick it's the result of encrypting everything, cryptographically opaquing everything, before it leaves your device. The cloud just holds blocks. You hold the meaning.

The subversion, simply
your machine
encrypt(file) → opaque_block
XChaCha20-Poly1305 AEAD
key never leaves device
↓ upload to Telegram
telegram servers
sees: binary blob #29f3a…
knows: nothing
↓ download + decrypt
your machine again
✓ your file, intact, readable
Transparent operation
FUSE Layer

Mount it. Use it like
any other directory.

tgcryptfs mounts as a standard FUSE filesystem. Your applications don't know there's encryption happening. Your text editor, your code, your scripts they read and write files normally.

Encryption happens transparently on write. Decryption happens transparently on read. The FUSE layer intercepts the filesystem calls, applies crypto, and syncs with Telegram. You see files. Telegram sees blocks.

  • Works with any application no modification needed
  • Files appear as normal in your filesystem
  • Encrypted block cache for performance
  • Linux and macOS (FUSE required)
FILESYSTEM VIEW
$ df -h ~/secure
Filesystem: tgcryptfs
Mounted: ~/secure
──────────────────────
$ ls -la ~/secure/
drwxr-xr-x designs/
drwxr-xr-x research/
-rw-r--r-- api-keys.txt
-rw-r--r-- credentials.json
──────────────────────
$ cat ~/secure/api-keys.txt
OPENAI_KEY=sk-proj-…
ANTHROPIC_KEY=sk-ant-…
# files are just files to you
# to telegram: opaque blobs
Multi-machine

Sync across your machines,
share with colleagues and friends.

Because the storage backend is Telegram, any machine you authenticate on can access the same volumes. Your laptop, your desktop, your remote server mount the same volume, work seamlessly.

Share volumes with colleagues using ML-KEM-768 key exchange. Grant read-only or read-write access. Issue time-limited invite links that expire. Revoke access without re-encrypting. Forward secrecy via epoch-based key rotation means past access doesn't unlock future data.

  • Mount same volume on any authorized device
  • Share with post-quantum ML-KEM-768 key exchange
  • Time-limited, revocable invite links
  • Forward secrecy epoch rotation destroys old keys
SHARING
$ tgcryptfs sharing invite research-notes
--access read-write
--expires 7d
✓ invite link generated
ML-KEM-768 key exchange
link: tgfs://inv/7f4a8b…
(single-use · expires 2026-06-05)
──────────────────────────────
$ tgcryptfs sharing list research-notes
alice@example.com rw active
bob@example.com ro active
[revoke with: sharing revoke]
The protection you hope you never need

The dead man's
switch.
Your data, protected
even from you.

If you stop checking in heartbeat missing, network unreachable, conditions you define the dead man's switch destroys your encryption keys. Not the data. The keys. Your data becomes permanently inaccessible.

This matters in coercion scenarios. If someone forces you to "unlock" your storage, the keys no longer exist. There is nothing to hand over. The data is meaningless forever.

A hash-chained audit log records every trigger event. A grace period gives you time to disarm if you simply missed a check-in. Configure the conditions yourself time-based, network-based, or custom signals.

DEADMAN MONITOR
$ tgcryptfs deadman status
volume: research-notes
status: ARMED · nominal
window: 24h
grace: 2h
last checkin: 3h ago
⚡ checkin overdue · grace period
─────────────────────────────
$ tgcryptfs deadman checkin
✓ checked in · clock reset
next required: in 24h
─────────────────────────────
[if checkin missed: keys destroyed]
[data: permanently inaccessible]
Cryptographic architecture

Post-quantum from
the key hierarchy down.

Key Hierarchy

Argon2id(password, salt) → root_key
memory: 256MB · iterations: 4
↓ HKDF-SHA256 derivation
data_key → XChaCha20-Poly1305
meta_key → XChaCha20-Poly1305
schema_key → BLAKE3 table/column names
integrity → BLAKE3 content addressing
wrapping → ML-KEM-768 key exchange
deadman → destruction trigger
─────────────────────────────
all keys: zeroize on drop

MFA Vault Options

PASSWORD + TOTP
Standard MFA. Password + time-based one-time password from any authenticator app.
HARDWARE BINDING
Bind keys to a specific device's hardware serial. Volume is non-transferable without re-provisioning.
SECURE ENCLAVE / TPM2
macOS Touch ID / Secure Enclave or TPM2 for biometric-backed key protection.
22-WORD RECOVERY
Deterministic 22-word sentence encoding for root key backup. Write it down. Store it somewhere safe. That's your parachute.

What tgcryptfs protects against and what it doesn't

Protected against ✓
Telegram employees or government requests to Telegram
Physical device capture (volume unmounted, password required)
Network interception of uploaded data
KDF parameter downgrade attacks
Brute-force with Argon2id memory hardness
Coerced disclosure (dead man's switch)
Future quantum computers (ML-KEM-768)
Not protected against ✗
Compromised OS kernel
Adversary with access while volume is mounted
Powered-on machine with volume mounted and screen unlocked
Malware with keylogging access at time of unlock
tgcryptfs protects data at rest and in transit. If your machine is compromised while the volume is open, you have bigger problems than storage encryption.
Who uses tgcryptfs

An extra layer for data
that demands control.

Journalists & Researchers

Store source contacts, unpublished research, and sensitive documents somewhere that looks like your personal Telegram account. Plausible deniability via opaque blobs.

Security Professionals

Credentials, private keys, pentest notes, client data. Everything encrypted before it touches any network. Dead man's switch in case your equipment is seized.

Distributed Teams

Share encrypted volumes without shared infrastructure. No self-hosted server, no shared S3 bucket. Everyone has their own keys. Sharing is explicit and revocable.

YOUR DATA. YOUR TERMS.

Written in Rust. A proof of concept that asks: what if your cloud had no idea what it was storing? tgcryptfs answers that question.

Press Release Also See ARF →