ARX RUNA
Encrypted here  ·  Stored anywhere

Arx Runa encrypts files locally before cloud storage. Data is chunked and encrypted client-side using XChaCha20-Poly1305 AEAD; keys remain on the user's device and never leave the local system. Cloud providers receive only opaque ciphertext.

Local-first. Encryption happens entirely on your machine. The cloud never sees plaintext.
Cloud-agnostic. Rclone syncs sealed shards to any provider you choose — S3, Backblaze, Dropbox, your own server.
Zero trust. No accounts, no servers, no third-party key management. Your keys live with you.

Arx Runa is a personal file encryption tool built around one principle: your files should be unreadable to anyone but you — including the cloud service storing them.

When you upload a file, Arx Runa encrypts it on your device before it ever leaves. The cloud receives meaningless scrambled data. When you download, Arx Runa decrypts it locally. At no point does the cloud hold your encryption keys, your filenames, your folder structure, or any other metadata. This is called zero-knowledge storage.

Research Problem

Mainstream cloud storage services (OneDrive, Google Drive, Dropbox) require users to trust the provider with their plaintext files, filenames, and metadata. A compromised or legally compelled provider can expose everything. Arx Runa explores whether it is possible to build a practical alternative where the provider is structurally incapable of reading your data.

Main question: How can a software solution for secure cloud storage be designed and implemented such that client-side encryption eliminates the need for trust in third-party providers, and how can the use of physical hardware factors (MFA) and "Zero-Trace" principles minimise the local attack surface on the user's machine?

This breaks down into five sub-questions:

  1. Encryption standards and key management: Which modern encryption standards and key management principles are best suited for ensuring data confidentiality and integrity when data must be stored in an environment outside the user's control?

  2. USB key file factor and offline recovery: How can a physical USB key file be integrated into the authentication flow as a mandatory second factor — ensuring that password knowledge alone is insufficient to access vault data — and how can an offline BIP-39 recovery mechanism enable user-controlled credential recovery without delegating trust to a third party or introducing a server-side backdoor?

  3. Chunking, synchronisation, and provider-agnostic storage: How can effective chunking and synchronisation logic be implemented to upload changes to the cloud without revealing filenames, directory structures, or metadata to the cloud provider — and how can the synchronisation protocol maintain consistency across multiple devices while remaining provider-agnostic, enabling redundant backup to multiple destinations without re-encryption?

  4. Zero-Trace operation through a RAM-based UI: How can a RAM-based in-application UI achieve Zero-Trace operation — ensuring that decrypted file content is never written to disk during a session — and what forensic residue, if any, persists on the host machine after the vault is locked?

  5. File sharing in a zero-trust system: What cryptographic and protocol-level challenges arise when enabling file-granularity sharing between independent users in a zero-trust client-side encrypted system, and how does the proposed sharing architecture compare to existing approaches such as OneDrive sharing links and Cryptomator shared vaults?

Explore some stuff

What Arx Runa Does

  • Use Cases — Real-world scenarios Arx Runa is designed for

How It Works

  • How It Works — Plain-language walkthroughs: the vault, unlocking, encryption, cloud sync, sharing, and recovery

Going Deeper

  • Deep Dives — Research-level detail on cryptographic choices, file sharing, key recovery, and padding

Reference

Core Pillars

FeatureWhat it means
Client-side encryptionYour files are encrypted on your device before upload — the cloud only ever sees opaque ciphertext blobs
Tiered authenticationTier 1 (password only) or Tier 2 (password + 32-byte USB key file); both are combined before key derivation, so neither factor alone is sufficient
Zero-TraceSensitive data is zeroed from memory as soon as it is no longer needed; session keys are mlock'd so the OS cannot page them to disk; no temporary plaintext files are written
Fixed-size chunks with BLAKE3 integrityFiles are split into equal-sized, padded chunks so the cloud cannot guess sizes; every chunk is BLAKE3-hashed and verified before decryption to catch bit rot or tampering
Secure file sharingShare individual files using HPKE (RFC 9180) with X25519 identities — only the recipient's private key opens the share; the cloud sees only encrypted blobs
Bring Your Own CloudWorks with any provider Rclone supports (S3, Backblaze B2, Dropbox, Google Drive, and 70+ more) — no lock-in, multiple destinations supported

Technology Stack

ComponentTechnologyPurpose
LanguageRust (edition 2024)Memory-safe systems programming
Application frameworkTauriNative desktop shell and Rust backend
UI frameworkLeptos (Rust/WASM, CSR)Reactive frontend compiled to WebAssembly
EncryptionXChaCha20-Poly1305Authenticated encryption for every chunk; 192-bit random nonce per chunk
Key derivationArgon2id → HKDF-SHA256Memory-hard password hardening; then key expansion into independent vault keys
File sharingHPKE (RFC 9180) with X25519End-to-end encrypted share packages; only the recipient's private key can open them
IntegrityBLAKE3Per-chunk checksums recorded in the manifest; verified on download before decryption
Local databaseSQLite + SQLCipherEncrypted manifest: file paths, chunk records, wrapped file keys
Cloud transportRcloneProvider-agnostic transfer to 70+ storage backends
Memory safetyzeroize, secrecy, mlock/VirtualLockKeys zeroed after use; locked memory never paged to disk