Databeamer is built on a Zero-Knowledge architecture executed entirely within the client’s browser. This is not merely a policy decision; it is a mathematical constraint. Our infrastructure acts as a “Blind Router.” We facilitate the movement of data between authorized agents, but we do not possess the cryptographic keys required to decrypt the payload.
This document outlines the specific cryptographic primitives—including our use of streaming ciphers and AEAD—that guarantee End-to-End Encryption (E2EE) for files of any size.
The cryptographic stack
We have moved beyond legacy standards to utilize modern, high-performance cryptographic primitives optimized for browser environments and mobile devices.
Content (payload) Encryption (ChaCha20-Poly1305) We rely on ChaCha20-Poly1305, a high-speed stream cipher. Unlike older block ciphers, this allows for AEAD (Authenticated Encryption with Associated Data). This ensures not only the confidentiality of your data (it can’t be read) but also its integrity (it hasn’t been tampered with).
Key Derivation (HKDF-SHA256) To ensure robust key generation, we use HKDF-SHA256 (HMAC-based Key Derivation Function). This converts input key material into strong, cryptographically independent encryption keys.
Transport Security All data in transit is further protected via TLS 1.3, preventing Man-in-the-Middle (MitM) attacks at the network layer.
Large File handling: streaming encryption
A common limitation of browser-based encryption is memory usage (RAM). Loading a 10GB file into a browser usually crashes the tab. Databeamer solves this via AEAD Streaming Encryption.
How it works We do not load the entire file into memory. Instead, we read the file in small chunks.
The Process Each chunk is encrypted individually using the streaming cipher and immediately transmitted.
The Result This technology allows us to securely encrypt and process arbitrarily large files without size limitations, while keeping the client-side memory footprint minimal.
Data integrity & checksum validation
Encryption protects against spying; validation protects against corruption. To ensure the content received is exactly what was sent, Databeamer employs a dual-layer integrity check.
AEAD Layer The Poly1305 authenticator in our cipher ensures that if a single bit of the encrypted stream is altered during transit, the decryption will mathematically fail.
Checksum Layer Complementing the E2EE, we generate a cryptographic hash of the original file on the sender’s side. Upon completion of the transfer, this hash is automatically verified on the recipient’s side. This confirms that the file has not been altered, corrupted, or tampered with by any network intermediary or disk error. This process is transparent and requires no user interaction.
Distributed Key Management
We have eliminated the single point of failure inherent in traditional key storage. Instead of storing your Private Key as a single static file on your hard drive (which could be stolen) or on our server (which would violate Zero-Knowledge), we utilize a Distributed Key Management architecture based on the Pedersen Verifiable Secret Sharing scheme.
The “Shattered key” concept (2-of-3)
Upon account creation, the user’s Secret Key is mathematically “shattered” into three distinct cryptographic fragments (shards). No single shard contains enough information to reveal the key. To reconstruct the Secret Key and decrypt data, a threshold of 2 shards is required.
Note: Databeamer cannot reset your decryption capability. If you lose your Mnemonic, you lose access to historical encrypted data.
Metadata & compliance logging
To ensure business compliance (ISO 27001) and system functionality, strict subsets of metadata are visible to the Databeamer service.
| Data Point | State | Purpose |
|---|---|---|
| File Content | Encrypted (ChaCha20-Poly1305) | The actual data being transferred |
| Sender/Receiver IDs | Plaintext | Required for routing and permissions |
| Timestamps | Plaintext | Required for audit trails and SLAs |
| File Size/Type | Plaintext | Required for storage quotas and optimization |
Audit Trail We maintain a tamper-evident log of actions (Upload, Download, Delete) without ever logging content.
Privacy-preserving analytics
We believe that improving our product should not come at the cost of your privacy. Therefore, we strictly avoid invasive tracking tools (such as Google Analytics) that monetize user data. Instead, we utilize Plausible Analytics for basic usage insights.
Self-hosted & sovereign We host the analytics code and data entirely within our own secure environment. No analytics data is ever shared with, or sent to, third-party servers.
Cookieless Architecture Plausible is designed to be fully cookieless. It does not place persistent trackers on your device and does not track your activity across other websites.
Aggregate Only We collect only anonymous, aggregate metrics (e.g., “Page load times” or “Screen resolution stats”) to optimize performance and UI. We do not (and cannot) use this tool to link activity back to specific encrypted payloads or individual identities.
Further Reading
Check our technical and legal security measures in our Security Policy
Check our article about why zero-knowledge encryption matters
Check our position on privacy