How we protect your files

No marketing claims. Technical facts about how VexaHub encrypts, stores, and protects your data.

We cannot read your files

Zero-knowledge means the service provider has no technical ability to access your data. Not policy-based - architecture-based.

  • Your key is derived from your password on your device
  • Nothing is transmitted to our servers in a usable form
  • File names and contents are encrypted before upload
  • Even a court order cannot force us to decrypt your files
VexaHub never sees
Your password
Your encryption key
File contents
File names
VexaHub stores
Encrypted blobs
Encrypted metadata
Encrypted keys

Your password never leaves your device

Most services receive your password during login - even if only briefly, even over TLS. We use OPAQUE (RFC 9807, July 2025), a protocol where the server proves you know your password without ever receiving it.

  • OPAQUE is an aPAKE protocol finalized by the IETF in July 2025
  • Your password is never transmitted, even encrypted in transit
  • Even a full database breach cannot be turned into a working login - only offline brute force, blocked by Argon2id
  • Forward secrecy: past sessions stay safe even if our keys leak later
Traditional services
Your password Sent to server

The server receives the password and hashes it. A compromised server, a hostile insider, or a court order can capture it.

VexaHub with OPAQUE
Your password Stays local Server proof

Only an OPAQUE protocol message crosses the network. The server cryptographically proves you know the password without ever learning it.

Ready for the quantum era

Classical asymmetric cryptography (RSA, ECC) will be broken by sufficiently powerful quantum computers. We designed for that threat from the start.

ML-KEM-768 Post-quantum key encapsulation (NIST standard)
X25519 Classical key exchange (today's security)
XChaCha20-Poly1305 Symmetric encryption 256-bit key (128-bit post-quantum security)
The threat

Harvest now, decrypt later. Adversaries can store your encrypted files today and decrypt them when quantum computers become powerful enough. For sensitive data, this is a real risk.

Our solution

File sharing uses a hybrid X25519 + ML-KEM-768 scheme. Files at rest use XChaCha20-Poly1305, which is quantum-resistant by design. Both layers are protected.

EU sovereign, by design

Every component of VexaHub's infrastructure is EU-based. No exceptions.

Servers in Germany

Hetzner and storage located in Frankfurt. EU jurisdiction only.

EU certificate authority

Actalis, an Italian CA. Free ACME certificates. Zero US dependency.

Zero US infrastructure

No AWS, no Cloudflare, no Google, no Microsoft. Not subject to the CLOUD Act.

How we compare

Feature VexaHub Internxt Tresorit Proton Drive Filen Drime iCloud
End-to-end encryption Encrypted on device Yes Yes Yes Yes Yes Partially Partially
Zero-knowledge Server cannot decrypt Yes Yes Yes Yes Yes No No
Zero-knowledge auth Password never sent Yes No No Yes No No No
Post-quantum crypto Sharing protocol Yes Partially No No No No No
EU infrastructure Servers in the EU Yes Partially Partially Partially Yes Partially No
EU-based company EU legal entity Yes Yes No No Yes Yes No
No US jurisdiction CLOUD Act protection Yes Partially No Partially Partially Partially No
EU payment processors No US intermediaries Yes No No No No No No
Open-source frontend Auditable client No Yes No Yes Yes No No
No ads No trackers Yes No No Yes Partially No No
Desktop/Mobile apps Native clients No Yes Yes Yes Yes Yes Yes
Security audit Third-party reviewed No Yes Yes Yes No No No

Tresorit infrastructure runs on Microsoft Azure (Ireland).
Internxt uses Kyber-512 (NIST Level 1) with a custom hybrid construction, below current best practices.
iCloud offers E2EE only for certain data categories.
Filen uses several US-based third-party services (Sentry, Cloudflare Turnstile, PayPal, Coinbase) documented in their privacy policy.
Drime uses Cloudflare R2 for object storage (US company, subject to CLOUD Act) despite physical EU server locations.
Based on publicly available information and automated privacy audits, verified April 2026.

What we don't claim

Every web-based E2EE service has structural limits. We're explicit about ours rather than pretending they don't exist.

Web-served code

Your browser downloads our JavaScript and WebAssembly from our servers on every visit. We use strict Content Security Policy and Subresource Integrity from launch to defend against supply-chain attacks. These do not protect against compromise of our own serving infrastructure or legal compulsion targeted at us specifically. This is a structural limit of every web-based E2EE service. We are working on code transparency mechanisms that will let users verify their loaded code matches a publicly committed version. Native applications (planned post-launch) close this gap fully because their code is signed and verified by the OS app store.

Metadata we still see

Encryption protects file contents and names. We can still observe: file sizes, upload and access timestamps, your IP address (logged briefly for abuse prevention), and the existence of share links between accounts. We minimize what we log and do not sell or share this data, but it is not encrypted.

Endpoint security is on you

OPAQUE protects the network. Argon2id protects against database breaches. Neither protects against a compromised device - keyloggers, malicious browser extensions, or someone with physical access to an unlocked session. The strongest protocol cannot help if the endpoint is owned.

Independent audit pending

Our codebase has not yet been independently audited. The cryptographic primitives we use - chacha20poly1305 (NCC Group, 2019), x25519-dalek (Quarkslab, 2019), opaque-ke (NCC Group, 2021) - have been independently audited. ML-KEM-768 is a NIST-standardized algorithm (FIPS 203, 2024); the Rust implementation we use has not yet been independently audited but passes all NIST test vectors. Our integration of these primitives has not been audited. An external audit is part of our roadmap.

Our honest take on the alternatives

We offer a service. That doesn't make us the only valid option. Here's what we actually think about the serious alternatives, no spin.

Mixed

Tresorit

Tresorit is serious. Their infrastructure runs on Microsoft Azure, which means Microsoft is in the hardware chain even though files are encrypted client-side before they ever reach the servers. In practice, even under the CLOUD Act, there's nothing to read. The nuance is around unencrypted metadata and account data, which sits outside that protection. For genuinely sensitive files it's worth keeping in mind. For everyday professional use it's a solid choice.

Decent

Koofr

Koofr is a decent pick for EU users. Independent Slovenian company, no trackers, no ads, GDPR-compliant. The values are in the right place. Encryption is server-side by default, with client-side encryption only available through their Vault feature, so it's not fully E2E out of the box. Vault is open-source, which means anyone can verify how it works. If you're in the EU, it's a genuinely good choice.

Solid

Proton Drive

Proton Drive is solid. The company has a real reputation to protect on privacy and it shows in their technical decisions. Authentication uses SRP, which prevents Proton from seeing your password, though a compromised database can still be brute-forced offline unlike OPAQUE. Note: Proton operates under Swiss law, not EU/GDPR, and Switzerland recognized US data adequacy in 2024. If you're already in the Proton ecosystem it makes sense to stay there.

For your most sensitive files, local encryption is the only real guarantee.

Contracts, personal records, confidential archives. If the cost of exposure is high, encrypt locally before anything reaches a cloud. Any cloud, ours included. Two tools are the reference for this.

Why post-quantum

Classical asymmetric cryptography will be broken by quantum computers. Even though, they're not there yet, the threath is here. We designed for that threat from day one.

Timeline
2016

NIST launches post-quantum standardization

The US National Institute of Standards and Technology calls for post-quantum algorithm submissions, acknowledging the quantum threat is real and approaching.

2022

First algorithms selected

NIST selects CRYSTALS-Kyber (now ML-KEM) and CRYSTALS-Dilithium as primary candidates after 6 years of public evaluation.

2024

FIPS 203 officially standardized

ML-KEM-768 becomes an official NIST standard (FIPS 203). VexaHub implements it from day one.

2030 ?

Cryptographically relevant quantum computer?

Most estimates place a quantum computer capable of breaking 2048-bit RSA somewhere between 2030 and 2040. Timeline is uncertain but the direction is not.

Now

Harvest now, decrypt later. It's already happening

Intelligence agencies and advanced threat actors are storing encrypted traffic today. Any data protected only by RSA or ECC is at risk retroactively once quantum computing matures.

Comparison

VexaHub

Symmetric enc. XChaCha20-Poly1305
Key exchange X25519 + ML-KEM-768
Post-quantum Full hybrid
NIST standard FIPS 203

Proton Drive

Symmetric enc. AES-256 (OpenPGP)
Key exchange RSA / ECC
Post-quantum Partial / planned
NIST standard No

Tresorit

Symmetric enc. AES-256
Key exchange RSA classique
Post-quantum Partial / planned
NIST standard No

Internxt

Symmetric enc. AES-256
Key exchange Kyber-512 + ECC (custom)
Post-quantum Non-standard XOR hybrid
NIST standard No

Sources: public documentation and code audits. Proton Drive has announced post-quantum roadmap items but has not yet deployed ML-KEM in production for file sharing as of 2026.